Reinventing Enterprise Architecture

I've seen articles recently proclaiming that Enterprise Architecture (EA) is dead. Of course, I've seen the same proclamations for SOA, for COBOL and any number of other technologies or IT practices over the years. These premature announcements all have one thing in common - they equate the value of a technology (or technology practice) with its current position in the hype cycle rather than its actual utility. There is another thing these death notices fail to grasp - technologies aren't static and they aren't always replaced by something new. But before we dive further into this topic, perhaps it is worthwhile to revisit what the current expectations for Enterprise Architecture.

Sadly, Mark Twain is really dead now, but EA isn't...

EA, as it is currently defined…

The set of high-level design activities necessary to support IT portfolio planning and/or specific IT Transformation initiatives. While EA is typically considered primarily a business-focused activity, it is also often concerned with high-level design of data, application or security solutions. EA is typically distinguished from other types of architecture by the scope or scale of the associated problem-space.

Now, this definition doesn't capture any of the core issues associated with the typical exploitation of EA in most enterprises and the reasons why some people have determined it is no longer relevant. And, like most other aspects of technology, there are legitimate issues associated with EA and a history of many Enterprise Architecture efforts not meeting expectations. Some of the problems that have been associated with EA over the years include:

• A lack of understanding as to what value it provides
• A too narrow focus on feeding (building out) an EA repository
• Lack of connection to the actual IT solution architectures

Sometimes, when we hear the word "Reinvention" we get the impression that whatever needs to be reinvented is somehow broken; that's usually not the case and it is definitely not the case with EA. What Reinvention does imply however is that there is always a need to evolve and improve - that is how any capability, technology or set of skills remain relevant over the long-term. Reinvention allows us to enhance what works, replace what doesn't and redirect all of it in more meaningful ways. That's exactly what I'm proposing for Enterprise Architecture.

So, how does one go about reinventing a major IT field of practice? 

It starts at the beginning - the expectations for that practice. These new expectations must take into account both the lessons learned (the current criticisms) as well as the trajectory of future need. The expectations fall into three categories:

1. Greater Flexibility
2. Greater Agility
3. More Relevance

EA must become more Flexible
Some of the severest criticism of enterprise architecture comes from those who have seen EA become a means unto its own end. In other words, the practice of EA has sometimes been overly focused with the management tools used to implement it. These tools are powerful and typically include EA repositories, technology catalogs and various analytics. These tools are also typically built atop a foundation known as an Enterprise Architecture Framework. These frameworks, which I will talk about in more depth in some future posts, include TOGAF (general), DODAF (military), FEAF (federal) and Zachman (general). The Zachman and TOGAF frameworks are typically better suited for commercial environments while the government ones tend be mandated as part of the larger IT portfolio processes of the agencies involved. 

The key thing to keep in mind with Frameworks is that they merely represent meta-models of what the types of things a typical organization ought to be concerned with. In this respect they are much like ITIL (which is essentially a taxonomy of data center processes) or like standard industry EDW data models (for energy, healthcare etc.). The Framework/model becomes the schema for the EA Repository and then the tool helps architects to build visualizations using data placed into that repository. The problem is that sometimes this process of building out the repository and the enterprise view of what's happening becomes too inwardly focused and too rigid. The flexibility required moving forward is this:

1. The tools are there to help the larger process of assessing the enterprise and supporting planning. That means that the tools must also serve the process and not the other way around.
2. The meta-models are not the end-all, be-all of what can be done with enterprise architecture. Like EA itself, all of these meta-models are evolving and there will often be important aspects of what's happening in the enterprise that aren't properly covered by the framework. EA is more than any given framework and can exist beyond them or even without them if needbe.
3. The work that an Enterprise Architect does is part of a larger continuum. We'll talk about that a little more in a minute, but the key thing to keep in mind here is that the Architect and the organization need to understand where and how the work fits in - and be willing to adjust as necessary (rather than staying on the same rigid course regardless of what is discovered).

Agile EA is possible...

EA must become more Agile
This is also a popular criticism of Enterprise Architecture; that it is often a rather lethargic and abstract exercise. Well, sometimes it is true, but that of course only happens when the activity is not made Flexible (see above) or more Relevant (see below). But what does Agile really mean in the context of Architecture? Many people might think that the two concepts represent a sort of cognitive dissonance. That's not really true though. Enterprise Architecture, like any complex enterprise level activity can be made more Agile by simply changing the expectations associated with it; for example:

• That analysis or assessment activities be time-boxed and aligned with specific goals or initiatives.
• That building EA deliverables or documents serve a specific purpose, such as Portfolio review or creation of Reference Architecture guidelines.
• That EA is not a giant one-off effort, but rather a more or less permanent and iterative process, that allows for continuous innovation as an organization.

Making it Real (or at least Relevant)
This is perhaps the most important change that needs to occur, but it also happens to the be the least recognized by most groups who are actually having issues with EA. This is borne from the problems associated with lack of flexibility - namely the stove-piping off of EA from the rest of what the enterprise is doing. I've been there, seen that - an EA group producing something that is totally ignored by other groups charged with making strategy real. There is one sure way to cure this problem and that is to connect EA to the rest of the IT lifecycle. The first step in doing that is understanding where EA fits in the larger spectrum of IT Architecture and then building the necessary links between all design and governance process for IT capability. 

EA when viewed by itself, represents the strategic or business focus of the larger IT Architecture mission spectrum. It is where enterprise options are assessed and where organizational strategy becomes an actionable plan for achieving organization-wide capability. It is also the starting place for all design. This unique, combined role places it squarely in between business and technical interests and their respective stakeholder groups. The future of EA is with this role empowered to broker issues between the wants and realities of the typical enterprise. EA is not analysis for its own sake - it is an ongoing and collaborative process for ensuring that Digital Innovation or evolution occurs according to plan.

copyright 2014, Stephen Lahanas