Mike Walker's Blog

MEGA annonces TOGAF and Business Architecture Offerings

Over the past few weeks MEGA an enterprise architecture (EA) tools provider, has recently announced  MEGA for the TOGAF framework and Business architecture solutions. I wanted to raise awareness of this update as a news item rather than an endorsement of the product. 

MEGA promises users that they can choose to begin an EA project using MEGA for TOGAF, then move seamlessly to a wider implementation using MEGA Process (BPMN Edition) and MEGA Architecture. It seems as if these announcements are aligning business architecture with the technology/solution architecture centric TOGAF. 

MEGA says they will aid TOGAF practitioners in these ways:

• Ensure EA project success by following the comprehensive Architecture Development Method (ADM).
• Facilitate project communication to all stakeholders with the collaborative development of TOGAF 9 deliverables.
• Customize the implementation of TOGAF and ensure all projects deliverables are aligned.
• Build current and future state transition architectures and compare them.
• Identify, document, and publish technical reference models.

MEGA also communicates the value proposition to business architects as well:

• assess and streamline major investments
• improve customer information management
• consolidate post-merger, post-acquisition business units and product lines
• incorporate outsourced and partner solutions
• conform to compliance and audit requirements

IBM Rational Enterprise Architecture Program

Scott McBride wrote a post announcing the IBM Rational Enterprise Architecture Program a few days ago. This isn't a new program by any means. This program was established before in partnership with Carnegie Mellon University. It does look like the program has been revamped with updated a new structure and approach, updated courseware, materials and participation. 

The new participation now includes a newly formed EA Institute called the Enterprise Architecture Institute (iEAi) that looks to of been established and ran primarily by Dr. Scott Bernard.

Some of my initial thoughts are:

• Another certification program in the market that is further complicating the EA 
• Looks to be vendor driven which means there is a strong tie to IBM products, namely Rational (very obvious from the title and called out in the program description)
• With the partnership with an external body that may be good but until someone goes through it and evaluates it's tough to tell how unbiased it really is. 
• I understand that IBM had a very close alignment (all their internal architects used the TOGAF + IBM materials to certify) with the Open Group and TOGAF. Has that relationship been severed? If so, why?
• What I do like is they are taking a best of breed approach and not just looking at one EA body.

It's a little too early to tell where this is going or if it will have traction but I am definitely interested in learning more about it. 

Here are the details of the program:

The three courses are Basics of Enterprise Architecture, Applied Enterprise Architecture, and Advanced Enterprise Architecture.  The courses are designed for those who are, or will be, participating in an enterprise architecture program, or those who have responsibility for the outcomes of an EA program.  You will learn how to make a business case for EA, the importance and history of enterprise architecture frameworks, how to identify the capabilities for a future architecture, and how use EA as a means of aligning the organization to articulated business goals with emphasis on IT investments, to name just a few of the topics.  Perhaps most is important is how EA integrates with the governance and decision-making processes across the enterprise.

• Learn how organizations can become more agile and competitive
  
• Better align strategic goals, business activities, and supporting technologies
  
• Understand how EA provides context for best practices with SOA, ITIL, COBIT,OO, and Cloud Computing
  
• Assess the management of a business and technology portfolio
  
• Better manage at the enterprise and systems levels
  
• Develop a framework for business/technology planning and decision-making
  
• Identify and develop new and enhanced capabilities to gain competitive advantage
  
• Refine the design and implementation of workflow, systems, and infrastructure
  
• Create reusable architectural building blocks that promote business transformation
  
• Attain improved compliance and more predictable project outcomes
  
• Improve the lifecycle of systems development, risk management, and security

Link to Program: http://www-304.ibm.com/jct03001c/services/learning/ites.wss/zz/en?pageType=page&c=O890082K19654X06 

The State of Enterprise Architecture

