Why Enterprise Architecture Needs Maturity Models

Walk before you run. We’ve heard it a million times, referencing almost as many different disciplines. Yet as time is limited, it’s often human nature to want to get things done quickly. However, much like our first steps, building a successful Enterprise Architecture practice is a process worked on and developed over time.

This is where a maturity model comes in. Maturity models are employed as a means for businesses to evaluate their current position, and therefore, better understand when it’s the right time to move forward and how to do so.

At the risk of a metaphor overstaying it’s welcome, consider this: buying your infant an expensive pair of runner’s shoes and expecting them to sprint is a misguided presumption at the very least. With the child clearly not ready to utilize them, there’s absolutely no way to justify the cost. You’re better off with a pair that are fit for purpose with the knowledge that they will be outgrown.

Maturity model use in enterprise architecture

Enterprise architecture (EA) can be viewed in the same light. If your enterprise architecture practice is newly established – the type of set-up that’s focused on reacting to issues as they arrive – you shouldn’t expect the team to immediately start delivering the work more associated with vanguard enterprise architects, who’re more focused on thinking forward, planning and innovating.

A maturity model is essentially a survey based framework, purposed for assessing IT capabilities. Capabilities including but not limited to operational efficiency and effectiveness. In short, the IT leaders in an organization complete a survey, and are awarded a score based on their answers.

However, the maturity model itself isn’t where organizations will find its value. It’s the knowledge gained from an organizations current position and insight from the model and it’s suggestions that gives the model its worth. Businesses can use this information to influence development roadmaps for their enterprise architecture practices, to better them going forward.

Gartner’s own EA maturity model generates generic, yet prescient suggestions for developing a practice. These suggestions are the cumulative understanding and judgment of some of the industry’s most trusted analysts.

However, organizations should tailor their development plans to themselves, as the nuances of their individual experience will rely on the organizations own business outcomes.

Perhaps the biggest benefit of a maturity model for the EA practice, is that it can help you better identify the right time to go bimodal, establish Vanguard Enterprise Architect roles or expand the team. This is important, as the current industry trajectory indicates that bimodal approaches to IT will be increasingly essential as digital business continues to expand across markets.

The different levels of the enterprise architecture maturity model

Gartner’s is by no means the only maturity model in the discipline. However, due to Gartner’s prevalence and status as an industry trusted source of analysis, their model is a fine point of focus for this discussion.

Their maturity model identifies five different levels of maturity within enterprise architecture practices. Ranging from an enterprise architecture structure that is “Non-Existent”, to one that is “Ubiquitous.”

They breakdown the five levels as such:

• Level 1: Nonexistent — As it sounds.
  In this instance, enterprise architecture either hasn’t existed until this point, or is in its very early stages of implementation, and any enterprise architecture work that has been done, was almost certainly informal and off cuff.
• Level 2: Reactive — In this instance, an enterprise architecture practice does exist, and is officially recognized by the organization. However, the nature of the practice is one of response, rather than preemptive planning and action. Because of this, work is still on an ad-hoc or off cuff basis, and can usually only promise short term fixes.
• Level 3: Functioning — At this point, an enterprise architecture practice is now operating with business outcomes in mind. The Foundational Enterprise Architect is often well represented here. However, the organization isn’t necessarily prepared for a truly bi-modal EA set up, and might struggle with balance when bringing in some of the more Vanguard EA responsibilities into the fold.
• Level 4: Integrated — At this stage, the enterprise architecture practice is delivering value, and consistently so. Vanguard EAs are clearly established and so the business can adopt a ‘true’ bimodal approach to its operations. This is where organizations should aim to reach at a minimum as here, an organization is delivering on business outcomes.
• Level 5: Ubiquitous — Here, enterprise architectures success has a trickle down effect across the organization. EA becomes a natural way of working and the principles behind the discipline are widely adopted.

The changing role of Enterprise Architects

Along the EA practice maturity journey, the enterprise architecture team tends to refocus at the different stages. Initially, the practices’ main focus is providing guidance – if you’re familiar with bimodal IT (you should be) you’ll know that this corresponds with ‘Mode 1’. Here enterprise architecture is predominantly concerned with answering specific questions about maximizing efficiency in processes, reducing complexities and helping to steer and implement development decisions.

The practice then moves towards a new focus, concentrating on delivering business outcomes. Enterprise Architects are responsible for laying out the structure behind the business strategy, and working towards and finding the business outcomes behind said strategy. At this point, EAs are also responsible for ensuring IT in general, stays aligned with the wider business.

Lastly, an enterprise architecture practice will occupy the space it arguably needs to be today. Practices are now tasked with supporting digital business – a concept that occupies a mass of consumer markets, and continues to infiltrate more. This is where enterprise architecture demands innovation, and why innovation management capable EA tools are a smart and valuable investment. Enterprise Architects are now responsible for creating new business opportunities, not just support in reaching their outcomes. This demands a different type of Enterprise Architect, and the introduction of a new ‘Mode’ (Mode 2) into the way the practice operates.

In each of these transitions, the previous is built upon rather than forgotten. This is where bimodal IT is so important when navigating the digital business environment. A mature enterprise architecture practice demands responsibilities for both ensuring “business as usual” and delivering business innovations.