So You Invested in an Enterprise Architecture Framework . . . Now What?

Architects have been successfully (and unsuccessfully) using enterprise architecture (EA) frameworks since 1987 when John Zachman published his Zachman Framework. Frameworks typically consist of an iterative ADM (Architecture Development Methodology) and a reusable set of existing architecture assets. There are many benefits that can be realized by implementing an EA framework. They allow large change programs to be approached with rigor and can be used to organize, control, and monitor the performance of third-party system integrators, vendors, and contractors. Using a framework helps achieve a balanced EA that is complete across all the required architecture domains (business, application, technology, and information) by providing clear guidelines on each step of EA development and deployment as well as a wealth of supporting guidance, tools, techniques, and reference architectures. They leverage the insight and experiences of others and provide a common architectural language for EA initiatives.

Meaningful framework deployment can be elusive

An EA framework is not a silver bullet, but it can assist with your EA program, providing it is implemented correctly. Through our many EA engagements we have gained significant insight on the challenges faced by organizations as they attempt to adopt EA frameworks. There are three questions organizations should ask themselves before investing in an EA framework:

1. Which EA framework is best for my organization and program?
2. What is the actual value that the selected framework will deliver?
3. How should we actually implement the selected framework and embed it within the enterprise?

Selecting a framework is usually a straightforward activity. Deploying it in a meaningful way is often hard to achieve.

Take A Pragmatic And Benefits-Based Approach

How then should architects and managers plan to roll out and embed an EA framework? We recommend implementing an EA framework that is pragmatic, benefit-driven, and realistic, focusing only on those elements that add value. The following key principles should be considered when creating a framework tailored toward the organization’s unique concerns.

1. Don’t spend too long selecting the framework. The selection of a framework is not the key activity. It needs to be done but settle on one quickly as they all share a common pedigree.
2. Don’t be a slave to your framework. ADMs can be onerous and have many steps that can be omitted. Architects can get distracted and bogged down in the details if they attempt to blindly execute every single step without understanding the value it will deliver. Adapt and customize the framework to fit your needs, removing, adding, and flexing.
3. Support your implementation with robust tooling. A good EA tool is essential to any successful EA program. Take time to understand the capabilities of the tool and framework before you begin. Only implement parts of the framework and tool that answer a specific question in the mind of your stakeholders.
4. Know when to use your framework and when not to. EA frameworks are suited to large change initiatives as well as smaller, iterative architecture development. However, there are tasks for which EA frameworks are not well suited and you need to understand them. Implement an ADM rubric to assist with framework decision making.
5. Understand that effective implementation of an EA framework takes time. An EA framework may add additional time to your program. Communicate this and plan for it. Be pragmatic and flexible, however, and understand the financial impact of your recommendations.
6. Work hard to get teams to adopt and time the rollout right. Architects may resist the formal implementation of a framework. Be sure to sell the benefits of your approach and communicate these religiously. Be aware of major programs on the horizon and make sure that you are ahead of the curve in regard to the need to provide architecture support to key initiatives.
7. Design and implement value metrics with your stakeholders. Frameworks don’t typically include metrics and measures to gauge success and the value that an ADM is delivering. Take time to agree these.
8. Don’t implement EA from an ivory tower. Don’t implement your framework in isolation from other IT initiatives. The ADM will have touch points with your SDLC, IT project portfolio management, ITIL, strategic planning, and other IT functions.

by Proteus Duxbury, a principal consultant in PA Consulting Group’s IT consulting practice with 10 years experience as an experienced enterprise architect and certified TOGAF practitioner. His past work includes EA, solutions architecture, technical due diligence, software development, system development life-cycles, and project management.