Agile ESA

Agile Enterprise Solution Architecture

Fundamentals of Enterprise Solution Architecture Elements

We see many architectural diagrams or views. Not many catch the architectural essence in a holistic fashion. Some are cloud platform-specific reference architectures, some are software or infrastructure architectures, some are enterprise architecture planning views, and many are casual diagrams without clear architectural properties. This post describes a set of enterprise solution architecture (ESA) elements that are gleaned from numerous practical ESA solutions or projects.

ESA Element List

Now, let’s examine List 1 [1], the ESA base element list, to see why these elements were chosen based on the S3 principle: Simple, Significant, and Systematic.

List 1 – ESA Base Element List:

Enterprise

  • Capability: It represents an EA-level ability possessed by a structural element, such as a functional service.
  • Value/Value Stream: It represents the relative importance or value of a concept or vision from an enterprise perspective.

Case Scenario

  • Role/Actor: It represents a responsibility for performing a specific behavior, as well as an actor, user, or user group.
  • Task (Activity, Operation): It represents a business function, activity, or piece of work assigned to a role in a process.
  • Use Case/User Story: It describes the interactions between a role and a system to achieve a goal.

Metrics

  • Principle/Guidance: It represents a qualitative statement of intent that must be met by the architecture. It is part of a guideline framework.
  • Requirement /Rule: It represents a concise statement of needs in a broad sense.
  • Key Choice/Consideration: It represents an architecturally significant decision, gap analysis, assessment, issue resolution, or solution assurance based on the collective solution strategy.
  • Risk/Constraint/Arch Debt: It represents a constraint, a potential issue, something that has not happened, or a key decision that needs to be addressed.
  • Governance: It embodies IT architecture standards, compliance requirements, and criteria.

Functional Service

  • UI (User Interface/Interaction) Service: It is an interactive service, usually with a visual presentation.
  • App Logic Service: It represents explicitly defined non-GUI application behavior, control logic, or composition.
  • Data Service: It is a self-contained piece of information with a clear meaning to the application. It can be a standalone data object or a federated, integrated data service.
  • Tech Service: It represents behavior that is independent of the application-specific logic context.
  • Service Interface: It represents an access point where services are made available to a user, service, or service component.
  • Service Component: It represents the implementation of a service responsibility or functionality.

Operational Service

  • Deployment Package/Unit: It contains functional services based on their unique service-level characteristics.
  • Middleware: It represents system or intermediate software that provides services to software applications.
  • Data Store: It represents a repository where structured, semi-structured, or unstructured data is persisted and managed.
  • System/Device: It is a collection of hardware and software components and their relationships for specific business functions.
  • Node: It generally represents a hosting resource that interacts with other resources.
  • Network: It denotes a set of structures, products, and services that enable connections between system nodes for data transmission.
  • Location: It is a place where structural elements are positioned or through which they are communicated.

Connection

  • Association: It represents a generic or unspecified relationship.
  • Flow: It represents movement from one element to another.
  • Composition: It represents an element composed of one or more other elements.
  • Realization: It represents the realization of an abstract element as a concrete one.

General

  • Note: It represents commentary or interpretation of the architecture.
  • Grouping: It represents a logical representation, layer, generic composition, or aggregation of elements.
  • Generic Domain: It represents a functional concept or boundary within which multiple elements are controlled under the same scope.
  • Generic Service: It covers well-defined business or application activities in a specific solution context and serves as a logical service, architectural service, or functional service.
  • Virtual Service: It represents an intangible asset or information, or a technical service without a physical IT service form or a clear interface.
  • View Frame: It is used to scale an architectural design through a drilldown view or solution plateau.
  • Deliverable: It represents a defined outcome and is generally more of a concern from a solution management perspective.
  • Artifact: It represents an additional solution specification or design piece. It can be a class, method, namespace, document, project, or the like.
  • Extension: It is a flexible representation for adding model elements, including non-IT elements or external system elements.

ESA covers high-level enterprise concerns and guidance through the Capability, Value (Cost, ROI, etc.), and Principle (also part of metrics) elements. These are representative elements of enterprise architecture (EA). Many other EA elements, such as business model elements (for example, function and business process) and capability model elements (for example, resource and course of action), can be mapped to ESA elements for solution relevance. Elements that cannot be mapped well are either too high-level, unrelated, or beyond the architectural concern level.

ESA also covers case scenario elements. Role, Task, and Use Case are simple enough, yet sufficient to express complex architectural case scenarios.

ESA has a set of metric elements, which is unique in the architectural model specification. These metric elements are critical to decisional architecture in addition to structural architecture. It takes Principle from EA or enterprise guidance and Requirement (primarily non-functional requirements or quality attributes) from users or intended solution plans. It considers Risk from both architectural solution and solution management perspectives. It clearly defines the Key Choice element, which many specifications ignore, although most people understand the importance of trade-off analysis. In many cases, trade-off analysis is scattered across documents or maintained in separate architecture decision records (ARDs). Importantly, ESA includes Governance, which is key to architectural conformance. An architecture without governance actions has limited value.

Now we come to the hard part of software architecture associated with metrics: functional/application services. Traditionally, software architecture has relied on design practices such as MVC (model-view-controller) or UML-based design.

