FAQs on ESA (Enterprise Solution Architecture)

Why is ESA taking an IT service-based approach?

Software architects or developers tend to design solution architectures based on technical services (or components), leaving little or no room for abstraction. In contrast, business people tend to think about business services from a different focus and granularity of technical services. They both look at the same solution from different perspectives. However, ESA architects, who consider both business needs and technical implementation, view the solution from an architectural perspective. ESA uses IT services or architectural services that best reflect the solution architecture. An ESA model includes a well-considered set of IT service notations (functional or operational) and associated notations that define those IT services.

Who should assume responsibility for ESA?

The ESA is a component of the EA repository and should be assigned an owner, which may be a team or a role. Depending on the scope of the solution, the key ESA responsibility may be held by a Chief Architect for overall enterprise-level issues, a Lead Architect for a major solution, or a Specialist Architect for a specific part of the architecture. The ESA includes all stakeholders as participants who provide input or feedback. The ESA architects organize or map the input received into a solution with measurable metrics and shape it into the A-ESA model.

Why does ESA require both Case Scenario and Functional Views?

ESA focuses on IT solutions, not business architecture. However, one of the key architectural issues is the mapping between business processes and activities to application logic. For example, a BPMN process often does not automatically translate into a workflow or BPEL flow as expected. The transition from business services to application or technical services requires a lot of architectural thinking. The use of a well-defined architectural style or methodology supports such a transition. For example, in a microservice architecture, case scenarios will identify domain services in the problem space, while functional views will specify bounded-context services in the solution space. The mapping of case scenarios and functional spaces facilitates the flexibility, modularity, and maintainability of the solution. Even in a technical architecture, applicable case scenarios are still part of the considerations, along with the functional services that make up the technical architecture.

Unlike an EA, which has a relatively long-term strategic goal, an ESA is a landing plan. IT faces constant change, and so does an ESA. Agility allows key architectural considerations to be captured dynamically and incrementally in a flexible modeling approach. It reduces the learning curve and leverages common sense to meet different solution needs.

Does A-ESA use agile frameworks?

Agile architecture does not require the use of agile frameworks such as Scrum and SAFe, although they are a good fit. A-ESA does not require these frameworks either, but advocates their principles. As mentioned in the book, A-ESA does not specify a formal process, but requires a model approach that maps critical agile activities through iterative delivery. Both agile architecture and A-ESA live on the promise of lower change costs, so they are complementary. Ideally, A-ESA is the unity of agile methodology and IT architecture.

Is Design Thinking valuable for ESA?

Design thinking is a problem-solving methodology that emphasizes user-centeredness, explores problem spaces, and generates innovative solutions through iterative processes and interdisciplinary teamwork. Design thinking helps with requirements gathering and analysis, which is an important input to ESA's case scenario mapping. ESA emphasizes mapping the problem space to the solution space. A well-defined problem space must be supported by one or more solutions. When design thinking and architectural thinking go hand in hand, there will be a successful ESA outcome. However, design thinking alone lacks long-term considerations and tends to overlook system issues, technical choices and standards, compliance, governance, accumulated problems, etc.

Does gap analysis fall under ESA?

Sure. Gap analysis in ESA is reflected in the dynamic model and focuses on gap mapping, architectural or technical debt considerations, quality issues, and future solution cases. Metrics mapping, including feasibility assessment and key choice considerations, is an important part of gap analysis, as is the as-is/to-be transition. ESA doesn't include the lengthy assessment or impact analysis that is typically part of the EA deliverable.

What's special about A-ESA?

There are many architectural frameworks with different approaches and purposes. Choosing the right one, often a mixture of different frameworks, is no small feat. The judgment lies in its practical application. A-ESA is featured with 3S: simple, significant, and systematic. It is coupled with a modeling approach and provides a simple model for rapid solution architecture, with flexible modes to choose from. It takes a holistic view of the enterprise solution, but considers only the most significant case scenarios for focused architectural considerations. A-ESA is a concrete architecture beyond these traditional EA processes, frameworks, and reference architectures that contain a lot of fluffy descriptions. It's a real alignment between business and IT. In an A-ESA, an EA is implementable, and an SA is rendered at an appropriate level of abstraction. A-ESA defines a unique set of views and elements that are generalized from many different types of solution architectures, and they represent a foundational enterprise solution architecture. It's intended to be used in AI-enabled tools through the unique characteristics of each selected element, which all together represent the real solution system. For example, a so-called microservice must be specific to a basic A-ESA element. Is it a problem space domain, a bounded context, an independently deployable unit, a runtime container, or just a self-contained, data-owning service? A clearly mapped A-ESA will present a model that is well understood in an SA context. A-ESA disdains lengthy documentation or steps. A-ESA values meaningful architectural outcomes rather than lengthy descriptive outputs. The idea of "less is more" requires a lot of architectural thinking to simplify complex matters. An ESA model, together with the A-ESA constituents, serves as a visual checklist and abstracted digital twin of the as-is or to-be system at the architectural level.