EA is a strategic tool that presents an approach to identify and address gaps between aspirations and reality, whatever drives the gaps. It accelerates the ability of an Enterprise to achieve its stated objectives. The tool comes with its method to use, taxonomy to support the directions, and resources needed to benefit from using the tool.
- Why is it important to develop an Enterprise Architecture?
- What is an Enterprise Architecture?
- How to use an Enterprise Architecture?
Why is it Important to Develop an Enterprise Architecture?
An EA is developed for one very simple reason: to guide effective change.
All Enterprises are seeking to improve. Regardless of whether it is a public, private, or social Enterprise, there is a need for deliberate, effective change to improve. Improvement can be shareholder value or agility for a private Enterprise, mandate-based value proposition or efficiency for a public Enterprise, or simply an improvement of mission for a social Enterprise.
In its simplest terms, EA must describe the future state and the current state of the Enterprise. The description of the future state enables the right people to understand what must be done to meet the Enterprise’s goals, objective, mission, and vision in the context within which the Enterprise operates. The gap between the Enterprise’s current state and future state highlights what must change. A good EA facilitates effective governance, management, risk management, and exploitation opportunities. A list of gaps makes obvious what must change and the implications of that change: is the proposed project in alignment with what is needed? In alignment with priority? In alignment with the complete set of goals and objectives?
What is an Enterprise Architecture?
In short, EA provides the most effective path to realizing an Enterprise’s strategy. A good EA uses a holistic approach to translate strategy into a well-defined execution path, using appropriate analysis, planning, design, and implementation methods.
The purpose of EA is to enable the Enterprise to most effectively achieve the mission, business strategy, and goals through cycles of planning, design, deployment, and delivery of change. An architected approach provides a rigorous planning methodology that validates the business objectives, ensuring that they are feasible, deliver the desired business value, and their achievement is cost-effective.
Achieving this purpose comes from understanding the Enterprise, the context, the scope of change, and the value that will be realized. Using EA facilitates understanding. The Enterprise is described in consistent terms, highlighting fundamental parts and how they interact. Consistent terms enable like-with-like comparison. Potential changes to the fundamental parts are explored regarding the desired end-state and preferences. This understanding and analysis enable trade-off between competing preferences and potential changes that carry different costs and different benefits.
In short, a good EA enables stakeholders to knowingly strike the right balance between any competing set of preferences. It allows individual business units to innovate safely in their pursuit of business value delivery. At the same time, it ensures the needs of the organization for an integrated strategy are met, permitting the closest possible synergy across the extended Enterprise.
How to Use an Enterprise Architecture?
An EA is developed for one very simple reason: to guide effective change. Practitioners use models to provide a consistent analysis of complex systems. Models provide efficient long-term representation that enables like-with-like comparison – comparison of what is, what was, and what might be. The comparison that facilitates trade-off between potential changes that carry different costs and different benefits. Models provide understanding to people who understand the language, structure, and limitations of a model.
Guiding effective change is driven by who is using the architecture. Three broad communities use the EA: stakeholders, decision-makers, and implementers. Each of these communities uses the architecture differently.
When starting to talk about communication, the problem of terminology is the first obstacle faced. “Stakeholder” is a useful term, and multiple frameworks and methods use the term. Be aware of when you are carrying implied meaning from one framework, or approach, to another. This Guide follows ISO/IEC/IEEE 42010:2011 guidance on stakeholders which focuses the attention on those whose concerns are fundamental to the architecture, or architecturally significant. Facilitating effective communication requires us to make a distinction between other communities who are interested in the architecture. A stakeholder holds approval rights on the target and the implementation; an implementer requires guidance and constraint; and a decision-maker holds execution rights on change. Practitioners are advised to develop views that address a stakeholder’s concerns. Success of an architecture rests on the clarity and focus of the views produced. Its sole purpose is to communicate that the Target Architecture best satisfies the complex set of requirements the Enterprise has. Practitioners are best served when they preserve the distinction between stakeholders with approval rights and those needing most recent data points to create appropriate views of the concerns addressed by the EA. Without clarity on distinct roles, Practitioners complicate governance of the EA and the change projects.