How to Break Down Architecture

Software architecture – at what point does the documentation start? Where does it end? What processes should be followed to see architecture through from its inception where requirements are still vague through to the finishings of a crystallised notion? As with almost all design disciplines a software architect starts with the big picture. Once the requirements have been very loosely defined it is possible to produce some marchitecture. Marchitecture is very informal (a cross between marketing and architecture) – pretty pictures and colourful blocks. This allows the architect to convey what might be built to customers or management. It gives a very high level overview and probably does not represent technically what will really be built at this stage. The marchitecture will later evolve into architecture which gives a true representation of the system as further requirements become apparent.

So why produce marchitecture? Well it allows very early visibility into the project, and can be understood by a large audience. It provokes thought and debate at an early stage, which lead to further ideas and confidence building in the project. The marchitecture can often be used later in marketing and supporting documentation for the product.

The next phases should produce architectural documentation formally represented e.g. in UML. But we should not go diving straight into the fine details as it will be very difficult for anyone to grasp the concepts of the system as a whole. Instead people need to be guided though various levels of abstraction to allow them to build their understanding. A high level of abstraction is often referred to as a low precision view. We also need to cater for different audiences needing to view the architecture only down to a certain level of abstraction.

This all falls very nicely into the development cycle as an architect will naturally go through similar levels of abstraction in his or her mind whilst the system is being fleshed out. So I would recommend documenting architecture on three or four levels of abstraction as you firm up your understanding. This process is known as hierarchical decomposition. A component within the achitecture is only specified once the corresponding sub-system has been firmed up within the previous level of abstraction. Clever numbering of architectural components is often used to specify the level of abstraction they come from. Class objects are only defined at the lowest level of abstraction.

Another huge advantage in using this method is to be able to offer early cost estimates on each component. These costs can then be refined in the next level of abstraction as more detail is known. Failing to produce architecture in this way will result in a giant blobby mess which no one can get a handle on, and the architect will struggle to manage the complexity.