7 Essential Elements of EA (Continued)
Engaging the Business
Incomprehensible technical models and arcane diagrams make it impossible to launch a meaningful architecture discussion with business stakeholders. That approach will simply collapse under the weight of engaging the business to help create such detailed models. A better way to introduce a business audience to EA is to begin collaborating with business stakeholders to develop a set of guiding principles, our first element.
Guiding Principles are a collection of definitive statements that provide guidance on how the organization should conduct certain business and technical functions (see Figure 2). They serve as filters for decision making, eliminating possible solutions that are not consistent with the organization’s goals and objectives. Good guiding principles are unlikely to change within a short-term period, and are clear, concise, and supported by rationale and implications developed with business and technical staff working together. Consensus building and alignment are beneficial byproducts of conducting a series of structured guiding-principle discussions. In all cases, the results serve as guideposts for the upcoming decision making and are a necessary tool to unite business and technology constituencies.
The second element, blueprinting, is the art of documenting the EA models and standards. As in civil architecture, a good set of blueprints helps manage the complexity associated with ongoing repairs and updates to intricate systems. However, unlike civil architecture, EA does not have a rigorous blueprinting methodology. You can use frameworks such as the Zachman Framework, Steven Spewak’s Enterprise Architecture Planning, and the Federal Enterprise Architecture Framework that identify blueprint contents, but do not address how to go about developing the blueprints.
Start by engaging the business stakeholders in the development of business architecture blueprints. Architects work closely with the business to document the mission, vision, goals, objectives, and business capabilities required to enable the business strategy. This strategic business architecture work is led by the enterprise architect, bringing an engineering rigor to the process. The result is a set of linked architecture elements clearly showing which capabilities are required to deliver the business goals and objectives. Furthermore, business metrics are identified and associated with each objective, providing a model that is used to periodically measure the progress toward attaining the business vision.
The business architecture also includes an operational business architecture that defines the key processes, stakeholders, and interactions that are needed to implement the business strategy. Current state and future state versions of the operational business architecture allow architects to assess the impact a new strategy would have on current operations.
Next, engage IT to develop the systems architecture. The systems architecture describes, in a platform-independent way, the high-level applications, information, infrastructure, and interfaces that enable the strategic and operational business architectures. These models are useful for linking technical elements (such as applications, information, infrastructure, and interfaces) to the business capabilities. This linkage provides a language for discussing technology with the business—both in terms of impact (What happens to my technology when I change a business goal?) as well as in terms of cost (What does it cost to implement a particular business goal or capability?).
The business and systems architectures are typically created and updated during regular IT planning cycles. You use these architectures to identify the IT initiatives (and determine the funding) needed to implement the business vision—expressed in terms of the business capabilities, which by now has become the common language that binds business and IT.
The final level of blueprints is the technical architecture, which describes the physical implementation of the applications, information, infrastructure, and interfaces. The technical architecture identifies the specific products, protocols, and wiring schemas that guide the implementation.
Back to top
|