In software architecture, six key architectural techniques in practice are cohesion, coupling, layering, granularity, isolation, and autonomy. MVC, for example, does not fully address isolation because it lacks explicit consideration of technical services. In ESA, the functional services include UI, App Logic, Data, Technical Service, Service Interface, and the realization-level Component, making it easier to clarify these six techniques. Each functional element has its own service characteristics to consider (see List 2 [2]) and is likely to belong to a different specialist group, or require a different role and mindset.

List 2 – Service-Level Characteristics of the Functional Services:

  • User Interface – Type of user/actors, access frequency, concurrency, active time, access mechanism, and UI element types.
  • App Logic – Actor touch point, cohesion, logic complexity, composition, technical isolation, invocation mechanism, and performance metrics.
  • Data – Data type, volatility, currency, record size, record numbers, usage intensity, accuracy, and compliance.
  • Technical – Concurrent user/actors, transaction type, operating time, bandwidth condition, latency, reliability, and error rates.

For operational services, Node is straightforward. Network (at the blueprint level) is part of the operational environment, and Location often comes from EA considerations. For ESA, the System element is essential because there are always interactions with internal or external systems. Middleware has unique architectural characteristics that support development or runtime operations. Unlike self-developed functional services, Middleware (or cloud Middleware) is typically provided by third-party products. Therefore, in ESA, middleware requires configuration and compatibility, with little or no development effort. If customization costs more than using a different solution, the middleware may not be the right choice. There are many types of middleware, so it is not appropriate to include specific types, such as Gateway or Service Bus in the base elements. Commonly used middleware types can instead be represented as assistive elements. Data Store (Database or Storage), a type of middleware, is often treated as a base element because it is an integral part of the solution. The Deployment Package element is a key link between functional services and the operational environment. Without clear and rational deployment mapping, the architecture is problematic.

ESA has only four connection relationships for simplicity. For simple solutions or simpler expressions, only Association and Flow elements are required.

General elements are used as needed. The Note is a common element, as is the Grouping. Unlike the Grouping, the Domain element has a strong composition relationship and can represent a physical grouping. Generic Service is loosely defined and can represent different levels of granularity. Virtual Service is relatively less familiar, but it is part of solution customization and integration. The View Frame is a unique element that supports architectural view scaling. Deliverable addresses solution management concerns. Artifact can represent software documentation and similar items. The Extension element is optional and is used to represent remotely related elements.

That is a brief overview of the ESA base elements. It is easy to add more elements, but difficult to create a simplified yet minimal list. As Antoine de Saint-Exupery pointed out: “perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Varied Element List

Table 1 describes only the ESA base elements. A complete set of ESA elements includes assistive elements suited to different architectural styles. The base elements serve as the ESA core, but they can be expressed in different forms for stakeholders at different architectural levels.

In its lean mode, ESA uses around ten or fewer elements for a simpler representation. Solution architects can expand these elements and map them to the core elements to support better architectural understanding and conformance. List 3 shows examples of commonly used lean-mode elements.

List 3 – ESA Lean-Mode Elements:

General

  • Role: Actor, User, Stakeholder
  • Task: Activity, State
  • Grouping: Group, Domain, Layer
  • Artifact: Key Element Properties, Artifact

Metrics

  • Requirement: Non-Functional Requirement, Rule, Intent
  • Key Choice: Key Decision and Consideration, Governance

Functional

  • Generic Service: Service, Application, General Element
  • Component: Service Component, Object
  • Data Store: Database, Storage

Operational

  • Middleware: Development, System, or Platform Software
  • System: Device
  • Node: Deployment Package

On the other hand, for solution specialists, ESA can be expressed in a less abstract form using more assistive elements for detailed representation. For example, in AI-native or augmented solutions, ESA offers AI-specific assistive elements such as Agent, AI Coordinator, AI Tool, AI Model, Knowledge Access, and Context at the ESA abstraction level. List 4 shows some examples of assistive elements. Solution architects can map these elements back to the core elements to support holistic thinking about complex solutions.

List 4. Example Assistive Elements in ESA:

AI-Specific

  • Tool & Action: Tech Service
  • Knowledge Access: Data Service

Architectural Style

  • Frontend: System Device
  • Cloud: Domain, Location
  • Microservice: Generic Service, Deployment Unit

Business

  • Function: Generic Service

DevOps

  • Governance Control: Governance

General

  • Document File: Artifact
  • Partition: Domain

Integration & Scalability

  • Gateway Service: Middleware
  • Service Broker: Middleware

Ops & Infra

  • Cell: Domain
  • Virtual Server: Virtual Service, Middleware
  • Rack: Extension

Software Design

  • Module: Domain

Therefore, ESA is often called agile ESA because it allows flexibility and adaptation to meet practical solution architecture needs while maintaining a simple and clear set of core elements for analyzing the architectural characteristics that matter to the cost of change.

Summary

The ESA elements are generic and independent of specific solutions, so they apply to most solutions. They form a simple yet clear set of architectural elements, each representing unique architectural characteristics and useful modeling features. This allows for focused architectural thinking rather than product-focused or superficial architectural representation in commonly seen solution architecture diagrams.

ESA is a key link between enterprise solution planning and solution design & implementation. In the AI era, this level of architecture is critical for providing architectural guidance, whereas traditional enterprise architecture and solution design are increasingly supported or handled by AI.