Counterintuitive Enterprise Architecture

If you have spoken to any Chief Architect or a student of Enterprise Architecture, most would advise you to begin your Enterprise Architecture program with the Business Architecture, which is sound advice. The business needs of the organization should drive technical solutions. How could you possibly know what your Technical Architecture should be if you don't know what Business functions it should support? In other words, your Business Architecture should drive your Technical Architecture.

Here's a taste of reality. Most Enterprise Architecture Programs organizationally reside in the IT department. Many IT executives don't understand Enterprise Architecture, or if they do consider it to be purely Technical Architecture.

So how do you create and an adaptive Enterprise Architecture program driven by the business with these constraints? Start with your Technical Architecture!

I know, I know, believe me it hurt me to say it. However, if you want your EA program to survive and eventually provide value to the organization, you need it to be around long enough to do so. I recommend building credibility by first dealing with your Technical Architecture governance, lifecycle, processes, artifacts, etc. By building credibility and documenting your wins with your Technical Architecture, you'll have the breathing room you need to tackle your Business Architecture.

Low-Hanging Fruit

Picking the low-hanging fruit first is the key to your Enterprise Architecture (EA) program credibility. When starting your enterprise architecture program, identifying and resolving your organization’s pain points will add credibility to your initiative.

Identifying and Resolving Pain Points

Understanding the organization’s pain points and addressing them with EA can build a tremendous amount of credibility to your EA program. In the beginning, it is very important to understand which issues can be addressed easily and quickly. For example, something as simple as a charter for an Architecture Review Board (ARB) can help all stakeholders understand the scope, roles, and responsibilities for the ARB. In my experience, this simple deliverable was enough to set a clear scope and direction for this governance group. Better decisions and more efficient meetings resulted from this change.

Address issues that require minimal effort, like writing a charter, first. Choose two or three pain points that can be resolved through the EA program within 30 days at the beginning of your implementation. The Enterprise Architect and EA program’s credibility is absolutely critical for success. Pick the low-hanging fruit early in the project to buy time for the larger and more important changes.

Pragmatic Advice

• Look for simple fixes such as a roles and responsibilities document or a simple phone call to a stakeholder in the beginning.
• Communicate the quick win.
• Address the pain points within the first 30 days of your program’s kick-off.
• Use Steven Covey's high-level prioritization scheme to identify important and urgent needs.