Open CA Gets Top Pay in Enterprise Architecture Certifications

As I was doing some market research for my EA’s competency driven strategy I ran across an interesting article from late 2012 that validates the importance of a well educated, fully rounded and even certified Enterprise Architect. The article, “23 IT Certifications That Mean Higher Pay” posted on in September of 2012, shows that companies value these skills and are willing to pay more. 

The data was pulled from the Foote Research Group quarterly 2012 IT Skills Demand and Pay Trends Report and its CEO David Foote spoke with about how you can use certifications to get employers to show you the money.

The article separates the list into three tiers of percent added to base pay from the lowest to highest:

  • 8% – 13% Added to Base
  • 10% – 15% Added to Base
  • 12% – 16% Added to Base


In the highest tier of 12% to 16% Open Group Certified Architect (Open CA) gets top ranking in Enterprise Architecture certifications for largest percent premium added to your base salary. I received my Open CA certification in 2011 and was nominated to the certification board. It was quite the honor for both.

Afterwards I really wanted top share my experiences and write up a condensed version of what Open CA really was. You can find this information in the post entitled, “The Open Group Certified Architect (Open CA) Program Distilled“.  

Two things I think this article says about our industry:

  1. Baseline of Skills and Competencies – Whether it is Open CA or any other EA certification, I believe this shows a natural maturing in the EA discipline. The industry is bringing together a set of common and recognized set of skills and competencies through these certifications. In this case the EA market has recoginized Open CA as the most popular and perhaps the defacto standard for EA skills and competencies. 
  2. Competencies of Skills – I liked seeing Open CA certification on this list rather than TOGAF or a Zachman certification (there are many others besides these two). The reason I prefer Open CA is because it is  competency based. Meaning it’s about how and what you have done as a practitioner and not about what you know from reading a book or taking a class.  


For more information on Open CA: 


Also of note in that tier with Open CA is the Program Management Professional (PgMP) certification.


TOGAF Demystification Series: The Truth behind the TOGAF Standard Creation


I've only heard this one a few times but since this myth was recently referenced in one of the comments of the post,  "TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex" I thought it would be good to elevate it up to a post in case there was similar misconceptions out there.

To set the stage, the basis for this myth is that the creation of the TOGAF standard is done so by an elite and exclusive group of individuals in the EA community the jet set around the world to sunny tropical vacation destinations all the while eating all the free bagels and coffee one can consume.

That sounds like a lot of fun. Sign me up!

It's too bad this isn't real. 

So let's break this apart the myth into three digestible parts:

  1. Set of Elite Individuals Driving the Standard
  2. TOGAF Excludes Industry Developments and Research
  3. The Standard is Developed in Leisurely Tropical Destinations

#1 – Set of Elite of Individuals Driving the Standard

This is by far the easiest one to dispel.  What you will find from the Open Group charter is that this concept goes against the grain of the core principles of the Open Group. This not only applies to  TOGAF but all of the standards that the Open Group creates.  You can find that this  dates all the way back to the UNIX days.  The process is open to any person employed by a member company can participate with no zero discrimination on any sort of politics, company status or individual status.

You can find this  statement on the Open Group's public facing website describing the process:

All member organizations of the Open Group are entitled to participate in one or more of The Open Group Forums — vendor-neutral environments where members share knowledge and resources, and collaborate on developing open IT standards and certifications. Covering a range of technical, business, legal and regulatory issues, each Open Group Forum addresses a specific functional area, and is fully supported by The Open Group’s resources.


The Open Group Forums and Work Groups are governed by the Open Group Standards Process which is governed by the following principles:

  • Openness - Standards are developed in an open process.
  • Consensus - Standards are based upon the consensus of the parties involved.
  • Timely and Deterministic Process - Standards are developed using a deterministic process that delivers standards in a predictable and timely manner.
  • Public Availability of Published Standards - Standards once published are made publicly available.
  • No Legal Impediment to Implementation or Adoption - There must be no legal impediment to implementation or adoption of an Open Group Standard.
  • Confidentiality - Material is kept confidential until published by The Open Group.

You can see evidence from my story referenced in the post  "TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex" where I was able to come into the forum as a newcomer to the Architecture Forum and was able to effect change. I didn't have to be part of a ficticuiuos "good old club".

