In-Depth
5 Steps to Successful EA Adoption
Architects could learn a few things from the U.S. federal government, which has had success with its use of EA.
It is increasingly apparent that organizations are finding the management and control of Information Technology more and more difficult. The ability for a small group of people including architects, database administrators, and lead developers to hold the IT inventory in their heads is impossible, but most organizations rely on that capability. How many times have complex IT investment decisions been based on talking to a key architect or operations manager who "knows the systems like the back of his hand"?
Enterprise Architecture is seen as one of the answers to this need for control. Its promise is to provide the organizational blueprint that enables executives to make decisions about investment, business value, and organizational change. But if EA is so important, why aren't organizations adopting such an approach? And, more important, what are the steps you can put in place to take advantage of EA thinking without introducing more overhead?
To answer these questions, we look in an unusual place: the U.S. federal government, which has become the EA poster child in recent years. The Clinger-Cohen Act passed by the Office of Management and Budget (OMB) in 1996 mandated that all U.S. federal agencies develop and maintain an EA in order to obtain funding. With this initiative, government agencies were forced to find best practices to implement and leverage their EAs. Based on our experience working with the government, I propose these five steps to successful EA adoption:
- Leverage an iterative process to reduce risk.
- Use visual models to represent multiple views of an enterprise and the relationships between them.
- Ensure traceability from inception to implementation.
- Control change throughout the evolution of the EA.
- Make EA part of the organizational governance process.
Iterative Process
An iterative process has been defined as the repetition of the same activities regularly on small chunks of the system under development. We add to that definition by including the concept of risk into the set of requirements that define each iterative chunk. It is important that the EA is treated like a project, and that EA processes be understood as risk-based, with iteration plans, risk lists, and other project management artifacts of the iterative, incremental lifecycle.
So the EA is incrementally created, but the portions addressed first are those areas that represent the most risk. For example, the EA would be developed for a complex system first, or because of a merger of the key business systems. Once the initial EA is developed, new elements would then be added in line with the priorities of the business.
Visual Models
A picture says a thousand words, and this is particularly true for an Enterprise Architecture. It is crucial that the EA provide both a means for addressing the problems facing an organization (by asking the right questions) and a mechanism to readily communicate the complex system capabilities to many different stakeholders. Architectural frameworks such as Federal Enterprise Architecture (FEA) and Department of Defense Architecture Framework (DoDAF) provide a firm basis for an EA, providing both a set of questions to answer and enabling a level of consistency between EAs across an agency.
Traceability Throughout the Lifecycle
An EA is often thought of as an analysis tool; activities associated with the EA are undertaken by analysts in the early stages of the lifecycle. The most effective EAs have to reside throughout the lifecycle and include artifacts and information from all the domains in the development, maintenance, and planning of systems. The EA needs to be able to answer questions that relate to business process, applications, data, and operational implementation.
Providing that traceability, which ultimately means "accountability," enables the EA to be used as the ultimate planning tool. But that level of traceability can require extensive resources to create and maintain it. When an EA become overly elaborate in terms of traceability mechanisms that do not get maintained, the EA loses its value. So it's crucial that the capacity for traceability be kept at a realistic level and that automated traceability tools be used to better enable it.
Control Changes
A static EA is a dead EA. EAs change as the organizational systems change to support the business or mission. A good measure of an EA's value is to determine when the last change was made. If the change was long ago, it's less likely that the EA offers value. Organizations must consider the EA part of the standard change package for a system; change requests should be managed against the EA elements, and version control needs to be practiced on those elements.
At any one time, there should be at least two versions of an EA: the current EA and the proposed future EA. Often there are numerous versions of the EA for each change path, each project, and each version within that project.
Make EA Part of the Governance Process
The U.S. government's success in its EA effort was partly because of the integration of the EA activities into the budget and procurement process. Making EA a fundamental part of the overall governance process—for example, ensuring that spending is controlled in the context of the EA—helps ensure that the EA is both current and useful. The Office of Management and Budget made the CIO accountable for the EA to get access to funding. This approach naturally encouraged CIOs to take great care in developing and maintaining their EAs.
Thinking, Organizing and Executing
When approaching the development of an EA, an organization needs to do three things: thinking, organizing, and executing (see Table 1).
Thinking: The organization needs to assemble, purchase, or harvest a framework that enables its members to think about the EA. This framework needs to provide the semantics and structures to enable those creating and maintaining the EA to make the right decisions and communicate those decisions to all the necessary stakeholders.
Frameworks like FEA, Zachman, E2AF, and TOGAF are just a small sampling of the materials in the marketplace today. It is my experience that organizations must sample from all of these approaches and build the EA that suits their needs. They must build an EA that satisfies their requirements and suits the style and skills of their stakeholders.
Organizing: Once the appropriate way of thinking about the EA is determined, an organization must organize its process and structure around that framework. Responsibility, control, and ownership must be integrated into the framework to better enable the organization to operationalize the architecture and to ensure that the structure clashes between architecture and organization are kept to a minimum. If an organization is working iteratively, it needs to develop a change management plan.
Executing: An initial EA project might be complete, but that does not mean that the work of the EA is complete. It is important that EA becomes a natural part of the processes and lifecycle of the systems that support the business. The activities undertaken to create and maintain an EA often need to move out of the EA project and into the normal systems lifecycle. Organizations often still have an architecture department, but that department's role is one of enablement and governance.
It is clear that the U.S. government is having some success with its use of EA, as evidenced by its integration of EA into the governance, procurement, and planning processes of government systems development. As commercial organizations increasingly face growing systems complexity and different procurement methods, the adoption of good EA practice seems logical. Making EA part of the overall development process and using its artifacts in the decision-making process will help ensure that systems development becomes the first-class business process it needs to be.