---

In the IT world, we often see that many well-crafted architectures fail to meet expectations. The reasons are many, but a common one is the lack of a clear model for viability.

An Enterprise Solution Architecture (ESA) specifies a five-area model that covers key considerations in an enterprise environment in terms of common architectures such as enterprise architecture and software architecture.

Since an ESA is more effective in an agile approach, Agile ESA (A-ESA) is often used synonymously in many cases.

5C Area Model

First, let’s take a look at what the 5 areas of an A-ESA model are in the following figure.

For simplicity and ease of recall, we focus on the core 5C or C5 concept of these 5 areas: 

• Case Scenario – this is the area of requirements capture and mapping with enterprise solutions
• Composition of Services – this is the area of coarse-grained functional services that correspond to business domains and are often composable for flexible applications
• Capability – this is the area of enterprise-level considerations that embody the business value proposition and reflect enterprise directions and constraints.
• Context – this is the area of architectural boundary and overview that represents the governing ideas of the enterprise solution. It also ensures the specification of significant metrics and their appropriate mappings.
• Container – This is the area of the operational environment that contains deployment packages or units with specific service level characteristic considerations.

Simply put, these 5C areas are fundamental to viable ESA modeling.

5C’s Relevance to Major Architectures

The ESA model is closely related to popular architectures, as seen in the following figure.

• Software Architecture – Composite services are more of a software or application architecture concern. Composite applications can be very challenging in a large, complex distributed environment.
• Information architecture – The case scenarios reflect the solution requirements. Each solution must map the information flows and values of key related enterprise sections.
• Enterprise Architecture – The enterprise capabilities are the essential part of the enterprise architecture and business architecture. They symbolize enterprise resources and building blocks that are aligned with solution building blocks and quality attributes. 
• Solution/Integration Architecture – The solution context provides an overview of the enterprise application and system’s boundaries and interfaces, considering both information flows and control flows.
• Operational Architecture – The container environment is more concerned with the dynamic aspects of the technology or platform architecture, and its impact on the deployed applications.

Depending on the ESA needs and choices, modern architectural style(s) are incorporated into the model. For example, the DevOps often reflects a cloud native microservice architecture, commonly featured with domain services (largely software architecture), DevOps culture (ESA’ DevOps view), and scalable virtual nodes (operational architecture).

This architectural relevance ensures an overall consideration from multiple viewpoints for a common understanding of what viability means.

Hint: Business architecture is typically part of the enterprise architecture consideration, and data architecture is typically cross-cutting and will be related to various architectures.

Viability via 5C Synergy

In an ESA, heat map assessment (more EA focus) and tradeoff balancing (more SA focus) are critical to achieving viability. The ESA’s link between EA and SA is an architectural assurance of such viability.

Hint: SA can mean either software architecture or solution architecture, which is what we mean here.

As shown in the following figure, ESA viability is intuitively ingrained in the modeling process.

• Requirements mapping – The case scenarios are used as input to the solution(s), and only the significant use cases and processes are walked through to identify likely hotspotsof service-level quality attributes
• Application adaptation – The composite services represent meaningful business domains, service choreography, and process task orchestration, with a key set of non-functional requirements and governance rules for future cases or flexible change needs.
• Heat-map assessment – The enterprise capabilities are drilled from IT strategies and built up from IT solutions (either in whole or in part). The capability area reflects the problem space, white space or innovation space, and is the thermostat of the as-is and to-be enterprise. 
• Key choice consideration – The solution context, along with the governing ideas, is where key metrics, building blocks, and architectural patterns are specified. Note that the focus here is not only on solution needs, but also on architectural conformance.
• Deployment unit mapping – The container environment also reflects the flexibility of the solution along with key service level qualities. Deployment package mapping determines how application services are coupled with the runtime environment for operational excellence and efficiency.

A viable ESA model is the result of synergy between these 5C areas, with the enterprise capability area serving as the overall viability assessment and the solution context area serving as the viability assessment for each solution project or solution program. Ultimately, ESA effectiveness is about viability and sustainability. In practice, viability is more valued from an ESA perspective. A viable ESA can easily adapt to change, as measured by the cost of change.

Hint: Viability vs. Sustainability
Viability is characterized by adaptability, resilience, and efficiency. Sustainability is characterized by long-term planning, environmental impact, and resource efficiency.
Ideally, a system should be both viable and sustainable to ensure long-term success and resilience.

Viability Measurement

Viability can be measured by comparing the as-is state and to-be state. Viability metrics can be set at different architectural levels, as shown in the following table.

Architectural Level	Metrics	Measurement
EA level	– Capability Heat Map Performance – Comparative Cost-Benefit	– Categorized Capability Indicator
Solution level	– Key quality attributes (such as performance, reliability, adaptability, ) – Development efforts (such as productivity) – Stakeholder satisfaction	– Optimal SLI (Service Level Indicator) as ideal solution) – Realizable SLI (within constraints) – Governance Functions
ESA level	– Cost of change – Architectural technical debt (note: this is on top of technical debt)	– Viability assessment (probability vs. impact) – Architectural Proof of Concept (PoC) for significant case scenarios, or SAAM (Scenario-Based Architecture Analysis Method) – Agile ESA tool
Note: There are several approaches to measuring the viability of an ESA. For an article on this topic, see “How to Measure the Viability of an Enterprise Solution Architecture?”

For an objective quantitative assessment, you need to define clear evaluation indicators, collect baseline data and post-implementation or post-delivery data, compare data analysis, establish a technology flow evaluation system, and so on.

It’s important to note that a meaningful viability assessment is only possible if a viable ESA model is in place. Missing or downplaying any of the 5Cs will potentially lead to biased results and/or incorrect mitigation actions.

Summary

A-ESA, as its name suggests, takes an agile approach to ESA. This article very briefly introduced A-ESA using a simple 5C area model that centers on enterprise capabilities.

A-ESA’s holistic modeling approach enforces architectural conformance and helps contain or reduce architectural debt, thereby achieving architectural viability and enhancing sustainability with lower change costs.

---