Architecture

When and why do you need an architecture?

If you are going to build something small or even medium in size, you can just wing it. Small stuff requires little architecture and medium systems most often crystallize along some crude architectural lines without much intervention. If you are going to build something large and you start without an architecture, what you will wind up with is a large series of disconnected and/or overlapping pieces that are impossible to stabilize. The project will die.

So what is an architecture?

In its most simplest explanation it is the overall organization of the underlying sections of code. For something to be ‘organized’ that means that there are a series of rules which categorize a specific layer to a ‘reasonable’ number of sub-pieces. Most often I prefer to refer to these as ‘lines’ and to leave the number of layers to be relative to the problem. An unreasonable number of categories is somewhat dependant, but lower numbers like 3 or 5 are nice, while larger ones like 20 or 30 are problematic.

How does one describe an architecture?

Like any good blueprint, an architectural description is a top-down listing of the lines and the layers. But since there are essentially two dimensions to an architecture there need to be two main roots to the design. The first is the underlying data in the system, while the second is the way the code is constructed to manipulate this data.

A top-down view of the data is essentially a hierarchical structure, starting with the major entities and gradually breaking them down into the details. The overall organization however needs be contained within a reasonable number of categories at each layer, so the major entities are most likely collected into a smaller set of categories at an abstract layer. That ‘organizational’ constraint flows all of the way down to the details. The data itself often cross-references other entities, but it does so internally (as data), thus it often be arranged in a hierarchy.

For the code the situation is similar. A hierarchical structure of categorizations forms the basis, however code is a little more difficult. To avoid redundancies many well-defined parts of the system will be shared at many layers, so here a hierarchy really fails to capture the expressive requirements of a well-designed system. Thus, although there is a root (a place to start), the lines in the code form a graph of categorizations, although these should still be presented as well-organized layers (unwinding this is part of the challenge).

So overall a well-documented architecture has two main sections that each descend down into the details. At each layer, there are a reasonable number of sub-pieces that are either specific or abstract (if necessary to be reasonable). A group of programmers should be able to walk their way through both parts of the document and use all of the contained information to solve all of the final coding-level problems.

If all is going according to plan, they still have significant problems to work on but all of the external decisions have been resolved and they understand how their individual pieces will interact with each other.

How does one create an architecture?

A software system needs a well-defined problem to solve. The underlying details, driven by this problem, come from analysis of the solution, which identifies the required data and the algorithms to operate on the data. There may also be analysis into the operation environment for the system and possibly the development environment as well. All of these details need to be sorted and arranged, then finally organized into layers. Although the final architecture is top-down, assembling the pieces in a bottom-up manner is often simpler and produces less redundancies. Generalization and abstraction are key to reducing the effort and getting it presentable. The architecture is ready when it’s depth matches the programming team’s capabilities.