On architecture

I have been thinking that there should be a generic way to express the role of an architect in an organization and thus also helping people be better architects. So here it comes.

The layers
Architects know that system architecture is not a thing in itself, it is strongly bound to how an organization works in general. There are authors who have thought about that to some extent (like Christophe Longépé) but they usually only look at the technical or functional side of the systems. It seems to be much wider than that, let's build a stack here:

1. Organizational architecture. This layer answers questions like what business are we in? How do different parts of organization relate to each other? What are the core principles the organization lives upon? What business processes do we have?
   
2. Functional architecture. Every organization performs a certain set of functions in its everyday life. This layer deals with what clumps of functionality (like accounting, HR, customer service etc.) there are and how they interact.
3. Technical architecture. This is the domain usually attributed to technical architects and deals with logical components, integration methodologies, middleware and so forth.
   
4. Support architecture. The layer consists of processes tools, and organization that works underneath the technical architecture. Version control setup, release and testing procedures, coding conventions, team interaction, development methodology etc.
   

An example
Let's explore this layering using an example. Let's say a system architect has three projects on the table for evaluation, each of them approaching the concept of a corporate customer from three different angles creating a technically unsolvable puzzle: although the architect sees that it would make sense to have the three systems talking to each other this can not be done because one treats companies as phone numbers with some fields attached, the second one as a source for authentication information (several customers can operate under the same legal agreement) and the third as an entity that has to pay VAT.

How did it come to this? Apparently all of the layers were affected. Firstly, the organization was set up as a set of silos which do not talk to each other, which leads to the three different unsynchronized projects being initiated.

Secondly, the functional architecture consists of a phonebook, a list of warrants describing who can do what business with the company and an accounting system. This poor setup gives the business units no support in their quest for solving their business problems and getting money pouring in.

The technical architecture, the third layer, now has to face the situation and figure out a way to solve this. As forcing the business people back to the drawing board does not work (remember, there are silos and nobody has ever spoken to them about the concept of a unified customer view) and re-writing all existing systems would blow the budgets of all three projects all there is to do is to build three separate systems. Which, as the architect knows, will lead to an integration nightmare the moment somebody discovers it would make sense to have the ability to have the company phone number displayed along the agreement information so the legal people can conveniently place calls.

The support layer now faces even more trouble: instead of having one or two applications to deploy there is three, all of which have different availability requirements, different release cycles, different versioning schemes and so on.

In short, a problem in an upper architecture layer leads to a growing amount of issues on its way down. Actually, the same applies to the opposite direction. Imagine a setup where two different outsourcing partners (one using RUP and the other XP) are forced to work together to tightly integrate their applications as there has been a change in the organizational structure. The very least that will happen is that the applications remain separated and the business guys suffer acute schizophrenia while participating in a planning game in the morning and compiling requirement artifacts in the afternoon.

The conclusions
Following conclusions can be drawn from the layering concept:

1. A poorly set up layer "radiates" issues to the neighboring layers. For example, a poor technical architecture leads to problems in deployment because of unmanageable dependencies and a weird organizational structure leads to a weird functional architecture.
   
2. A major change in any of the layers causes changes in every layer with the impact getting weaker the further you get from the source of the change. What is interesting about this one is that it usually only applies downwards. If changes start filtering upwards, something is very badly broker somewhere as there should not be any technical change without a business cause.


3. The model shows a weak spot most of the companies happily ignore: the fact that nobody is really responsible for the functional architecture layer. However, it acts as a filter between top and bottom layers and thus, if undeveloped, hinders all cooperation between them. The only conclusion to draw from here is that a system architect needs to make darn sure that part of the stack is under control taking it to him or herself if necessary.

Comments from Sergei added as a separate post