The control of a large force is the same principle as the control of a few men: it is merely a question of dividing up their numbers.
Sun Tzu: The art of war
What should it mean in the field of architecture management? What to divide and how? How to keep control about a large Enterprise Architecture? Finally the recipe is the same as for war forces: you need an organisation, a kind of "command hierarchy" which enables the appropriate control over the entire Enterprise Architecture. This is the first part of a series about preparing Architecture Management Directive, which was one of the topic selected by you in the What would you like to read more? questionnaire.
The best way of dividing the Enterprise Architecture is to have Enterprise Architects on the top layer, domain architects in the middle using functional landscape separation and application experts on the bottom layer, having three layers and not more. Building this setup, you should have one Domain Architect responsible for 30-50 applications through Application Experts and one Enterprise Architect per each 4-7 Domain Architects. Domain and Enterprise Architect together are the Architecture Committee in the enterprise. One more thing about the applications: I gave you a reference amount of the number of application but this number is not carved into the stone! Those domains, which contain more of standard based applications like IP network and transmission my contain more applications, while another domain having non-standardised solutions, or large amount of significant changes are expected should contain less.
At the end you will have an well-defined layered professional organisation, with one or more Enterprise Architects for the case you will have more there must be a nominated lead, usually called Chief of Chief Enterprise Architect who is responsible to operate this organisation, since shared responsibility means no responsibility. The specialities of this role we'll come back a bit later where we will clarify the reason of not handling this role as an additional layer.
The figure above shows the hierarchy and highlights the main tasks of the people there. You can see chat the Chief Architect has no special role about the optimisation and development related tasks he or she is one of the Enterprise Architects. What is the difference then? It is about the architecture change management. All the changes, which should be analysed and decided by the Architecture Committee should be lead or supervised (in the case when another Committee member leads/owns a given topic) by the Chief Enterprise Architect.
Example of domain setup
The following figure shows an example how to prepare domains in case of a convergent telco operator. What is so interesting in this division of functions that numerous domains are common to other industries, only some should be changed to apply to different places. Telco specifics are the Telco enabler, the Radio and Fix access plus the Core control domains. One more argument is, that more matured, more convergent cases the Radio and Fix access will be a single Access domain to ensure utilisation of seamless and hybrid communication technologies.
Cross-domain functions
There is one last thing we have to mention: they are the cross-domain functions like Security, Risk management or Integration. These cross-domain functions are the hygiene factors, therefore each Architects has to calculate with them by default. This is the reason why cross-domain architects or experts are not active participants of the Architecture Committee (not active means they have no right to vote). Their cross-domain observations could be counted by each active members and the insurance of understanding their opinion is the responsibility of topic owners and/or the Chief Enterprise Architect.
Will be continued to understand the different type of committees, TOGAF references and voting mechanism.