Enterprise Architecture Fatigue

Enterprise Architecture Fatigue

Interesting discourse with a new client. They have been through numerous attempts to establish Governance using Enterprise Architecture and every time they find themselves swamped with extremely clever people who produce copious quantities of Enterprise Architecture documents, diagrams and hold ever increasing numbers of meetings. Meanwhile, when the client asks for tangible support material needed for making Architectural Decisions and to support implementation, information management and other operational issues, nothing is found.

The client complained that in the past numerous teams have tried to "Boil the Ocean" and model as many artefacts, creating system views that were academically perfect, however it seemed that the diagrams just didn't meet the needs of the client or their stakeholders.

Another way

That brings me back to another way. I explained to the client how this works, that first of all we work out a list of their core requirements and needs as this frames the types of diagrams that need to be developed. It is all about purpose and keeping to the scope, understanding the stakeholders, their needs and their roles, which dictate how they use architecture in their organisational and operational roles.

The work of setting up a Governance Framework has not been helped when clients have been through these experiences and it is harder to win back confidence. What does help is explaining how focussing on key diagrams developed on the basis of the Core Architecture Requirements and Needs, guided by Architectural Principles.

The client has a set of Architecture Principles, which they were quite happy to disect and analyse into constituent concepts. The approach to Principles in TOGAF can at times consist of best intentions or be considered a "wish list" while it is more useful to look at design guidelines that inform real and practical strategic direction. When looking at a Principle, it is worth asking the "so what" question.

Basic Rules for formulating principles 

1. Name the concept or phenomenon that has been identified as a target, and break down the contributing aspects, lowest common denominators, factors that describe the phenomenon in terms of root causes and symptoms.
2. Give the principle a name tag, makes it easier to name and nail. Then add relationships to the root causes - an atomic factor could be a factor in a number of principles. 
3. For effective communication purposes try to find or create a picture showing exactly what is stated in the short statement - start a pattern books (the good, the bad and the ugly)
4. Do not mix derived design rules or policies with the principle itself. It is obvious you need policies and rules to take the principle in to account once you know of the principle. But rules and policies are not part of the principle!

Take a Security Principle By using two staged authentication and authorisation mechanisms in accessing company systems from external trusted systems it is ensured that only legitimate system access is allowed so that unauthorised access is prevented and critical information and resources are protected.

These principles are then analysed and devolved down into logical patterns for concepts that will guide implementation and that will be used for underpinning Architecture Governance decisions and evaluating design choices.

Governance Artefacts

 Gradually, the Principles and Patterns (Concepts) are starting to provide artefacts that support Governance and provide means to measure compliance with policies and to start identifying divergence. This is a perfect opportunity for identifying where dispensation needs to be allowed for exceptional circumstances and to schedule initiatives for bringing these systems or operations back under compliance. Sometimes an exception is needed in operationally critical circumstances or when technology is not mature enough to cope with the rigours demanded for secure operations. In these cases extra measures need to be put into place to guarantee the integrity of the wider system, such as a DMZ (demilitarized zone).

This approach has been a voyage of discovery for the client. Their first instinct was to design the Architecture using a "Bottom Up" approach by mapping out the system inter-connectivity and mapping out the interfaces and information exchanges.  While this at least shows current landscape and is an opportunity to identify where there are discrepancies, it does require some analysis in the light of its compliance to the desired principles and patterns. It does provide an opportunity to start identifying areas that need transformation and to plan activities to bring about compliance.

More importantly is the ability to keep focusing stakeholders on their roles, responsibilities and their involvement in the Governance process and in reviewing and agreeing models. Enterprise Architecture will be seen as an enabler as stakeholders are impressed with the relationship between compliance, policy, architecture diagrams and standards.

So we have come a long way, in a relatively short time and hope that Enterprise Architecture will be seen as a useful support tool for managing systems