Architecture solution architecture method
Download as PPT, PDF11 likes6,865 views
The document introduces the artITecture Architecture Method for documenting solution level architecture. It describes the method's primary and secondary deliverables for describing different aspects of the architecture. The primary deliverables are software, infrastructure, integration, and data architectures. Architectural thinking considers all phases of the system lifecycle and links to project management. Principles of the method include considering all lifecycle phases and project management implications.
Architecture 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/