complete solution architecture method

1. artITecture
Architecture Method
Version 1.0
30th January 2009
Author: Chris Eaton
http://chriseaton.wordpress.com/

2. Introduction to the artITecture Method
The artITecture Architecture Method is a way to think about and communicate solution level architecture. Solution architecture
describes how a complete working solution fits together from an architectural viewpoint. Solution architecture is more granular
and definite level than Enterprise Architecture(EA). The artITecture method is intended to be scalable across small and large
projects.
Within the artITecture method, architectural thinking, decisions and design is documented through a number of different
deliverables which describe different aspects of the architecture and the thinking behind it so that others can understand why a
solution is designed in a particular manner.
Deliverables are categorised into four types as follows:
• Primary Artefacts
– the core documentation produced by solution architects describing the software, infrastructure, integration and data
architectures.
• Secondary Artefacts
– These deliverables are likely to be produced in as an input to primary deliverables.
• Tertiary Artefacts
– These deliverables are produced in certain circumstances, often to assess the best of several options available.
• Enterprise Architecture Artefacts
– Deliverables which set the direction for solution level architectures through Standards and Target Architectures.
All artefacts are optional although completion of four primary deliverables is strongly recommended.
All artefacts are intended to be templates, that is a suggested format, feel free to adapt and improve them.
Full templates for each artefact and implementation guide notes can be found here:
http://chriseaton.wordpress.com/artitecture-architecture-method/

3. Architectural Thinking
The architectural work products with the artITecture method are a way of documenting and communicating ‘architectural
thinking’ so that others may understand why a system is architected (designed) in a particular way.
When considering how to solve requirements for IT systems there is almost always more than one way to meet those
requirements. A primary skill of an architect is assessing the options and deciding (and agreeing) the best way to solve
requirements with IT solutions.
Principle 1 – Think about all aspects of the Systems Lifecycle
The first principle of the artITecture method is to consider all aspects of the systems lifecycle. This method explicitly considers all
the phases shown in the diagram below. These considerations include how the architecture affects upstream phases before
solution architecture, and downstream phases such as development, testing, deployment, etc. These upstream and downstream
considerations are explicit in the way primary architecture deliverables are documented.
Principle 2 – Think about Project Management
The second principle of the artITecture method is the linkage of architectural thinking to project management, curiously this is
often overlooked (or perhaps more generously this is not explicit) in architectural methods, yet, this is clearly crucial to
architectural choices and the follow-on implications to the overall solution implementation and ongoing delivery.
IT Strategy / .... Feasibility
EA
Requirements
Design
Development
Testing
Deployment Service Delivery
.... .... Decommission
Service
Project Management - Scope, Resources, Schedule
Management

4. Spheres of Influence – the deliverables in the artITecture Architecture Method
Target Architecture
Architecture Risk
Architecture Assessment
Architectural and Mitigation
Overview
Decisions Plan
Diagrams
Principles
Technology
Component Data
Assessment
Architecture Architecture
Architecture
Non-Functional
Scope and
Requirements
Context
Integration Infrastructure
Architecture Architecture
EA Governance
Decision Model
Model
Primary Solution
Work Product Functional
Standards
Requirements
Secondary
Change Cases
Work Product Roadmaps
Tertiary
Work Product
EA
Work Product

5. artITecture Artefacts Overview
Primary Architecture artefacts Secondary Architecture artefacts
Describes the components with the solution and the Architecture Describes the scope of the solution and the context in
Component Scope and which is sits such as user demographics and other
interactions between them, usually oriented towards the
Architecture Context systems which the solution must integration
applications and integration between component parts
Describes the environment in which the solution will run
Architecture Any pictorial representation which communicates the
including servers, partitions and storage, and where
Infrastructure Overview entire solution, or a subpart of the solution in a single
components will be placed. Describes how the solution
Architecture Diagrams picture or diagram. Usually created to communicate to a
will meet the infrastructure dependant aspects of the
specific audience.
NFRs like availability
Functional requirements are a description of the business
Describes the data stores, data elements and functions a solution must perform. Many different
Data Functional
relationships between to meet the functional and non models exist to communicate this and can range from
Architecture Requirements
functional requirements. Use Cases, Business Process Models, to good old
Requirements documents
Describes the requirements of the system such as
An architectural view of what data needs to be moved availability, performance, disaster recovery, etc. These
Integration Non-Functional
around the components within the architecture and how are qualities which do not provide business functions to
Architecture Requirements
that is achieved. users directly. Often referred to as NFRs. Arguably this is
a business deliverable.
Describes important decisions made by the architects
where several options are available. The solution should
Architectural
be non obvious. Includes the alternatives consider and
Decisions
the rationale for selecting one solution over others
considered

6. artITecture Work Product Overview
Tertiary Architecture Work Products Enterprise Architecture Work Products
Standards specify some aspect of technology to which
This can be the identification and evaluation of software, an enterprise has mandated compliance. For instance,
Technology Standards
hardware or even entire solutions in a SaaS, PaaS or ERP all Unix servers must run Linux. Usually a mechanism to
Assessment
environment. Often results in an Architecture Decision. reduce cost by doing things the same way everywhere.
Change Cases describe probable future requirements
Target A target architecture is a future state, high level,
which may influence the current architecture. Change
Change Cases Architectures architectural view.
Cases often arise from scope constraints which push
requirements from current releases to future releases.
A roadmap communicates the logical progression
Architecture Risk A risk assessment focused on the technological aspects of
Roadmaps overtime of how IT moves from it’s current state to the
Assessment and a solution and plans (tasks and owners) to reduce the
future Target Architecture.
Mitigation Plan chance of the risk occurring.
The EA governance model specifies the roles and
A decision matrix is a quantitative assessment of
responsible such as ARB membership and purpose,
different qualities of something (in this case technology)
EA Governance together with the processes and procedures which the
Decision Model to compare between different alternatives. Often used
EA will follow such as Architectural and Standards
with a Technology Assessment to compare different
Compliance
alternatives.
Principles are high level, directional statements which
drive the intent of technology within an organisation.
Principles An example could be ‘to minimise the number of
applications in an enterprise by developing global, run
once applications’

7. Gravitation Diagram of the Architectural Artefacts.
Closer proximity between artefacts means they are more interdependent
Note: this is an imperfect diagram!
Architecture
Scope and
Context
Technology
Architecture Integration Assessment
Overview Architecture
Diagrams
Target
Functional
Architecture Standards
Requirements
EA Governance
Component Operational
Model
Architecture Architecture
Roadmaps Non-Functional
Architectural
Requirements
Decisions
Architecture
Data
Principles Risk
Architecture
Decision Model Assessment
and Mitigation
Plan
Change Cases
Primary Solution
Work Product
Secondary
Work Product
Tertiary
Work Product
EA
Work Product

8. Solution Architecture Artefact Interrelationships
 One might surmise that all architectural work products are inter-related in some way or another, you would be right!
 Work Products should not developed in isolation, their development is a concurrent and inter-dependant activity.
 Time is not shown on the interrelationships chart, but as a general rule the artefacts on the left are started earlier in the
process (hopefully EA Artefacts are already available)
 Change Management is not shown on the interrelations chart, any change could affect one, or many parts of the
architecture.
What now?
 Full templates for each artefact and implementation guide notes can be found here ->
 http://chriseaton.wordpress.com/artitecture-architecture-method/