A-ESA

Agile Enterprise Solution Architecture

One-page Introduction to the Agile Enterprise Solution Model: A 5-Area Coverage

This brief article provides a one-page introduction to the areas and views of the Agile Enterprise Solution Architecture (A-ESA) model, which is based on numerous real-world enterprise solutions.

One-page Introduction to the Agile Enterprise Solution Model: A 5-Area Coverage

Basically, A-ESA covers five architecture areas with corresponding architecture views, as shown in the figure above.

Enterprise Capability Area

This area reflects IT strategic intent and enterprise architecture (EA) inputs to the solution architecture (SA). To ensure alignment between EA and SA, there is a mapping between enterprise principles and solution metrics, and a mapping between capabilities and IT services in an agile approach.

Case Scenario Area

This area is primarily for clarifying solution requirements in visual modeling. All architecturally significant cases should be considered with corresponding non-functional quality attributes. The Page Flow View, for example, can be used in a design thinking workshop to facilitate requirements mapping.

Overview Context Area

This is a high-level view area of the entire solution from different viewpoints, reflecting architectural governing ideas and guidelines. Typically, there are more required views in this area than others, based on different solution needs. Fundamental views are required to provide a clear architectural overview. This area requires abstraction skills and contains key architectural considerations.

Functional Area

This area represents composite functional service views, along with representative service component realization in software engineering to ensure mapping and governance to the component design. This area is most critical for enterprise application solutions that are subject to change.

Operational Area

This area reflects more non-functional requirements and needs to have a clear mapping of deployment units or packages. It’s one of the key architectural mapping areas that often gets less attention.

Once you have covered these five areas iteratively and incrementally, you have a basic ESA architectural shape. However, there is more work to be done to improve A-ESA, which will be discussed separately.

Regarding the A-ESA area/view, there are a few points to note:

  • There will be some flexibility in the definition in real solution projects. For example, a validation area is often used to enforce testing and governance. Because A-ESA takes an agile approach, it’s adaptable to different solution needs.
  • Despite of the area/view names, the fundamental areas and views must be present for a holistic consideration of the enterprise solution(s). For example, the enterprise consideration is often missing or not given enough attention, leading to viability issues or architectural debt in many cases.
  • For the functional area, don’t fall into the component modeling mindset. An enterprise solution without a service level functional view would defeat its purpose.

For ease of recall, the A-ESA model can be simplified as a 5C or C5 model that captures the essence of the A-ESA areas. The first two Cs are obvious: Capability and Case (Scenario). The other 3 Cs: Context (Solution Context), Composition (Functional Composite Services), and Container (Container Environment with Deployment Units based on the Service Level Requirements). See this article on the 5C Area Model.

Obviously, there will be an incomplete discussion of ESA views without considering their associated elements which are a minimal set of notations that reflect the fundamental architectural nature of enterprise solutions. The A-ESA views (more details) and elements are discussed separately.