Recently there was a panel discussion regarding "The State of Enterprise Architecture: Vast Promise or Lost Opportunity?". It was actually a very interesting panel discussion. Take a peek when you have a moment.

Here are a few excerpts that I really agree with:

In a lot of cases, we make a big deal about the technical expertise of architects, but in a lot of architectural engagements that I have been involved in, I didn’t actually know anything at all about the subject matter that I was being asked to architect.

What I did know how to do was ask the right questions, find the people who knew the answers to those, and help the people who actually had the information orchestrate, arrange, and understand it in a way that allowed them to solve the problem that they really had.

This is very true. It is all about asking the right people the right questions and even more often it's about asking those same people the next two or three questions that are the real answers you are looking for. This also isn't something that is easy for anyone to pick up. While the occasional cheat sheet/checklist is good as a refresher to make sure you tied everything off it should be used as the end all be all. Questions alone with out the right people asking them are not effective.

In terms of its maturity as a profession, it may be 100 or 200 years back, compared to law or medicine, but on the other hand, the quality of the practice is much more like where medicine and law were 50 year, 25 years ago.

I have to agree on a lot of fronts. It is somewhat the EA Wild West out here. There are so many competing frameworks, certifications and methods that it is difficult for the EA community to have a common vocabulary or measurement.

The fundamental with leadership in EA is that architects don’t own things. They are not responsible for the business processes. They are not responsible for the sales results. They are responsible for leading a group of people to that transformation, to that happy place, or to the end-state that you're trying to achieve.

Enterprise Architects only have influence to the organization where it needs to be. This is both good and bad. I think that the previous comment made about the quality of the EA practice being equivalent to 25 to 50 years ago wouldn't be the case if EA's didn't have to "earn there keep" as influencers. They have to earn there stripes to be effective in the industry. This is the true test of a good EA.

If you do not lead and do not take the risk to lead, the transformation won’t occur.

As an EA it's all about putting yourself out there and taking calculated risks for yourself, not necessarily for the company.

Again, very good panel with Dana Gardner,Jeanne Ross, Dave Hornford and Len Fehskens.

For more information and the full article:

• Transcript (Download)
• iTunes/iPod and Podcast.com

[UPDATE]

Direct link to audio podcast: https://www.opengroup.org/events/podcasts/BriefingsDirect-State%20of%20Enterprise%20Architecture%20With%20The%20Open%20Group.mp3 

IEEE 1471 adopted as ISO/IEC 42010:2007

If there was one standard that I believe has high value in maturing it is IEEE 1471. It is the underpinning behind how we describe our architectures. Unfortunately, there is little momentum behind this but we are now seeing incremental movement on it. As we talked about in 2007 in the post, Architecture Modeling - IEEE 1471 has been adopted by ISO there was adoption by ISO but there has been somewhat radio silence.

Now in May of this year, IEEE 1471 has continued efforts to be incorporated by ISO as ISO/IEC 42010:2007 and is now communicating some of it's revised goals.

For those that are not familiar with IEEE 1471 it is the standard for describing architectures. It provides a meta-model that illustrates the relationship of information.

The new joint revision goals:

• Widen the scope of application from software-intensive systems to general systems architecture (including enterprise architecture);
• Harmonize with the ISO systems engineering (ISO 15288) and software engineering (ISO 12207) life cycle processes; and
• Produce common vocabulary to align terms and concepts with other ISO architecture efforts, including RM-ODP (ISO 10746) and GERAM (ISO 15704).

For more information on this check out:

• Architecture Modeling - IEEE 1471 has been adopted by ISO
• Can you Easily Compare EA Frameworks?
• Impact Assessment of IEEE 1471 on TOGAF
• http://www.iso-architecture.org/ieee-1471/index.html
• http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45991

Enterprise Architecture Industry Maturity Models

In my previous post entitled “Ways to apply the Enterprise Architecture Capability Model (EACM)”, I talked about how to leverage the EACM to build a maturity model. But what about those other EA Maturity Models?

