A Note on This Article

This article was originally written in 2011 as a diagnostic challenge to organizations that believed they had Enterprise Architecture simply because they had a group of architects. The question it poses is as relevant today as it was then — perhaps more so, as the scope of what EA must govern has expanded dramatically. Technology references have been updated where appropriate to reflect current standards.

Do You Really Have an Enterprise Architecture?

Many organizations have a corporate or enterprise architecture group — but does that mean they have an Enterprise Architecture?

The fastest way to assess this is to ask the Director or VP of Architecture to produce the Target Architectures and associated three-year roadmaps. If that document does not exist, you already know where you stand.

What Does Target Architecture Actually Mean?

In its simplest form, a Target Architecture is a clear picture of the applications that will be added, modified, or removed over the next three years. The critical question is how that picture was produced:

a) The result of opinions and political views

or

b) The result of a structured process covering:

  • Modeling and documenting Business Processes (and capabilities)
  • Mapping Business Processes against the Common Information Model (CIM) via CRUD (Create, Read, Update, Delete) matrices
  • Mapping Business Processes against Applications — to identify redundant functionality and processes not supported by any application
  • Analysis of which applications to keep, decommission, or modify
  • Planning the projects required to reach the target state over a three-year horizon, with Rough Order of Magnitude (ROM) estimates and project dependencies identified
  • Incorporating those projects into the annual CAPEX budget with identified sponsors

If the answer is (a), the architecture will shift with every change in leadership or priority. If the answer is (b), then the organization has real EA Targets and Roadmaps — and a credible plan to execute them.

What This Tells You About Your EA Coverage

Approach (b) also means the architecture group covers at least two of the five architectural aspects — Business Process and Data. This is a meaningful start. The group may also have defined a BPM methodology covering modeling notations, process optimization, Business Activity Monitoring (BAM), and simulation.

But before moving to the remaining aspects, one additional question deserves attention: have Business Processes been standardized across Lines of Business? This step allows further streamlining of the application portfolio — because one of the most consistent outputs of a mature EA practice is a significant reduction in the number of applications, bringing costs under control while delivering more comprehensive applications that better support the business.

What About the Remaining Architecture Aspects?

For the Integration Architecture Aspect, the key questions are: Have you addressed the transport layer, the data layer, and the process layer? Have you planned the appropriate software and hardware infrastructure? Have you mapped all applications against the Common Information Model — the only reliable way to achieve loosely coupled applications? (Originally framed around ESB and SOA — today this equally applies to API-first design and Event-Driven Architecture.) This is where some of the largest benefits are achievable: reducing the number of point-to-point interfaces dramatically lowers both application maintenance costs and the cost of new projects. It also makes Merger & Acquisition integration significantly more manageable — with pre-defined standard migration plans already in place.

Technology Infrastructure, Architecture Governance, and Security each deserve their own treatment — but the foundational question this article set out to answer is the one above: do you actually have an Enterprise Architecture, or do you have a group of architects?

A Manager of Architects Is Not an EA Leader

If the answer is that Target Architectures and roadmaps do not exist, the organization likely has a Manager of Architects rather than an EA Leader. The distinction matters enormously. A Manager of Architects assigns the best available architects to the most visible or sensitive projects. An EA Leader defines a vision, a strategy, target architectures, and roadmaps — and becomes an evangelist with Lines of Business on the business value of process standardization, application rationalization, and architectural alignment.

An EA Leader also understands the value of proper EA tooling — for metadata management, impact of change analysis, version control, and roadmap management. Without these, the artifacts that make EA actionable cannot be maintained at scale.

The right person in this role forces alignment across all architecture disciplines — Solution Architecture, Data Architecture, Integration Architecture, Business Process Architecture, Technology Architecture, and others. That alignment makes architects more productive, reduces the crisis-driven project cycles that result from architectural drift, and ultimately gives the architecture community the sense that they are truly supporting the business — and seeing it succeed.

Footnote on Terminology

The term “Aspect” used throughout this article derives from Capgemini’s Integrated Architecture Framework (IAF). As a member of the Open Group, Capgemini contributed IAF 4.0 as input for the definition of the Architecture Content Framework in TOGAF 9.