Pragmatic Enterprise Architecture

Wednesday, October 8, 2008

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.

Labels:

Monday, February 18, 2008

Dummying it Down

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.


Labels: ,

Thursday, October 25, 2007

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.

Labels:

Monday, September 17, 2007

Enterprise Architecture Communication Plan

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.

Labels: ,

Tuesday, September 4, 2007

Enterprise Architecture Metrics

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



Labels: , ,

Friday, August 24, 2007

So Many Frameworks So Little Time

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.

Labels:

Thursday, August 16, 2007

Enterprise Architect: Why do you need one?

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

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

Labels: , , , ,