Here is a compile of the maturity models in the EA industry today:

 

MIT CIST EA Maturity Model

Third Party Blog Source: The role of Architecture in the Enterprise

Book: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution

Extended Articles (if you have access): http://cisr.mit.edu/blog/documents/2004_07_2B_MaturityMatters.pdf

 

 

Corporate Executive Board

Source (if you have access): Enterprise Architecture Maturity Model

 

TOGAF Maturity Model (Not Directly EA Maturity)

Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap30.html

 

EA Maturity Model (Based on TOGAF & SEI CMMI)

Source: http://iea.wikidot.com/ea-maturity-model

 

NASCIO Enterprise Architecture Assessment

Source: http://www.nascio.org/publications/documents/nascio-eamm.pdf

 

IT Capability Maturity Framework (IT-CMF)

Source: http://ivi.nuim.ie/ITCMF/cps/cap_eam.shtml

 

British Columbia Institute of Technology

Leo de Sousa, Manager, Business Application Services and Enterprise Architecture, British Columbia Institute of Technology

Source: http://leodesousa.ca/tag/capability-maturity-model/

 

IT Capability Maturity Framework (IT-CMF)

http://ivi.nuim.ie/ITCMF/cps/cap_eam.shtml

Maturity Model Characteristics vs. Capabilities

As I was researching the current  industry Enterprise Architecture Capability Models I ran across an interesting observation. I  found that most of the EA Maturity Models (even TOGAF) actually derive or are heavily influenced by The Department of Commerce Architecture Capability Model (ACMM).

What is interesting about this is that instead of focusing on true capabilities, they rather focus on characteristics. Below you can see this in the example from Department of Commerce ACMM.

 

 

As a first step and initial cut at an EA Maturity Model I think this was a large leap forward. But is it the end state? I don’t think so. While it was a good first step I think we can mature on this baseline. The key first step is to have a bit better classification on what we are evaluating and assessing through the Maturity Model. That brings us to the topic of this post.

Let’s look at comparing these two aspects:

Characteristics	Capabilities
· Ad Hoc · Mixed Abstraction · Pointed · Context Missing	· Defined · Abstraction Defined · Very Pointed · Context Defined

 

The key differences here is the evolution of these key ideals into something more structured and at a higher level abstraction.

 

Technorati Tags: Enterprise Architecture,Maturity Model

Using the Enterprise Architecture Capability Model to Drive a Maturity Model

In this series of posts I am talking about the Enterprise Architecture Maturity Model (EACM) along with it’s usages. In part 1, I provide an overview of the EACM in the post “The Enterprise Architecture Capability Model (EACM) ”, and in the second post “Ways to apply the Enterprise Architecture Capability Model (EACM)”  I talk about the generic usages.

In this post I will be much more specific with one of those usages, maturity. This is the most obvious and common usage of EA capabilities as they are known today. Unfortunately, I haven’t found many other references out there for EA Capabilities quite like how I have defined them. The referenced Maturity Model in the image below comes from the NASCIO where they use characteristics rather than capabilities. The approach is the same though. The challenge with current EA maturity models is they are incomplete and ad-hoc in their assessments. There isn’t one industry standard model that is universally accepted. The Open Group doesn’t have one and the assessments in the public sector is still evolving.

 

 

When you look at the relationships between the EACM and the EA Maturity Model it does a few things for us:

1. Establishes Criteria – this helps us understand the criteria in which we will populate the EA Maturity Model. While the EACM provides the source content to be populated it also provides a good landscape on what complete looks like.
2. Guides – When refining the Maturity Model, the EA Maturity Assessment or updating an active assessment content, the EACM is a guide for the development of the Maturity Model. It provides a level of separation of concerns from the model.
3. Context – When performing an assessment, it often helpful to go back to a reference point to take a broader look at the space. The EACM provides the entire landscape of EA. So if there is confusion of where a detailed assessment fits, you can always peek up and get context of where you are.

 

