|
-
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, 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 on the topic of
Enterprise Solution Architecture or Solution Architecture:
- Mastering Enterprise Solution Architecture/Gu, Sean(Chunhong), APRESS, 2024 - This
book explores the Agile ESA model in terms of its six
constituents: Method Specification, Thinking Framework,
Measurement Criteria, Architectural Styles, Governance
Techniques, and Tools.
- 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.
- Agile Enterprise Solution Architecture/Gu, Sean,
Vernal Press, 2021 - This book presents a foundational 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.
- 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.
- 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.
- 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.
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 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.
|