0% found this document useful (0 votes)
39 views

Weekly Note 416 - Difference Between Solution and Target Architecture

Solution architecture defines the structure and guidance for a specific IT solution, providing details down to physical components. Target architecture depicts the conceptual future state of the enterprise as a whole, including business models, processes, governance and supporting technology. It provides a framework for alignment but is not directly implementable. Key differences are that solution architecture focuses on implementation details for a project while target architecture guides programs and projects towards the enterprise's long term goals at a conceptual level.

Uploaded by

Daniel Zavalza
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views

Weekly Note 416 - Difference Between Solution and Target Architecture

Solution architecture defines the structure and guidance for a specific IT solution, providing details down to physical components. Target architecture depicts the conceptual future state of the enterprise as a whole, including business models, processes, governance and supporting technology. It provides a framework for alignment but is not directly implementable. Key differences are that solution architecture focuses on implementation details for a project while target architecture guides programs and projects towards the enterprise's long term goals at a conceptual level.

Uploaded by

Daniel Zavalza
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Weekly Note 416 – Difference between Solution and Target Architecture

This week I attended an ASE and one of the main conversations was the question of the Difference between
Solution and Target Architecture.
Introduction
A solution architecture defines an architecture for a specific solution, whether this be business or IT. The
solution architecture provides structure, standards, and guidance for the detailed design of a solution and is
typically guided by the enterprise architecture. Note that “solution architecture” is often used as shorthand for
“solution IT architecture” and is sometimes referred to as “project architecture” and/ or” IT architecture”.
By target architecture we often refer to the target state of the enterprise which details the structure and
relationships of the enterprise, its business models, the way an organisation will work and how and in what
way information and IT will support the organisation’s business objectives and goals. Enterprise architecture
provides an all-encompassing, holistic end-to-end view of the business in terms of people, process,
governance, and technology within (and external to) the business to support those objectives and goals.
An enterprise architecture is not directly implementable. Instead, it should be seen as a pictorial depiction of a
conceptual target that covers both business and technology.

Solution architecture in detail


Let’s start with a solution architecture. Whereas a solution architecture typically details a solution down to a
physical level, an enterprise architecture works usually on a conceptual or logical level. As an example, an
application cloud migration solution will have to have designed and validated the technical target platform incl
network, server, and storage layout. Key to note that a “solution” is not just a network diagram or an
application component view.
To detail a solution there are several key aspects (a technical solution as example to illustrate) to design:
• The overall Context
o A synopsis of the architecture context that has influenced the design decisions documented
within this solution
• Scope
o A clear definition of what is in but also what is out of scope for this solution
• Requirements
o The functional as well as non-functional requirements covering availability, performance,
stability, sustainability, and security for instance
• Constrains
o Any legal, compliance or commercial constrains the solution had to consider
• Assumptions, risks, issues
o Any assumptions, risks and issues the solution had to consider
• Delivery / Migration Approach
o The approach taken to move from the current position (As-Is) to the target
• Target
o Pictorial depictions of various target pictures that shows the solution in its target state related
to key technical information. For instance (a non-exhaustive list)
▪ A pictorial representation of all main Business Applications and System Services
organised in logical clusters (e.g. Portal applications, Financial Applications, CRM
applications, security services, integration services, B2C services etc) - High Level
Conceptual View of all Customers Services
▪ A pictorial representation of the Business Services covered by the distinct logical
clusters
▪ A pictorial representation of the Business capabilities covered by the distinct logical
clusters including
▪ A lower-level pictorial version of point a (decomposed) defining distinct components
contained in each service (e.g Integration Services, decomposing this there is a ETL
box, storage etc)A pictorial representation of each distinct business service provided
(or line of business ) and the high-level business process (step-by-step view)
▪ An Integration View (interfaces) - take deliverable of point d and define what
component is receiving/sending what data and how
▪ A Data View - take deliverable of point d and define what data is being used and how
(read, write, change)
▪ A Security View
▪ etc

Solution architecture in detail


An enterprise architecture covers a similar set of artefacts. However, it does not provide components that can
directly be implemented. It details the structure and relationships of the Enterprise, its business models, the
way an organization will work and how and in what way Information and IT will support the organisation’s
business objectives and goals. An enterprise architecture provides an all-encompassing, holistic end-to-end view
of the business in terms of people, process, governance, and technology within (and external to) the business
to support those objectives and goals.
An Enterprise Architecture will
• visualise the structure and dynamics of an organisation (functions, processes, information, systems,
technology)
• provide a framework for proven designs (principles and patterns)
• provide a common ‘big picture’, fitting the various building blocks of design into a coherent
‘enterprise’ whole
• support the alignment of business and information systems
• documenting a ‘baseline’ for the business and IT to be used for investment decisions (strategic and
tactical)
• show areas of Common, agreed solutions
• provide flexibility, with different solutions or variants
• highlight linkages and dependencies – decisions, alternatives, consequences and
opportunities, and
• help to build a joint plan to move forward.

Without having an enterprise architecture programmes and projects work in isolations, with potential
duplications and only coincidental alignment that will lead to more complexity, higher cost, and a reduction in
flexibility.
Coming back to the term “target architecture”: According to the Open Group a target architecture “is the
description of a future state of the architecture being developed for an organization. There may be several future
states developed as a roadmap to show the evolution of the architecture to a target state. Target architecture
therefore has a timing element attached to it.”
A target architecture should at a minimum have view of the As-Is landscape, a depiction of the medium / long
term future as well as clear views related to the steps to reach that long term target. So, whereas the solution
architecture is diving into a solution detail – typically application and / or infrastructure relate – the target
architecture is concerned with what the overall target is and how to get there.
Key for the target architecture is to outline
• Current
o High level view of the current
▪ Business Model and key Business Processes
▪ Current Application set
▪ Data / Information and
▪ Infrastructure (compute, storage and network)
o The current cost profile, asset value and current value provided
o An understanding of the current issues, constrains, challenges covering all aspect
areas clients, end users, applications, information / data and infrastructure
• Future
o High level view of the future
▪ Business Model and key Business Processes
▪ Current Application set
▪ Data / Information and
▪ Infrastructure (compute, storage and network)
o Any material that we can draw together that details their target in 2-3 years’ time
from a business perspective + any market / competitor view that will force them
towards a particular route
• Transformation
o Any information that we have that outlines the scope, objectives, and durations of any
significant change programs and / or projects that are in progress or are planned

Another difference between a solution and target architecture is where and how the developed material (aka
artefacts) are being used. The solution architecture material is typically used for implementation purposes, as
it outlines in detail what the solution is and with what physical components it should be implemented. The
target architecture is used to guide and direct projects and programs as it details the medium / long term
target architecture related to business, information, applications, and infrastructure.

You might also like