When you apply the EACM to either your company’s existing model, an industry model or from another source you can leverage the EACM to heavily influence the maturity model as shown below:

By implementing a maturity model in this fashion you implement a more refined classification system into the maturity assessment. This improves the overall effectiveness of the EA assessment.

There are 4 areas shown above. The first is the influence of the EACM.

The second is the maturity levels themselves. These can be influenced by the EACM. However the EACM is not the primary driver behind these levels. These are either custom for your organization or they are based on some industry standard model. The one referenced above and below is from http://iea.wikidot.com/ea-maturity-model that pulls from both TOGAF and Carnegie-Mellon Software Engineering Institute’s Capability Maturity Model for Software CMMI. There are other models as well that are very good. This was pulled for illustrative purposes.

 

The third is the major level one capability areas that are heavily influenced by the EACM. Ideally there should be a one to one mapping to the capabilities. This ensures that you are covering the entire domain of EA in someway. Even if your current maturity level doesn’t allow you to leverage certain capabilities it can provide you with an idea of what areas you can move into.

 

The fourth area is the detail in the cells, these are the capabilities that would be implemented at this level. There isn’t a one to one map from all the capabilities in the EACM to each maturity level but rather an orchestration for each level of maturity. The EACM provides baseline for establishing maturity levels, areas of capability and the levels of capability as shown below.

 

Once the model is implemented your not done. An assessment tool or questioner will need to be built to collect and populate the model. I have built this for my organization and I will see if I can share those questions with all of you.

 

After the assessment there is one last step. That is a transformation plan. A transformation plan should collected all the inputs from the process of the assessing the maturity of the EA capability of the organization. Through that process you will collect the following:

• The current level of maturity
• The desired state of maturity
• Gaps, issues and concerns
• Opportunities
• Inhibitors
• Refined plan

 

You maybe surprised by the last bullet, Refined plan. The origination will have an idea where they want to go at the beginning of the process, but when you identify all the above you will find that there maybe tweaks to the desired state.

 

Technorati Tags: Enteprise Architecture,Maturity Model,EA Maturity

Ways to apply the Enterprise Architecture Capability Model (EACM)

In my last post I showed the Enterprise Architecture Capability Model (EACM). This was developed for a very specific purpose for my Enterprise Architecture organization. It allowed my to articulate the entire landscape of Enterprise Architecture to enable key conversations. After I had created it,  I took a step back and saw that this could be used for so much more. Not only for my EA organization but for others as well. So it came to now that we had created the Enterprise Architecture Capability Model (EACM), what do we do with it?

Here are a few usage patterns that the EACM can be applied to:

• Maturity Model – This is the most obvious and common usage of EA capabilities as they are known today. Unfortunately, I haven’t found many other references out there for EA Capabilities quite like how I have defined them. The referenced Maturity Model in the image below comes from the NASCIO where they use characteristics rather than capabilities. The approach is the same though. The challenge with current EA maturity models is they are incomplete and ad-hoc in their assessments. There isn’t one industry standard model that is universally accepted. The Open Group doesn’t have one and the assessments in the public sector is still evolving.

• Communications Tool – If used effectively the EACM can be a highly powerful tool to use as a collaboration and communication tool. This can aid an Enterprise Architect in his/her interactions with either IT or the business unit representatives. It facilitates the conversation around: describing the services, activities, maturity, roles, key definitions and vocabulary, context setting or facilitate and resolve conflict over what EA does and doesn’t do.

• Planning Tool – Determining what EA does is hard enough, but layering on that to what it should do can be a down right impossible task. The EACM combined with a maturity assessment can deliver a tool to guide the EA planning process. EACM provides a baseline for all in which EA does. If there are missing capabilities in your organization that are on the model they can be easily mapped and planned.