#2 - TOGAF Excludes Industry Developments and Research

The Open Group works just like most standards bodies do (that I know of). The standard is driven by it's members. The Open Group is an administrative funtion that helps enables its members rather than creating the standard. From my own experiences, I contrast this to my time in the financial services industry. I have participated in the following below and had indirect interaction with more:

  • IFX
  • FSTC
  • MBA 
  • and many others

Each one of these standards bodies operate in a similar way as the Open Group. It is incumbent upon the members to bring the latest developments back to the forum to be vetted by the industry before getting published. There isn't a R&D arm that goes out and discovers what the standard should be and go and publish. The role of the standards body to to create to forum in which these experts in the industry can distill proven practices and not fads and emerging trends.

Why is this important to do it this way? It think it all boils down to the following attributes:

  • Trustworthy – A standard you know has been vetted by your peers in the industry
  • Credible – Give it was developed by your peers, there is a very high degree of it is based on real world deployments and lessons learned. 
  • Foundational – This isn't the latest and greatest but rather the foundational proven practices in the industry.
  • Low Risk – Given all the above factors this results in a lower risk of just going out to the market and pulling the trend of the year off the shelf and running with it. Given that these are proven practices, actually implemented with success it lowers your risk.  

Personally, this is what I want form a standards body. I want the standards body (in this case TOGAF)   to tell me what is the most vetted method and framework that I can use as a base for my arhiecture efforts, then I can apply the other emerging trends or other not so mainstream ideals to my company. This manages my risk exposure to my company.

If the standards body did the reverse and adopted all the latest ideas and trends I would imagine that there would be a great deal of redundancy, conflicts and lack of guidance on how to apply as a result. I'm personally not interested in that scenario. 

#3 - The Standard is Developed in Leisurely Tropical Destinations

This one isn't a very well informed aspect of this myth. I can tell you that I haven't been a fan of the some of the destinations picked and very few of these have actually been at a beach. 

This comes from a very specific comment below:

One does not need to join the forum and participate at meetings in sunny places in order to contribute to the EA field. In fact it should be the other way around. 

NOTE: I don't have full insight to the specific policies, procedures and overall plans that the conference planners have with regards to this specific myth. I will share with you what I do know of the process. I would imagine it's pretty close but if the Open Group has any further clarifications I welcome them as a revision to this post. 

I don't think there is a simple one answer for selection of destination or why the why are the member meetings are the way they are. There are a two core drivers you I think you have to understand about the member meetings (TOGAF development in the Architecture Forum) to really answer the question. Those are:

  • Multi-Purpose Events – The events where the Architecture forum meets are multi-purposed in nature. They hold the practitioner conference, certification, forum and workgroup activities.
  • Maximize Value for Customers – By linking the development of TOGAF to the practitioner conference it serves as a way to consolidate travel, foster networking, collaboration and increase the overall in take knowledge through the conference materials and presenters. 

Given these two drivers and let's say the myth is true (it's not) then this would be no different than any other mainstream conference. Looking at both pure technology, analyst and industry wide all of which go to resorts, beaches or tourist destinations. But I haven't seen one Open Group conference in Vegas yet. I can't count the number of times I've been to a standards meeting in Vegas.

So to be factual I pulled the conference locations and bolded the tourist detonations (that I would consider) . It's interesting that there isn't too many beaches listed:

List of 2013 Open Group conferences: Newport Beach, Riyadh, Saudi Arabia, Abu Dhabi, UAE, Mumbai, India, New Delhi, India, Sydney, Philadelphia, London

List of 2012 Open Group conferencesBarcelona, Washington DC, Sao Paulo, Brazil, Dubai, UAECannes, France, San Francisco

Now you could contrast that with other conferences and standards setting meetings as well for example the insurance industry standard ACORD events where they too combine conference with standards meetings. 


Again with this post I want to have a fact based conversation about this topic. Like many others I think this is a perception issue. At first glance, this may seem true (or at some parts of this myth) but if we take a closer look I think you will see it as I do that these are just myths. 

