Enterprise architecture is a methodology applied to a business process, typically as part of solution delivery. In layman's terms this means that one way to ensure that any project an organization undertakes is successful is to follow a tried and true process throughout the life of that project.

This process is often called a framework, and the individual deliverables within the framework as artefacts. As you might imagine a framework used to describe any or all of an organization’s projects would necessarily be very high-level and broad in scope. Thus what most organizations do is begin with a comprehensive industry-standard framework and then out of that develop their own focused one.

The process of developing your own architecture framework is a balancing act. Without a framework you will find your organization suffers from the following problems:

• Poor engagement with your customers
• Unclear expectations from solution delivery groups within your organization
• Lost confidence by your customers in your ability to deliver a solution
• Repetition of previous mistakes
• Missed deadlines

In short, your project management team will not be successful in their deliverables because there is no clear architectural framework for them to follow.

However, you can have too much architecture as well. This may result in:

• Cost overruns
• Missed deadlines

To be successful your organization has to hit the sweet spot in the development of their enterprise architecture framework. This sweet spot is different for every organization but it is defined as the point where your staff does not need more direction, but any less results in the symptoms of a lack of framework as outlined earlier.

How do you find the sweet spot? Consider the following two areas to get you started:

• Staff competency
• Deliverables

Staff Competency
Asking a Linux guru to document every installation step he or she takes as part a large project is like asking a master chef to hand wash each and every leaf of lettuce as part of food preparation. Chefs have knives. Linux gurus have root. Both can get pretty ugly if you over-bureaucratize their job. What you need to know is what you need to know to meet the objectives of the project and of your organization as a whole. Don’t ask them for more than that.

Deliverables
Mission critical computing systems are considerably more complex than potato peelers. Ever sit in a day-long boardroom meeting where really helpful yet heated discussion is taking place and wonder to yourself if anybody will actually remember what was being said by the next morning? At some point the discussion is too technical and too complex for even the best minute-taker to capture. In the same way the more complex your deliverables are, the more detailed and complete your enterprise architecture framework will have to be. What we are looking for here is to keep it as simple as possible, but not simpler. Processes must exist to capture all of the critical information you are going to need to make your projects successful.

Of course there are many more areas to examine but the point remains the same. You need to understand the nature and requirements of your business, your customers, and your staff. Develop just the artefacts from a broader framework that make sense for your business, and only develop them to the point they need to be to make your business efficient.

Please let me know if you would like me to dig into more detail about any aspect of balancing an enterprise architecture, or enterprise architecture in general.