Enterprise Architecture Maturity

Enterprise Architecture Maturity

Why is Enterprise Architecture Maturity Important?

When I talk about Enterprise Architecture, the topic includes Enterprise Architecture Maturity.

I figured it would be worth sharing a little more detail about that for additional discussion and revision. Definitely would appreciate any feedback you might have.

Before I show you the model, let me preface by saying that I am trying to provide something that makes sense to people and organizations who are just starting out in architecture as well as to people and organizations that have been doing architecture for a long time. I am not trying to capture every nuance, but instead trying to provide a simple, conceptual model for people to work from.

The entry point for most individuals and organizations into Enterprise Architecture is Solution Architecture. EA tends to start out IT-focused because that is where it has much of its historical roots, and most EA teams report to the CIO or elsewhere within IT function.

As an EA, you mature, and you expand your scope: first from a breadth of coverage perspective, then moving from proactive to reactive and finally moving outside IT and really impacting the business model of an organization.

Three Significant Steps in this Journey

First, entry into the model in the first place is key. Architecture requires a much different mindset than business analysis or application design. Understanding that mindset is the first big step.

The second major step is moving from reactive to proactive. This is critical because it provides significantly more unique value to an organization. But it also requires much more buy-in and support from senior management.

The third major step is really moving outside of IT, to directly impacting the business model of the organization. When you make this step, you must consider many more variables in the conversation. The potential impact, both positive and negative, is much higher.

There are many EA organizations that never make it to Level 3 or 4, and that’s OK. Architects can add significant value at Levels 1 and 2. The key is to know where you are on the maturity scale and to stay in your lane. When you try to run out ahead of your organizational support and buy-in, that is where you will get in trouble.

Business or Digital Transformation?

Digital Transformation – A Bit Misunderstood

Everywhere you look people are talking about Digital Transformation. But very rarely do they explain what they mean. Every once in a while, people bring in the term Business Transformation, but they often don’t define that either. I thought I’d take a few minutes and share my views.

When I think about Business Transformation, I think of driving discontinuous change in an enterprise, usually in response to external forces. Harvard Business Review said it very well: “Business transformation is about making fundamental changes in how business is conducted in order to help cope with a shift in market environment.”

In today’s world, when I think of Business Transformation, I think of 3 key elements:


  • Primarily focuses on customer-facing areas of business and the extended enterprise
  • Typically transforms the business model using IT


  • Primarily focuses on how work gets done inside an enterprise
  • Typically transforms business processes using IT

IT Functional

  • Primarily focuses on how work gets done inside IT dept within an enterprise
  • Typically transforms IT Management processes using IT

Historically, each of these transformations is enabled by bringing technology innovation to bear as part of the change.

The Role of Technology Innovation

  • Primarily focuses on newer, cutting edge technical capability that can be applied in an enterprise
  • Typically is an enabler of the above transformations in some way

Our Why for business transformation is to support new business strategies. We know our Whats – the 3 key elements of transformation along with technology innovation as the enabler. What we are missing is the How.

In today’s digital world, Enterprise Architecture is the How, the best method for delivering business transformation for the enterprise.

If you would like to learn more about how EA and it fits with Business Transformation, check out my webinar co-hosted by industry expert Jason Bloomberg:


In this webinar, you will learn

  • Key tips to help your CIO see the value of EA
  • What needs to be different about EA in a Digital Transformation world
  • What you can do today to restart your EA program

You can also grab the slides on SlideShare.




IT4IT and TOGAF – how do they fit together?

IT4IT and TOGAF – how do they fit together?

IT4IT and TOGAF can each be used in isolation, but when used together, both are stronger.

In my role leading work in both the Enterprise Architecture space as well as the IT Transformation space, I am frequently asked how IT4IT and TOGAF fit together, and how the Enterprise Architecture profession fits into the IT4IT context.

My experience working with clients in this space has led me to look this question from two key perspectives.

As seen from the CIO’s office …

The first is from the vantage point of the CIO using IT4IT to look at his or her organization for improvement opportunities. At this level of enquiry there are two primary views: the IT Value Chain and the Level 1 Reference Architecture.

IT Value Chain


IT4IT Level 1 Reference Architecture

From this perspective, Enterprise Architecture is a small piece of the overall big picture.  There are 29 functional components in the Level 1 reference architecture of which EA is simply one of many. Within the EA functional component it is appropriate to use whatever architecture framework we see fit, to guide process or best practices for Enterprise Architecture. TOGAF, along with counterparts like DODAF, FEAF, Zachman and others, simply fits into this box and needs to be integrated with other parts of the IT organization through the development of the Service Architecture.

IT4IT gives the CIO a way to look across the organization, and to assess all its functional components for quality or maturity (or whatever other factor is important) and to decide where the biggest pain points are.

IT4IT also gives the CIO a very clear way to understand the data needed to manage an IT organization and provides a framework for evaluating how well that data is flowing across the different organizational silos.

… from the Enterprise Architect’s viewpoint

A second perspective for which IT4IT is useful is that of an Enterprise Architect.

As an Enterprise Architect, it would be my job to look across the entire enterprise. We use the Porter Value Chain here as one simple representation of a way to segment your Enterprise Architecture according to TOGAF.

Porter’s Value Chain Model

IT is one of several areas in the business. Each of them might have an industry reference model appropriate for use for one or several of the areas.  Examples include ARTS, BIAN, SCOR, VCG, APQC or many others. IT4IT in this context is simply a reference architecture for managing the Technology Development (or IT) support function.

IT4IT provides us with the details we need to truly understand how IT needs to work.

Neither perspective on how to use IT4IT is more or less important. The CIO can get significant value from using IT4IT in a top-down manner as a strategic assessment tool to drive improvement across the IT function and help transform the IT Operating Model. The Enterprise Architect can get significant value from using IT4IT in more of a bottom-up manner as a reference model to speed up architecture work and to drive vendor integration and standardization in the IT Management tool space. Regardless of whether you use IT4IT in a top down or bottom up manner, it helps to understand how the pieces fit together for you and your organization.