A Marchitecture is an architecture produced for marketing reasons, normally by a vendor. It is designed to put the vendor in the best possible light by emphasising the positive as well as hiding the negative. If you are in marketing you will spell it Marketecture.

Whereas an architecture is an attempt to define how the various, and many, components of a system fit together and interact.

Why do we produce architectures and why do they seldom meet the various demands laid on them?

The first question is easy to answer. Any system that is worth discussing is complex and human brains are not good at dealing with complexity. Our solution is to divide the world up into manageable chunks and then show how they relate. Having done this we have the added advantage that we can modify or replace bits without breaking the whole; as well as handing the individual components out to separate groups for development.

The more difficult question is why are they often inadequate?

The first requirement is that an architecture should be a graphical representation with written back up. This leads to the first set of reasons for inadequate architectures. Some people are less able to think graphically than others. More serious is the medium used - two dimensional A4 pieces of paper, or the digital equivalent. Architectures, like the plans for a house do not conveniently flatten themselves out into two dimensions.

The second requirement is that the picture should mean something meaningful. Sounds obvious but too often two boxes are put side by side for no apparent reason except that the producer wanted both of them on the same piece of paper.

Please tell us about your pet hates in marchitecture diagrams.

Here is my list as a starter:

• Overloading: trying to put everything on to one page. Often to be recognised by the use of three dimensional boxes that attempt to show how things are built on one another, or by bars down the side saying things like security or monitoring without any indication how they fit together. After a recent discussion about an overloaded architecture it was agreed that a picture is worth a thousand words but it cannot say two thousand.
• Underloading: a picture with four boxes and some pretty patterns generated by powerpoint. In general four boxes do not make an architecture.
• Diagrams showing flows of processes or data that do not have a predominate flow in one direction (left to right, top to bottom, or occasionally middle out).
• Layered architectures where it is not obvious (or in some cases true) that the higher levels are built on the lower.
• Architectures that do not recognise the flow of time and the development life cycle.
• Architectures that do not show the whole of the business problem. Normally because the bits left out are difficult or not supported by the vendor. This is often difficult to recognise as it is very difficult to answer the question: what is missing from this picture?
• Pictures that have unrelated thoughts on the same page. For example should a database design tool and a firewall be on the same page?

In a future article I will discuss some techniques to alleviate these problems. In the meantime if you are looking at an area, first devise your own architecture and then use that to critique vendor diagrams.