EA in Practice
Author: Brenda Yu
An EA serves as an important communication tool to multiple stakeholders and interested parties. To business proponents and champions, the EA brings together both current and desired operational processes and interactions. To data management personnel, the EA describes data objects used in current missions and systems and the desired data model. To budget and oversight organizations, an EA provides evidence that sufficient thought and planning have gone into defining the desired future capabilities and systems. It further helps to communicate and address both organizational and IT strengths and weaknesses.
One of the most important functions of an EA is to provide a holistic view of the enterprise that brings together components from the business architecture, data architecture, application architecture, and technology architecture. The entities and their functions captured for each of these architectures, developed as models, are comprehensive and often complex. Yet, the richness of the relationships, dependencies, and cross-cutting concerns among these architectural layers is perhaps the most compelling aspect of an EA’s value-addition. Various models and architecture views provide a mechanism through which desired knowledge is communicated among different stakeholders.
Stakeholders have a specific viewpoint on a subject, and their perspective must be addressed by a corresponding “view” on the model. In the modeling context, a view is a selection or derivation from the model of the architecture and is expressed in terms of the same modeling concepts and notations. A viewpoint establishes the purpose of constructing multiple views within a model to communicate an integrated picture. The presentation of this view—sometimes referred to as “visualization”—can take on many forms, from standard diagrams to tables, cartoons, or even animations. Whether it is tailored for a business or technical audience, the visualization needs to be intuitive and easy to understand. As stakeholders have unique individual perspectives, this enables creation of usage scenarios that ensures the system is modeled in a consistent manner and in accordance with the interests and concerns of the respective stakeholders.
EA serves as a guide for the enterprise to manage its complexity, but effectively implementing and communicating is dependent on a clear understanding of the different perspectives of its stakeholders.
- Lankhorst, M., et al, 2013, Enterprise Architecture at Work: Modelling, Communication and Analysis, Third Edition, Springer.
- Nikpay, F., Ahmad, R., Yin Kia, C., 2017, “A hybrid method for evaluating enterprise architecture implementation”, Evaluation and Program Planning, Volume 60, Pp. 1-16.
EABOK® Knowledge Areas
Organizational Scope and Structure of EA
Developing an EA
- Business Requirements and Value Proposition
- Methodologies and Processes
- Architecture Frameworks
- Data and Information Management
- Project Management
- Change Management
- Testing and Evaluation
- Modeling and Simulation
- Role of Reference Architectures
- How to Build a Reference Architecture
- Coordinating the Creation of a Reference Architecture
Management of EA
EA in Practice
Perspectives on EA
EABOK is an evolving knowledge base and more information will be released as available.
In addition to the EABOK Board members, the content is also contributed by the following MITRE employees:
- Carla Kendrick
- Brenda Yu
- Eddie Wang
- Rose Tykinski
- Wakar Khan
- Mike Russell
This website is managed by the EABOK Consortium and hosted by MITRE to enable stakeholder collaboration within the EA community.
EABOK and the EABOK logo are trademarks of MITRE and are used by The EABOK Consortium with permission.
All other trademarks are the property of their respective owners. All rights reserved.