I do think there is an opportunity for the Open Group to do as I am doing, proactively dispel these myths by publishing and sharing these views (if they agree w/ my views as I'm not sponsored by the Open Group to write any of this content) with the architecture community. It could be a learning series, a set of FAQs or even going out to online forums like Twitter and LinkedIn to address some of these concerns.  

Again, I hope this helps and if you want to contribute to the conversation I welcome you to join in on the comments on this post. 

Big Data’s Big Impact on Enterprise IT– The Open Group Panel Discussion

Today @Dana_Gardner posted on twitter The Open Group Panel discussion on Big Data’s Big Impact on Enterprise IT. It worth a watch as it gave a good primer on general concerns in the industry. My question to the panel got a cut due to a truncation issue so it may not have made a lot of sense but I wanted the panel to go deeper into the challenges they were expressing and give practical and applied guidance to the audience on how to confront some of these challenges, specifically on the compliance, risk and data segmentation areas. 

Below is the video and the description:

A panel of experts explores how big data changes the status quo for architecting the enterprise. Learn how enterprises should anticipate and correct the effects and impacts of big data, as well the simultaneous impacts of cloud and mobile computing.

My Architecture & Governance Magizine Article: Business Architecture & Best Practices

Mike Walker Architecture and Governance Magazine

The new issue of Architecture and Governance Magazine is out. This issues is centered around the Business Architecture practice with elements of Information Architecture. It’s tiled, “Business Architecture: The Blueprint for Success?”

I was fortunate enough to be included in this edition. I speak about the definition of the Business and Information Architecture domains, their relationship to each other, and enabling techniques and models supporting each. 

You can find my article here: Walker Talks Business Architecture and the Best Practices for Using It 


To subscribe to A&G check it out at:

TOGAF Demystification Series: TOGAF Doesn’t Play Well With Others

Fit Together

In this post in the TOGAF demystification series I will talk about how well or not so well TOGAF plays with other frameworks in the industry. In my last post this topic was brought up and I see it on the LinkedIn forums as well.

So let’s talk about this myth that TOGAF doesn’t play well with other frameworks. So what do I mean by that? The myth is that TOGAF is all about TOGAF or is monolithic in nature. This is far from the truth. TOGAF is a truly unique framework in that it really does embrace the notion of a better together story with other frameworks and approaches to solving problems. This better together story is all about bringing in other frameworks to complement, reuse and ultimately reduce the amount of duplicate methods in the industry. The thought process must be, if it works for them then it should work for us too. 

A great example of this is at the absolute core of TOGAF. A core concept of “Architecture” is not defined by TOGAF but rather by ISO/IEC 42010:2007 (formally known as IEEE 1471). Of all areas to define yourself and be justified, TOGAF doesn’t do so. It takes in the definition and applies it to the architecture framework. TOGAF provides guidance around the definition and meta-model given that it was created outside any one methodology / framework. 

Below is the actual text from TOGAF:

TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 – ensuring that usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard – and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 3. Definitions and Part IV, 35. Architectural Artifacts.

As you can see above, while many other frameworks feel that they have to make it their own in an self-interested type of way, this isn’t the case with TOGAF. There is clear evidence that that TOGAF is doesn’t have the “must be invented here” syndrome  and will not duplicate the approaches in other methods. I applaud them for that level of leadership in the industry where it is a common practice in the overall technology and architecture fields respectively to do deliberately duplicate meanings, approaches and overall methods for doing things. 

One last area of note, in most phases in the ADM the first step is essentially to establish how you want to perform that phase. In this step you as the EA are to select the methods, approaches, reference models, architecture or standards and apply them to the problem you are solving in that phase. This is essentially saying is:

  • Not every architectural problem needs a prescriptive process. 
  • USE YOUR JUDGEMENT when applying architecture process and rigor.
  • If TOGAF doesn’t have something that solves your problem fill the gap.
  • Reusable architecture building blocks are the key to accelerating predictable results, TOGAF is architected to support this.

Lastly, TOGAF has published many mappings to other frameworks. In the specification you can find references to ISO, IEEE , PMI, Zachman and DODAF to name a few.

Below is a listing of some of those mappings (not all inclusive):


Note: Some of these mappings were done with older versions of TOGAF. However, there should be minimal gaps and provides the intent of a better together story. 

TOGAF Demystification Series: Comparing TOGAF to Other Frameworks

 Apples and Oranges

For the second post in the TOGAF Demystification series, let’s tackle the common topic of TOGAF to other frameworks. Over the years I’ve heard the debates between passionate EA’s and seen the seemingly endless posts on LinkedIn and blogs on this topic. One thing is for sure, this is a topic of much interest.  

While the driver is often to figure out if there is a better enterprise architecture framework out there, sometimes our enthusiasm gets the better of us and turns into a heated debate with a lose of the original reason why we need to choose a framework. 

This post will not go into:

  • TOGAF compared to [Insert Framework Here]
  • Detailed comparison of all frameworks
  • Why TOGAF is better or worse than other frameworks
  • TOGAF features and evaluation to other  frameworks  

Rather than directly evaluate or compare, I think it is more beneficial to take a step back. The goal here is to provide a way to think about comparing TOGAF. I do believe that not all roads lead to TOGAF. That is the reason for not publishing the reason why all of you should adopt TOGAF. I believe that is fundamentally wrong. You must look at what is important to your organization and make the call based on all those drivers. 

So in this post will will  look at the following:

  • what are the common misconceptions when evaluating
  • what approach should we use
  • is there a comparison frame of a mental frame for evaluating these frameworks. 

Simply put, this post serves as a way to think about comparing and contrasting frameworks.

If you are looking for an evaluation of frameworks, I have a resource for you. Back in 2007,  I ran the practice of Enterprise Architecture for the Architecture Strategy Team at Microsoft. At the time, my team contracted Roger Sessions to write, “A Comparison of the Top Four Enterprise-Architecture Methodologies” to be hosted on the Microsoft Enterprise Architecture portal that I ran. Since then it has gotten quite a bit of attention. It is due for a refresh as it is clearly out of date now. It was a good first start but needs more quantification and classification to really do these justice. I am looking at a refresh of that whitepaper and will have an update soon. Stay Tuned!

Apples and Oranges

I would like to start us off with the notion that not all frameworks are the same and not all serve the same purpose. In many ways these comparisons have been like comparing apples and oranges. For a number of years I have observed that architects tend to compare these frameworks as if they all were built with the same goal in mind. With this logic there is no real winners in the comparison, just confusion. 

TOGAF is routinely compared to other frameworks. In many instances it is unfairly compared to other frameworks that serve another purpose and/or outcome. We first have to split these into two areas:

  1. Area of Focus – Defines the disciplined area of focus of the framework.  Examples would be: Service Management, Program Management, Architecture Development, Software Development, etc.
  2. Type of Architecture Framework – A defined set of segmentations to identify the logical groupings of frameworks with similar origins, goals and outcomes.  

We first want to look at the area of focus when comparing frameworks. We want to make sure we are in the “same ballpark” when we compare. By looking at this we can use it as the qualifier to quickly see if we compare at all. For example, if you wanted to determine what is the idea EA framework for your orginization it doesn’t make much sense to compare frameworks ITIL vs. TOGAF or COBIT vs. TOGAF (outside edge cases where this is done deliberately). These frameworks have completely different:

  • problems it trying to solve
  • outcomes
  • supporting processes
  • stakeholders, suppliers and customers
  • deliverables
When we evaluate frameworks that were built to support a different outcome than the outcome we are looking for in EA the comparison is fundamentally flawed. 

Once we determine that we are “in the same ballpark” and comparing architecture frameworks, we then can look at the the types of architecture frameworks. 

Three major types of architecture frameworks:

  • General Purpose – frameworks that are purposefully generic in application and built to be highly reusable and modular to support a broad range of outcomes, industries, skills and maturity levels. Examples include: TOGAF, Zachman
  • Business Specific – frameworks driven by a set of defined business or industry concerns. Examples include: MODAF, FEAF, TEAF, DODAF
  • Vendor Specific – frameworks that are aligned to specific offerings provided by that vendors. Examples include: Oracle EA, Microsoft Value Realization Framework, Cap Gemini IAF (deprecated and merged w/ TOGAF)

Making Comparisons

So far we haven’t really talked about evaluating or comparing frameworks. What we have done is set some important data points for us that will be a large part of our evaluation.

According to Wikipedia, evaluation is defined as such:

Evaluation is a systematic determination of a subject’s merit, worth and significance, using criteria governed by a set of standards. It can assist an organization to assess any aim, realisable concept/proposal, or any alternative, to help in decision-making; or to ascertain the degree of achievement or value in regard to the aim and objectives and results of any such action that has been completed.

There are two key points that I’ve highlighted, merit (what I want to get out of this) and structured and governed criteria. 

A simple 7 step full lifecycle evaluation process that I use for an evaluation of an architecture framework has the following steps:

  1. Rational – Why I’m evaluating architecture frameworks and what are the key drivers. This typically will result in a set of the critical questions that need answered with some well structured criteria. 
  2. Identification – The goal of this step is to quickly and qualitatively to identify a “short list” of architecture frameworks that align to the problems we are trying to solve with the architecture framework (Step 1 – Rational). We do this by:
    1. Apply the rational or value driver statements to the list of frameworks available. 
    2. Architecture Framework Area of Focus (discussed above) – This allows us to quickly get to a smaller set of frameworks to evaluate
    3. Architecture Framework Type (discussed above) – This further cuts the list down to a finite set of frameworks. 
  3. Trade-Offs – With the short list of architecture frameworks go through a well disciplined trade-off analysis with the identification criteria above. This should identify all the change management challenges that you will encounter with people (maturity level, skills, etc.), tools / technology and process changes that will be needed. This should lead to the overall costs and benefits that address the rational subsequent value drivers. 
  4. Selection – The selection of the architecture framework with well defined implications of the decision with the criteria of selection. 
  5. Implementation – Phased implementation of the architecture framework. 
  6. Govern  – Established body that governs the architecture framework health with measurements of effectiveness in the organization. 
  7. Validity – After a period of time has elapsed (sometimes yearly) a life-cycle is implemented around the architecture framework to ensure that that the organization is getting maximum value out of the framework. 



When you are evaluating TOGAF for your needs there isn’t an easy or direct answer. You have to go through a process to determine what framework is right for you. This post nor a LinkedIn forum will be able to answer that question for you. Start with what is important for your organization. Meaning, what drives value for you. If you’re a government agency, it makes sense to start off with one of the popular government EA frameworks such as: DODAF, MODAF, TEAF, FEAF etc. If you are in an industry segment which has a framework defined like telecommunications then TMForum is a leading candidate.

Since TOGAF is a general purpose framework, I tend to look at TOGAF as a framework of frameworks. It is really built to be the “platform”. It was designed with reusability, modularity and assembly as first class citizens. It will not give you the prescriptive process, rather it is descriptive of the areas of concern and YOU choose what is “fit for purpose” for your problem set.  As I mentioned in my last post, this does add a layer of complexity but I do believe it provides the ability to come to the fastest possible value to market in an architecturally rigorous way.

If you are comparing TOGAF to FEAF or a vendor framework you are not comparing apples to apples. These architecture frameworks have different inputs and outputs in mind. Comparing TOGAF to Zachman is a closer fit. However there isn’t many more general purpose frameworks that are “open source” like TOGAF. A fair comparison would be MODAF vs. FEAF or Microsoft VFR to Oracle EA Framework. These are comparing the same value drivers. But when you mix these types it causes confusion and endless debate. 

If you are looking for extended information on this topic I will be writing a full whitepaper going into an extended look into the process, the framework and a EA Framework Evaluation Matrix that will compare a set of the common EA frameworks on the market based on a set of attributes (outside a specific EA organization need) in a qualitative and quantitative way. If you want a sneak peak at the drafts or you want input into the process leave a comment below.

Culture Mapping Tool

Dave Gray posted on his blog that he has created a tool to help understand corporate cultures. This looks very interesting… I could see lots of uses for this tool as an Enterprise Architect. The typical stakeholder management only gets you so far, this takes it to the next level if the tool is effective. 

The collaborative effort between Dave Gray,  Alex Osterwalder, Alan Smith, and Chris Finlay has yielded a prototype and the graphic below:

Culture Mapping


In his words:

The culture mapping tool was so useful that I have long thought it would make an excellent tool for any company that’s dealing with a difficult transformation that will require rethinking, re-imagining or simply shifting the company culture.


More Information and developments