-
What is enterprise solution architecture?
-
Why enterprise solution architecture?
-
Who are the primary users of ESA?
-
How does ESA differ from other EA and
software design in terms of tool support?
-
When is ESA most applicable and when is it
not necessary?
-
What is the impact of AI on ESA?
-
Books on ESA or SA
FAQ about A-ESA
Simply put, enterprise solution architecture (ESA)
falls between enterprise architecture (EA) and solution architecture
(SA), leaning more toward the latter. It's an IT service-based
architecture for the missing link between EA and SA.
The definition of enterprise architecture varies (see
references). According to FEAPO: it is "a well-defined practice for
conducting enterprise analysis, design, planning, and
implementation, using a comprehensive approach at all times, for the
successful development and execution of strategy." It "applies the
architecture principles and practices to guide organizations through
the business, information, process, and technology changes necessary
to execute their strategies. These practices use the various aspects
of an enterprise to identify, motivate, and achieve these changes."
While solution architecture defines the implementation of a
project (or a program containing a group of projects) by considering
all the major elements from its related requirement inputs, software
applications, data exchanges and infrastructure environment.
Enterprise solution architecture (ESA) aims at an enterprise-level
IT system (system of systems) which, similar to the best-known IEEE
definition about IT architecture, concerns a fundamental structure
of service components, their relationships to each other, and to the
environment, and the principles guiding its work product and
evolution. Of primary importance, ESA is about establishing a
leading practice and a governance modeling approach to solution
design. It’s not about everything in a complex system, nor is it
about detailed solution design.
Unlike an EA, an ESA often takes an agile approach, so an ESA is generally referred to as an Agile ESA or A-ESA for short. Visit a-esa.com to learn more about this topic.
Note that an EA or SA can mean an ESA if it achieves the architectural outcomes of the ESA defined here.
References:
As we all know, enterprise architecture (EA) typically involves
an enterprise-wide IT approach for common ground standardization,
shared capabilities, industry-specific architectural patterns,
operational efficiency, and reduced total cost of ownership (TCO).
However, many organizations honor IT strategic planning and
enterprise architecture in word but not in deed. The many IT plans
and blueprints, with their size and complexity without enterprise
solution architecture (ESA) feedback mapping, often turn out to be
shelfware that is less useful.
In contrast, the ESA approach takes into account EA’s capability and
principles which fill the missing space in the solution architecture
specifications while leaning toward enterprise-level significant
concerns beyond the design or development level. ESA’s
plan-while-modeling approach pragmatically facilitates EA landing
and solution robustness.
ESA is for pragmatic enterprise architects, chief or lead
architects, solution architects, and other IT solution professionals
in a large-scale and complex solution environment. It’s also for IT
decision makers such as CIOs and CTOs to take a down-to-earth look
at enterprise IT architecture.
Each architectural design specification has its own purpose and
usage. ESA strikes a proper balance between EA tools and
architectural design tools (UML, etc.) and provides its own unique
features.
The ESA is most applicable to enterprise digital transformation
and solutions that are heavily subject to the cost of change. If the
solution is small or less complex, does not require a certain level
of abstraction and collaboration, or has few service-level
requirements across different architectural layers, the A-ESA is not
a must.
Enterprise solution architects are among the least threatened
professionals in the AI era. Powered by AI, ESA architects will make
better and faster decisions. Likewise, ESA's practical, robust
modeling approach will facilitate AI enablement for greater insight
and broader adoption.
Here is a list of just a few of the books (checked around the year 2023) on the topic of Enterprise Solution Architecture or Solution Architecture:
- Agile Enterprise Solution Architecture/Gu, Sean,
Vernal Press, 2021 - This book presents an enterprise solution
architecture that bridges the gap between traditional solution
architecture and enterprise architecture in a holistic yet
pragmatic modeling approach.
- Enterprise Solution Architecture - Strategy Guide/Garg,
Nitesh. BPB, 2021 – This book is about a roadmap to transform,
migrate, and redefine your enterprise infrastructure along with
processes, tools, and execution plans.
- Introduction to Solution Architecture/McSweeney,
Alan. 2019 - This book describes solution architecture as a
value-added information technology consulting service. It’s
about project management of solutions.
- Solution Architecture Foundations/Lovatt, Mark. BCS,
2021 - This book is an introduction to the discipline of
solution architecture, which is a structured way to address a
problem, risk or opportunity and produce an effective solution.
- Solution Architecture Patterns for Enterprise/Fernando,
Chanaka. APRESS, 2023 – This book provides a quick reference
architecture and a reference implementation introduction to the
concepts of enterprise software systems and solution
architecture and the different solution architecture patterns.
- Solutions Architect's Handbook/Shrivastava, Saurabh,
et al. PACKT, 2020 – This book is primarily about cloud solution
architecture based on aws, one of the solution architectures for
specific technologies.
Software architects or developers tend to design solution architectures based on technical services (or components), leaving little or no room for abstraction, while 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 characterization. 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.
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.
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, 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.
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.
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.
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.
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, 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 a 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 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.
|