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 

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:


Direct link to audio podcast: 

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:

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):



Corporate Executive Board

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


TOGAF Maturity Model (Not Directly EA Maturity)




EA Maturity Model (Based on TOGAF & SEI CMMI)




NASCIO Enterprise Architecture Assessment




IT Capability Maturity Framework (IT-CMF)



British Columbia Institute of Technology

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


BC University - Enterprise Architecture Model.


IT Capability Maturity Framework (IT-CMF)

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:



· 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.


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.


Mike Walker's Blog: Using the Enterprise Architecture Capability Model to Drive a Maturity Model


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:

Mike Walker's Blog: Using the Enterprise Architecture Capability Model to Drive a Maturity Model

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 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.

Mike Walker's Blog: Using the Enterprise Architecture Capability Model to Drive a Maturity Model


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.

Mike Walker's Blog: Using the Enterprise Architecture Capability Model to Drive a Maturity Model


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.

Mike Walker's Blog: Using the Enterprise Architecture Capability Model to Drive a Maturity Model


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.