We often rely on metaphors and analogies to explain software, its structure and function. We cannot see software (except for its user interface), so we use metaphors to illustrate. It is true that we can print out the source code and look at it, but such static representation can mislead as far as the software’s true behaviour (we call these defects).
Metaphors can also mislead. A single metaphor can rarely illustrate all aspects leaving us with an incomplete illustration. Integrating several metaphors is tricky, as it can easily confuse. But without, a single metaphor will be over-interpreted and extended to cover the gap inappropriately. Consider the word ‘architecture’ as a software metaphor.
We use the word ‘architecture’ as a metaphor to illustrate and explain the purpose of ‘software architecture’ (and feel free to replace ‘software’ with ‘enterprise’, solution, technical, etc.). Most people have an intuitive understanding of ‘architecture’ as representing structure, important, and quality. More generally, the word ‘architecture‘ is defined as the “formation or construction of a unifying or coherent form or structure” and can refer to “both the process and the product of planning, designing, and constructing buildings and other physical structures” (wikipedia).
Software consists of structures including the one found in its source code, although it is not the only structure of concern. Coherence is a desired property of software, that we seek to maintain through the formation and construction of the structure. Without coherence, the software is unlikely to work properly and be maintainable. The building architecture metaphor is frequently used to define ‘software architecture’ and sometimes made explicit – see Clement et al, Spewak, The Open Group, or Perry and Wolf as well as Garlan and Shaw.
There is one problem. Software is not a building.
Philippe Kruchten argues in his paper, “The Nature of Software“, that software has a very low manufacturing costs. In a strict engineering sense, software manufacturing cost is only the cost of creating the distribution media. The act of programming is similar to creating a cast in mechanical engineering.
This changes the purpose of ‘software architecture’ dramatically from ‘building architecture’ – in other words, the metaphor breaks down.
Software architecture is about guiding and constraining subsequent design decisions and not the subsequent construction (aka manufacturing). Architectural documentation, patterns, and styles guide the design process, while architectural decisions such as “we must use Java” constrain subsequent design decisions (as we can no longer use C# and probably not Microsoft application servers). Architectural design is about defining a suitable Design Space to support subsequent design decisions (which in themselves can also be considered an architecture; enterprise vs solution, solution vs technology etc.).
It occurred to me that many aspects of creating a useful architecture relate as much to cartography (map making) as to building architecture. According to wikipedia, the fundamental problems of traditional cartography cover:
- Map editing: Set the map’s agenda and select traits of the object to be mapped. We must tailor our architecture according to our stakeholder concerns and choose appropriate views.
- Map projections: Represent the terrain of the mapped object on flat media. We must choose the appropriate software element representations (such as those described in UML or ArchiMate) and how they can be mapped between different views.
- Generalisation: Eliminate characteristics of the mapped object that are not relevant to the map’s purpose to reduce the complexity of the characteristics that will be mapped. If there ever was a single critical activity for software architects, then this is it – generalisation to reduce complexity.
- Map design: Orchestrate the elements of the map to best convey its message to its audience. If you cannot communicate your architecture then there is no point.
Maps express structure often with several layers of information. Their intent is to guide a decision process. Cartography works well as a metaphor for software architecture. On the other hand, the (building) architecture metaphor does not encapsulate many of the challenges we face when designing software systems, while implying activities typically associated with IT management methodologies – a consequence of building architecture’s intend to guide construction and not design.
But I guess “software cartographer” does not have the same ring to it – as “software architect” does – even if, as a metaphor, it provides a better representation.
