(EA)<sup>2</sup> Approach to Modeling Enterprise Architecture
The (EA)<sup>2</sup> approach to modeling enterprise architecture is the result of working with various industry standard frameworks and architectural development methods (ADM) on numerous client engagements over the last 10 years. That experience has been embodied in the toolboxes, quicklinks, import files, and the base model provided with (EA)<sup>2</sup>. However, we do not expect everyone to structure their models in the same way as we do. Therefore, you are free to change the structures provided by (EA)<sup>2</sup> as need requires. The reporting capabilities of (EA)<sup>2</sup> do not depend on this structure at all, but rather on the elements you create from the toolboxes, their tagged values, the connectors you draw using the Quicklinker, and in some cases, diagram stereotypes. Sparx Systems' Enterprise Architect documentation describes how to save your new structure as a base model which can be used to seed other models you create. Several XML files are supplied with (EA)<sup>2</sup> that allow you to import complete package structures and diagrams for certain key element types. These too can be modified and saved for reuse.
There are four top level concepts that provide the overriding direction for modeling with (EA)<sup>2</sup> which are introduced in the following subsections.
Architectural Horizontal Slice
The architectural horizontal slice addresses the needs of different types of stakeholders by independently focusing on the architectural views. The views include the Business Architecture, Application Architecture (aka, Software Architecture), Data Architecture, and Infrastructure Architecture. (EA)<sup>2</sup> provides diagram types for these architectural views along with associated toolboxes that provide modeling tools germane to each architectural view.
Architectural Vertical Slice
The architectural vertical slice addresses everything (or at least the architecturally significant elements) that is required to realize a given business process. It includes a formal model of the business process and then, for one path, maps it to the applications that automate all or part of the process, the data that is used or created by the applications, and the infrastructure required to support the applications and data. Another path down through the architectural layers includes use case and use case realizations.
Roadmaps
Roadmaps provide a way to model the current state of the business process' architectural requirements while, at the same time, modeling future states. Roadmaps can be created for different purposes, e.g. for introducing a new process or changing the technology supporting a process. They can have phases, e.g. a current state phase, a phase for the years 2011-2012, and another for 2012 and beyond. Projects that are responsible for delivering all or part of the changes embodied in a Roadmap can be mapped to a Roadmap Phase.
Architectural Guidance
Modeling your architecture as described in the three sections above does not complete your architectural needs. The Architectural Guidance area of the model is the place to provide the big picture concepts of what you are trying to do with your architecture and its alignment with the business. You can add instructions on how to model certain aspects of your architecture. Better yet, you can include patterns that can be used by your designers. Some topic suggestions are provided in the (EA)<sup>2</sup> base model, but you should feel free to add additional ones.
This area contains some things provided by (EA)<sup>2</sup> as well as some (EA)<sup>2</sup> items that are user configurable. These let you tweak the modeling environment to better suite your purposes.
More Info
The following links will take you to more information on the listed topics.
