You are here

How to Make Enterprise Architecture Hands-On

The architecture — structure, functions and resources — of an organization exists whether anyone acknowledges it or not. Much of the continuing growth of enterprise architecture as a methodology worth pursuing hinges on the claim that acknowledging and formalizing an EA is helpful to an organization, especially one that’s large, complex and exists in a dynamic and competitive operating environment.

If one traces the roots of EA back to John Zachman’s seminal 1987 article, then we are in the 20th year of EA. During that time, architectural thinking moved from a systems-level perspective to an enterprisewide view. These 20 years have also seen EA grow from an information-technology-centric concept to one that claims to be the meta concept for the design and documentation of an entire enterprise in all respects.

My favorite shorthand for the evolved concept of EA is that it integrates strategic, business and technology planning (EA = S + B +T). EA also provides the context for using best practices, such as the balanced scorecard, service-oriented architecture and the IT Infrastructure Library. EA answers the what, how, why, where, when and who questions of the enterprise. That’s consistent with Zachman.

So, how can you make EA more valuable to users? Five factors help determine how tangible EA will be to an enterprise, and how well an agency can succeed at making EA a way of doing business that’s better understood by executives, managers and staff.

No. 1: Executive Support

Consider the Winchester House, the quirky California mansion

under continuous construction for 38 years. The owner did not value architecture or blueprints. The result was a nonsensical collection of rooms. Homebuilders today invariably understand the soundness of using blueprints. Agency leaders need to recognize that their enterprises, likewise, will not self-organize or improve on their own and will benefit from formalized architectures that support planning and decision-making.

No. 2: Encompass the Whole Enterprise

CXOs don’t have the luxury of selecting which parts of their enterprise to be responsible for and therefore need a methodology for architecture that can encompass all lines of business. This architecture must be scalable so it can address the entire enterprise, specific LOBs, and each process and resource component within each LOB. Because EA is scalable, it can represent the entire enterprise as well as show details needed by individual users.

No. 3: Authoritative Documentation

Just like architectures for buildings, architectures for virtual entities become authoritative when documentation is easy to navigate, correct, complete and current. Documentation is most effective when organized into an integrated set of artifacts that covers all aspects of the strategy, business, data, application, network and security subarchitectures. Approaches such as the Department of Defense Architecture Framework; the Federal EA Framework, reference models and profiles; and my own EA Cube Framework are examples of how to organize these artifacts.

No. 4: Tie-in to Governance

EA documentation needs to support planning and decision-making throughout the enterprise. It should be used in governance processes that involve policy development, strategic planning, capital planning, risk management, project management, knowledge management, contracting, security, operations and workforce planning.

No. 5: Training Is a Must

To be effective, everyone using an EA must understand its concepts and language. This requires training that’s become readily available from many sources. Two of the best EA certification programs are offered by the National Defense University ( and by Carnegie Mellon University (

To make EA more tangible, agencies should formalize the architecture across the entire enterprise using a mature, segment-based documenation framework and the Federal EA reference models and profiles. Agencies can then use the EA to improve mission performance across all lines of business by helping decision-makers better understand how, where and why change needs to occur and then create better business cases, transition plans and projects to make those changes happen.

Dec 31 2009