1. artITecture Architecture Method
Version 1.0
30th January 2009
Author: Chris Eaton

2. Usage of the artITecture Architecture Method
The artITecture architecture method is intended for free use to anyone who may wish to use it. It is requested that any use of the method is referenced to
The copyright of the artITecture method (‘the method’) is held by the original author, Chris Eaton who is contactable at the following address:
Contributions to improve the method are encouraged but must be made freely and without commercial obligation or expectation of compensation. Any contribution to the method must be freely given, and is assumed to be freely given. Submissions may or may not become part of the architecture method. Any claim to the copyright of submitted material is relinquished on submission to the copyright holder of the artITecture method.
Any contribution used in future versions of the architecture method will be acknowledged unless the submitter requests their contribution to remain anonymous.
This architecture method will never become a commercial concern. The copyright holder will never charge for usage of the method to any user whether they are a commercial enterprise or not. NB
I feel obliged to make the above caveats and I hope they do not put you off using the method or suggesting improvements. I hope that everyone can see that the intent of these usage constraints is to ensure the method free to anyone who wishes to use it now, and in the future. With thanks
Chris Eaton

3. 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 Deliverables
the core documentation produced by solution architects describing the software, infrastructure, integration and data architectures.
Secondary Deliverables
These deliverables are likely to be produced in as an input to primary deliverables.
Tertiary Deliverables
These deliverables are produced in certain circumstances, often to assess the best of several options available.
Enterprise Architecture Deliverables
Deliverables which set the direction for solution level architectures through Standards and Target Architectures.
All deliverables are optional although completion of four primary deliverables is strongly recommended.
All deliverable are intended to be templates, that is a suggested format, feel free to adapt and improve them.

4. Project Management - Scope, Resources, Schedule
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 / EA
Feasibility
Requirements
Design
Development
Testing
Deployment
Service Delivery
....
....
Decommission
Project Management - Scope, Resources, Schedule
Service Management

5. Spheres of Influence – the work products in the artITecture Architecture Method
Target Architecture
Architecture Risk Assessment and Mitigation Plan
Architecture Overview Diagrams
Architectural Decisions
Principles
Technology Assessment
Component Architecture
Data Architecture
Architecture Scope and Context
Non-Functional Requirements
Integration Architecture
Infrastructure Architecture
EA Governance Model
Decision Model
This diagram tries to describe how closely related the different work products
Primary Solution
Work Product
Standards
Functional Requirements
Change Cases
Roadmaps
Secondary
Work Product
Tertiary
Work Product EA
Work Product

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

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

8. 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 Assessment
Integration Architecture
Architecture Overview Diagrams
Target Architecture
Functional Requirements
Standards
EA Governance Model
Component Architecture
Operational Architecture
Roadmaps
Non-Functional Requirements
Architectural Decisions
Principles
Data Architecture
Decision Model
Architecture Risk Assessment and Mitigation Plan
Change Cases
Primary Solution
Work Product
Secondary
Work Product
Tertiary
Work Product EA
Work Product

9. 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.