The value of software architecture

A favorite hobby of IT architects is to discuss the purpose of IT architecture and what value it contributes to an organisation. See for example The Three C's of Architecture, or the motto of the last Nationaal Architectuur Congres in the Netherlands: Architecture múst contribute (as if that were not obvious!).

The goal of information technology is to improve business processes using computers. Improve in the sense of speeding up the processes, reducing their cost or increasing the quality of their results. But information technology is of course not the only way to do this: processes can also be simplified or streamlined, or eliminated entirely if it appears that no one is waiting for their results. All without any automation in sight. This step is often skipped by the way. This process improvement is the area of business architects and enterprise architects, depending on the definition of these terms.

Only when software is used (purchased, constructed), software architecture comes into play. There are lots of definitions of software architecture of course. My favorite is that of Jan Dietz, quoted and explained in: Architecture, a definition by Johan den Haan:

Theoretically, architecture is the normative restriction of design freedom. Practically, architecture is a consistent and coherent set of design principles.

The beauty of this definition, I think, is that it clearly distinguishes between the concepts of architecture and design, which are mixed up in most other definitions. A good reason to restrict design freedom is that it saves on having to think. Thinking takes time and energy, is difficult and error-prone. So thinking should be avoided wherever possible, to be saved for the problems for which it is really needed!

By the above definition, software architecture focuses on the design of software and thus on improving part of the process of developing software. And, like in the case of business processes above, improving in the sense of speeding it up, reducing its cost or increasing the quality of its result. And, again like with business processes, there are more ways to do this besides software architecture, like for instance, development methods and tools.

Just like information technology must deliver value to the business processes, software architecture must deliver value to the process of developing software. In other words: the goal is the same - to deliver value - but the thing to which that value is delivered is different: software development instead of business processes. If you look at it this way, the value of software architecture for the organisation as a whole is at best indirect. For that value is only added after the enhanced software development process has delivered more value to the organisation, at lower cost, or in less time. This idea should make software architects humble.