A software architecture is a decomposition of a software system into sub-systems or modules. These modules should be more or less independent. Remaining dependencies and control relationships (i.e. which module(s) is/are the boss) should be expressed in the model. Developing an architecture is part of software design. While decomposing the individual modules further one finally reaches detailed design, which is usually done with object-oriented models, functional models, data flow diagrams, .... .

A software architecture gives the software engineer an overview of the system, helps to define APIs and to communicate his ideas to his peers. It also allows to use something similar to software patterns on an architectural level to make it easier to re-use knowledge. Some standard architectural patterns are :

More structural 'patterns':

Piped architecture:
The different modules are organized as an assembly line with each module doing only part of the job and providing its output as input of the next one. Typical for UNIX shell scripts.
Blackboard architecture:
All modules place their results in a central area (the blackboard) and fetch new input from there. Every modules sees everything. Typical for some AI systems.
Client-server architecture:
Each server provides specific services to everyone caring to ask it. It may use services of other modules and can therefore be a client at the same time. Servers may be active (e.g. to exchange information with peers). The user is using clients, but in reality he may be interacting with a server (e.g. the X-server). Used by a lot of systems, especially distributed.
Layered architecture:
Modules are organized in several layers and each layer uses the next lower (and only it) to provide services for the next upper. Makes e.g. security easier. Used e.g. by former operating systems (don't ask me about current).

More control 'patterns':

Main program sub routines architecture:
A central module calls others (which may again call sub-modules of them), forwards intermediate results and stays in control all the time. Typically found in most programs not using threads or interrupts.
Event-based architecture:
The system reacts on external events (from e.g. the user, the OS or some sensors) by dispatching them to an appropriate module where they are handled.
Table-driven architecture:
Most of the control logic is embedded in some data structure which is 'interpreted' during program execution. Examples are YACC-generated compilers and state-machine-based systems.

To summarize: Use them! ;)

<architectures partially taken from a technical report of David Garland and Mary Shaw, the distinction into structural and control architectures is from "Software Engineering" by Ian Sommerville>

Architecture starts when you carefully put two bricks together. There it begins.
Ludwig Mies van der Rohe


As with traditional architecture, software architecture begins when the first lines of a computer program are written. Whether the architecture is described by formal documentation or a barely imagined “castle in the sky”, the author of those first few lines of code and all the lines which follow them is being guided by a software architecture.

The analogy continues to apply as the software development process continues to unfold. Just as a well architected building achieves its potential in form and function as it nears completion, so a well architected software system achieves its potential in form and function as it nears completion. In contrast, poorly architected buildings and poorly architected software systems never seem to achieve their potential (assuming that they are ever actually completed at all).

The extent to which the completed building meets or even exceeds the customers goals and expectations is not an accident. Rather, it is the direct result of the quality of the building’s architecture. Similarily, the extent to which a completed software system meets the customers goals and expectations is also not an accident. It is the direct result of the quality of the software system’s architecture.

Creating or developing an architecture is the task of an architect. Just as a building architect is responsible for a building’s architecture, a software architect is responsible for a software system’s architecture. They are both involved in very similar tasks:

  • They work with the customer to develop a shared understanding of what the building or software system should do.

  • They use this understanding to produce architectural diagrams and other documents which describe the building or software system in terms of both form1 and function2.

  • They guide the process of developing engineering blueprints or system design documents.

  • They continue to provide both overall guidance and often detailed input into issues that arise during the project’s construction/development phase. They have near final accept/reject authority regarding changes to the building or software system’s architecture including the near absolute right to decide whether a change is architectural or not.

  • They are ultimately responsible for ensuring that the finished result satisfies the customer’s expectations regarding function, form, time and budget (i.e. if the completed building or software system does not “work” then it is likely that the architect rather than the engineers/designers or the construction crew/developers who have failed).

There is one rather fundamental difference between the world of building architecture and the world of software architecture - a building architect generally concerns themselves with a single building or group of buildings whereas a software architect can find themselves dealing with either a single instance of a software system (i.e. a custom development scenario) or with a software system which will ultimately be reproduced many times over (i.e. a product development scenario).

The difference between a custom development scenario and a product development scenario is fundamentally the difference between being able to develop a shared understanding of the final result with the “real” customer or having to settle for trying to developing a shared understanding with the product visionary, the “marketing” folks and (hopefully) a selection of potential customers. The result tends to be a somewhat higher level of risk when developing a product’s architecture vs developing a custom system’s architecture3.

Architecture as a risk reduction tool

When one embarks on a building or a software system construction project, one enlists the services of an architect because one expects the architect to “add value” to the project. This “value” can take many forms including, of course, the “value” that a building/system which has been properly architected simply “works better” because an architect notices and understands things that others miss.

Each of these forms of “value” really amount to the same thing - risk reduction. The “risk reduction value” which an architect brings to the table can take many forms:

  • a reduced risk that the project will fail outright.

  • an improved likelihood that the customer(s) will be satisfied with the building/system.

  • an improved likelihood the building/system will “work” as expected.

  • a reduced risk that the building/system will be completed on schedule. a reduced risk that project will be over budget.

Closing remarks

The analogy between building architecture and software architecture is surprisingly good. What’s more than a little disconcerting is that few companies would even consider embarking on a major building construction project without the services of a building architect and yet these same companies routinely embark on major software construction projects without any serious consideration being given to the architecture of the proposed software system.


1 For example, a circular structure with a central atrium or web-browser like kiosks located in strategic locations.
2 For example, three million square feet of office space with a shopping mall on the lower level or provide theme park information and directions to the nearest toilets.
3 One must be careful to not over emphasize this issue as it is certainly not unusual for a custom system’s “real” customers to have little if any deep understanding of what the custom development project’s needs and goals are, a situation which effectively eliminates any real difference in the risks associated with custom vs product development scenarios.

The analogy between building architecture and software architecture is taken from the philosophy of the Worldwide Institute of Software Architects (www.wwisa.org).

Log in or register to write something here or to contact authors.