Pragmatic Enterprise Architecture

Dummying it Down

noreply@blogger.com (Brad Meyers) — Mon, 18 Feb 2008 17:17:00 +0000

The definition of the word “architecture” describes the art or practice of designing and building structures. With this definition, it’s easy to see that architecture has been the center of philosophical debates since Roman times. While the definition of Enterprise Architecture (EA) is generally accepted, it’s still easily confused, misunderstood, pondered and debated. Translating EA speak into your organization’s lingo can improve the credibility, practicality, and ultimately the success of your EA program.

Credibility, Practicality, Success

Describing and selling an EA program to any organization is a challenge. Translating EA speak into your organization’s jargon will add credibility to your program. First, your organization’s knowledge workers will understand the program’s impact and value to their jobs. If they just shake their heads, but don’t understand the message, your credibility as a Chief Architect can be lost immediately. This instantly labels the Chief Architect as the book smart academic that can’t apply EA into real world scenarios.

Next, communicating EA in your organization’s vernacular will improve the practicality of your program. For example, if you’re selling a new technical pattern or the concepts of technical patterns, use the analogy of a blueprint. Help your customers conceptualize the message you’re sending.

Finally, the success of your EA program will depend on your ability to communicate to your organization. You must be able to connect with your constituents on their level. You simply can't expect them to understand and learn EA immediately. While this would make your job easier, it's just not practical to expect your organization to change that quickly.

In the end, dummying down your EA program's communications will add credibility, practicality, and ultimately aid in the program's success.

Pragmatic Advice

Use analogies wherever possible.
Use terminology your organization if familiar with. If your organization refers to standards as operation policies, call standards operation policies.
Don’t assume a shaking head equals comprehension and understanding.

Low-Hanging Fruit

noreply@blogger.com (Brad Meyers) — Thu, 25 Oct 2007 23:47:00 +0000

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.

Enterprise Architecture Communication Plan

noreply@blogger.com (Brad Meyers) — Mon, 17 Sep 2007 17:05:00 +0000

Would you communicate to your CEO the importance of adding the prefix “C_” to constants in your programming? Probably not. Nor would you explain to programmers the importance of tracing the business mission down through tactical initiatives in the organization.

Developing a communication plan is important not only for projects, but for Enterprise Architecture (EA) initiatives as well. Strong EA communication plans provide specialized messages for each stake holder group.

EA Communication Plan Importance

The EA communication plan is a key deliverable of your EA program implementation. This plan will sell stakeholder groups on EA and your program. The EA communication plan is important for several reasons. First, you may only have one chance to sell your message. Second, stakeholders will lose interest quickly if the message doesn’t pertain to them. Finally, a communication plan will provide a systematic method for delivering the EA message.

Specialized Messages for each Stakeholder Group

The EA communication plan should have distinct and specialized messages for each stakeholder group in the organization. For example, the Zachman Framework is based around six basic questions: what, how, where, who, when, and why; with six model types which relate to stakeholder groups: visionary, owner, designer, builder, implementer, and worker.

Stakeholder groups vary from organization to organization, but are on average similar across the board. Different EA Frameworks will use varied terminology to describe the stakeholders, but in the end they’re all the same.

Ultimately, a strong communication plan is critical to EA program success. The communication plan is ongoing and will never end.

Pragmatic Advice

Put your plan on paper.

Shop your plan to several knowledgeable people in your organization for advice.

Don’t forget you may only have one chance to sell your stakeholders.

Enterprise Architecture Metrics

noreply@blogger.com (Brad Meyers) — Tue, 04 Sep 2007 15:29:00 +0000

These are two great blog entries from Mike Walker about obtaining Enterprise Architecture metrics:

So Many Frameworks So Little Time

noreply@blogger.com (Brad Meyers) — Fri, 24 Aug 2007 21:20:00 +0000

By now you have sold your Enterprise Architecture (EA) program to your CXO. The next step is determining which EA framework to use.

A few examples of these frameworks are: Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture Framework (FEAF), National Association of Chief Information Officers (NASCIO) Framework, The Gartner Enterprise Architecture Framework, and the Zachman Framework.

Not All Frameworks Are Created Equal

Unfortunately none of these frameworks are complete; however, each have their strong points. For example, if you are a federal government agency, your best option would be FEAF just as NASCIO would be most appropriate for state government.

As an Enterprise Architect or an aspiring one, you must become intimate with these frameworks and your business in order to choose the right one. Identify the quick wins or low hanging fruits in your organization and then match the framework that best addresses those.

Once you have chosen a framework, you are one step closer to framing your organization.

Pragmatic Advice

Develop a list of your organization’s most troublesome areas or those which need addressed immediately. Think quick wins.
Compare that list to your existing EA framework research.
Seek peer advice when making your decision. For example, the Open Group has several Enterprise Architecture groups throughout the country or starts your own.
Choose your framework and start your planning.

Enterprise Architect: Why do you need one?

noreply@blogger.com (Brad Meyers) — Thu, 16 Aug 2007 13:45:00 +0000

This is a very good article from CIO magazine about the Enterprise Architect role:

http://www.cio.com/article/127751/Enterprise_Architect

Educate then sell the Value!

noreply@blogger.com (Brad Meyers) — Sun, 12 Aug 2007 02:41:00 +0000

You must sell your CXO on the Enterprise Architecture (EA) program before you begin. Before you can sell your CXO on EA, you must educate him/her on the value of EA.

Don’t use the fancy definitions that don’t make sense.

Don’t use fancy definitions when explaining EA. If you don’t catch your CXO’s attention in the first few sentences, then you’re not likely to sell him/her. Educate on the value.

Don’t try to explain the divisions of EA. Focus on the value.

Don’t waste time trying to explain the divisions between your Business, Information, and Technology Architectures. Instead focus on educating your CXO on the value of EA. Value statements could be as follows:

- Common future vision shared by the business and information technology group.
- Support the business through improved information sharing.
- EA provides guidance in business driven information technology solutions.
- EA provides a way to manage complexities of a large IT shop by setting enterprise-wide IT standards.
- Assurance to the business and customers that new IT systems are implemented through a consistent and measurable process.

Guilt always helps.

Make your CXO feel as if he/she is behind the curve. Several large organizations such as Intel, Microsoft, and BP practice EA. In addition, several federal agencies and state government agencies practice EA as well. By referencing other high-performing companies, you can instill the fact that practicing EA can create strategic value for your organization.

In the end, your EA program will never be successful unless your CXO has full buy-in. As you begin your EA Program, you’ll need you CXO’s credibility and backing to implement many of your new governance practices and EA processes. Without support, your EA program will never get off the ground.

Pragmatic Advice

Create an EA presentation that is no longer than five slides.
Get time on your CXO’s calendar (ask your boss to help).
Memorize your presentation.
Make sure you know enough to answer any high-level or detailed question your CXO may ask. Practice, Practice, Practice.
Remember you are now your company’s EA expert!

Getting Started

noreply@blogger.com (Brad Meyers) — Sat, 11 Aug 2007 23:38:00 +0000

Welcome to my Enterprise Architecture blog. The intent of this blog is to share my experiences in starting an Enterprise Architecture program from scratch.

Step 1: Commission an Enterprise Architecture Program
Step 2: ??????
Step 3: Profit

This blog focuses on Step 2.