Software Engineering and the Software Architect

Part of my duties here at the University of Applied Sciences, Hof, is to teach the Art of Software Engineering.

Computer Science has been around for a couple of decades, but thinking of it as an engineering discipline is a rather recent trend.  So how does it compare to other engineering fields?  A recent survey of software project has brought the following shocking facts: 25% of all software projects succeeded, 50% were challenged and 25% outright failed [1]. 

To get a better feeling for these numbers consider the building of bridges [2]:  If a bridge-engineer were to build four bridges, one of those bridges would be just fine.  One bridge would collapse immediately before ever anybody walks on it.  Although not good, still nobody gets hurt.  So what's with those other two bridges that are 'challenged'?  Those are bridges that swing violently back and forth at the slightest wind blowing, cars might drop of for no reason, but since about ten percent of the cars get through without any damage, they are not considered a failure.

In my opinion there are two reasons for this current state of affairs: first, we only let certified bridge-engineers build bridges.  This is not true for software: anybody who knows half a programming language and with two or three classes in some obscure programming language can call themselves a software engineer.  It is like saying that one can play Chopin's Etudes after listening to a couple of Chopin's CD's. 

Second, and more importantly, the role of the software architect has neither been understood nor its necessity been acknowledged.  When building houses, one would never think about building a medium to large size house without an architect.  However, many medium to large size software projects are build without a software architect.  And mind you, a project manager is no software architect.

As Matthew R. McBride writes, a software architect is a technically competent system-level thinker, guiding planned and efficient design processes to bring a system into existence.  He is viewed by customers and developers alike as a technical expert.  The architect is the author of the solution, accountable for its success or failure [3].


[1] The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000
[2] Rafal Lukawiecki, New Developments in Microsoft Solutions Framework
[3] Matthew R. McBride, The Software Architect