• Enhance & Validate Services – Along with planning what new and augmented capabilities are needed you may want to also have a life cycle around not only you organization but also your EA office as well. EACM provides a good baseline to always go back to. Also, your organization may also be doing things that complement or extend the EACM. When you have a life cycle it isn’t just a one way street. You may find yourself modifying the EACM as well. These life cycle processes provide a controlled and predicable way of updating the EACM.

 

 

Those are a few of a potential many ways to leverage the EACM. There are many more but I have seen these as some of the bigger ticket usage patterns.

 

Technorati Tags: Enterprise Architecture,EACM,EA Capability,Maturity Model

The Enterprise Architecture Capability Model (EACM)

As I am building out an Office of Enterprise Architecture, I often hear and get the question, “what is Enterprise Architecture?”. We see this industry wide across the world. We EA bloggers have compiled and distilled definitions for the past few years. Below are some links that show this:

• http://en.wikipedia.org/wiki/Enterprise_architecture
• The Enterprise Architecture Definition Collection One, Two & Three
• Aggregates of Open Group and Gartner
• IT Architecture is not Enterprise Architecture

So when I think through the answer the response is always a bit complex.  I think through who I am talking to and their level of knowledge in this domain and then directly to how I am going to describe. I think through the categories of activities, the Who, What, When, Where and Why decomposition and abstractions. 

I then got to the point where I think to myself, why am I going through this painful exercise every other day. Isn’t there a great representation of of the Enterprise Architecture space. So naturally, I went to one of the greatest tools in an EA’s arsenal, Google. I went through blogs, articles, analyst materials and even EA frameworks. There wasn’t anything that could be my go to reference for facilitating the conversation.

So, I guess that means I have to create it, huh? That’s exactly what I did. So how did I go about it? I certainly wasn’t going to start with trying to come up with a cohesive definition that everyone would debate. Instead, I decided that I was going to take another approach.

A capability driven approach is what needs to be taken in this case. Instead of a generic definition, let’s define the space by talking about the capabilities that comprise Enterprise Architecture. This will provide the breadth and organization to describing the domain.

So what is meant by a capability? Often times this term is used in the Business Capability context. But if you is those same principles for the design of a business capability you can define a capability as:

• Abstraction of processes, activities, people and technology
• Used to provide a level of breadth without losing organization or intent
• Remove the complexities of the “lines”
• To only be the starting point, not the end to facilitate a higher level conversation about a specific domain/area

 

The Enterprise Architecture Capability Model (EACM)

 

In first draft this is what I have come up with as being representative of the Enterprise Architecture Domain. It shows the level one and two level capabilities. There will need to be more work on the level three capabilities. This is where it will get real interesting.

A great way to get people on board with the space would be as simple as using this a a quick reference. Printing it out am laminating it for cube/office walls. It has most certainly help me in my conversations.

It would be interesting to get all of your thoughts on this.

 

Technorati Tags: Enterprise Architecture,EACM,Enterprise Architecture Capability Model,Capability Models

The 50 smartest people in Tech

Interesting article on the smartest people in tech. I also had to give a plug to my leader of IV Nathan. 

See the article here: http://tech.fortune.cnn.com/2010/07/09/the-50-smartest-people-in-tech/

• How we chose the smartest people in tech

Co-founder, Intellectual Ventures

Microsoft's first chief technology officer is a man of many passions (he's a serious foodie, and his nature photography has been featured in books), but his true love is innovation. At Intellectual Ventures, which funds inventors, Myhrvold, 50, is setting out to prove that funding inventions -- as opposed to business ideas -- can be as lucrative as conventional venture capital. IV today has more than 30,000 intellectual-property assets, acquired and developed internally, many of which seem years away from commercialization, much less an IPO. (Example: an invention to halt global warming that involves creating a thin film of sulfur dioxide around the planet.) But Myhrvold has assembled such impressive mind power that Bill Gates (no slouch in the IQ department) regularly stops by to brainstorm. --B.K.