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

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 http://chriseaton.wordpress.com The copyright of the artITecture method (‘the method’) is held by the original author, Chris Eaton who is contactable at the following email address: gruffoot@gmail.com. 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

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.

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

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

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

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’

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

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.