Architecture with a Purpose
0 likes349 views
The document proposes a lightweight architecture framework called "Architecture with a Purpose" to help organizations introduce or revitalize their architecture capabilities. It consists of three main elements: purpose, stakeholders and concerns, and common modeling. The purpose is to address complexity while meeting stakeholder needs. Stakeholder groups and their concerns are detailed. Common modeling provides standard domains, elements, viewpoints and guidelines to document architectures consistently. The framework is intended to introduce architecture in a lightweight way that can later be expanded, with the main goal of addressing stakeholder concerns.
Architecture with a Purpose
- 1. Architecture with a Purpose A suggestion for a light-weight architecture framework © Heinz Tonn , May 2016
- 2. Issue • Architecture Frameworks are large specifications, consisting of methods, tools, templates and processes. There are for example 750+ pages of specification for TOGAF alone. • Some organisations hesitate and shy away from introducing architecture as they see it as an overhead or consulting gimmick. • Other organisations implement these framework on an full or almost complete scale and are then burdened with the associated overhead. • In both cases it can happen that the need or purpose of architecture is lost to most other members of the organisation because there is no architecture in the first place or it is so abstract that non-architects have difficulty understanding it. • The benefits organisations could gain by having an architecture capability are lost as a result. © Heinz Tonn , May 2016
- 3. Aim • This slide deck suggests a architecture framework called Architecture with a Purpose. • Architecture with a Purpose is a light-weight architecture framework derived from the needs of the whole organisation, not just architects. • Thus the framework is based on the purpose of architecture which is to serve the enterprise. • This framework can be extended to a full-scale framework and should only be seen as a first step to introduce or revitalise architecture in an organisation. • This slide deck provides an introduction and definition to Architecture with a Purpose in under 20 pages. © Heinz Tonn , May 2016
- 4. Overview The framework consists of 3 main elements 1. Purpose – Justification, basic introduction and setting the frame for the following parts. 2. Stakeholder & Concerns – Detailing stakeholder groups and their concerns. 3. Common Modelling – Detailing which elements to use, how to structure those and what the resulting viewpoints are. Structure and elements provide comparability of the documented architectures across the IT landscape. The delivered viewpoints address stakeholder concerns. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints IT Service Management The Project The Business Fellow Architects © Heinz Tonn , May 2016
- 5. Purpose • The generic purpose of architecture is to manage the complexity • Complexity is part of any IT project in todays fragmented landscape of IT solutions and services and collaborating businesses. • In addition, architecture is to ensure that the solution, system or service delivered by a project fits the needs of the client or owner and satisfies the expectations of the users. • Furthermore there are also needs in the wider organisation, such as IT service management having to operate the solution, as well as other stakeholders as detailed in the next part. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints IT Service Management The Project The Business Fellow Architects © Heinz Tonn , May 2016
- 6. Stakeholder & Concerns There are the four main stakeholder groups and their interests or concerns in no specific order. • The Business – Business owners, budget holders and non-technical users of the solution. • The Project – Staff implementing and delivering the IT and possibly organisation changes. • Fellow Architects – Domain, technical and subject- matter experts. • IT Service Management – IT staff managing and operating the delivered service or solution. Details of each Stakeholder Group are detailed on the next slides. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints IT Service Management The Project The Business Fellow Architects © Heinz Tonn , May 2016
- 7. Stakeholder & Concerns The Business • Stakeholder • Business owner as the main requestor and budget holder paying for the solution or service. • Business administrator managing users and their usage. • Business or public user as consumer of information. • Concerns • That the business requirements, objectives and constraints are meet. • That the solutions or service facilitates the desired business outcome. • That the solution provides value-for-money and is delivered in the agreed timeframe. • Typical Deliverables • Solution Description as in a manual, NOT a design or assembly instruction. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 8. Stakeholder & Concerns The Project • Stakeholder • Programme manager responsible for the business outcome. • Portfolio manager, responsible for alignment between different programmes and projects. • Project manager responsible for timely delivery within budget. • Concerns • That deliverables and tasks to implement the solution are known (from plan to hand-over). • That it fits into the available budget and timeframe. • That all resource requirements are known and feasible. • Typical Deliverables • Design (High Level, Low Level) as in a description of how to build the solution (Bill of Material, assembly sequence, cost & effort estimates). Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 9. Stakeholder & Concerns Fellow Architects • Stakeholder • Design authority as the governor of standards, for e.g. information security or legal. • Domain expert as the expert for a specific business unit. • Technical or subject-matter expert (e.g. storage architect). • Concerns • That generic or common constraints and requirements are meet (e.g. security, safety). • That generic or common objectives are observed. • That the resulting solution fits into the overall IT landscape. • That there is no duplication or “silofication”. • Typical Deliverables • Covered by deliverables for other stakeholder groups (e.g. Design, Solution Description). Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects
- 10. Stakeholder & Concerns IT Service Management • Actual stakeholder • Service management responsible for managing service or solution quality with the service users and owners. • IT operations responsible for running and maintaining the solution or service. • System administration responsible for the resolution of requests and incidents (e.g. help desk, support). • Concerns • That the expected service quality can be delivered. • That the requirements to operate and manage the solution are known (e.g. documentation, skills). • That the change requirements are known (i.e. improve, extend, scale). • Typical Deliverables • Manuals, Design (post go-live and updated version, not the pre-implementation version). Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 11. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects Common Modelling This part contains the basics of how architectures should be visualised, described and documented. • Domain Model – Modelling structure. • Common Elements –Element types or components to be used for modelling. • Viewpoints – Visualisations and their descriptions. • Modelling Guidelines – Rules for modelling. © Heinz Tonn , May 2016
- 12. Common Modelling Domain Model The following domains should be used to structure the common elements: • User & Processes – Roles and activities outside IT. • IT Workplace – User interfaces and devices through which user utilise IT. • Network – connectivity between devices or sensor on one side and data centre resources in the backend. • Information Technology – hardware, software for information processing as well as supporting IT resources and services (e.g. directories). Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 13. Common Modelling Common Elements These are element types to be used and the domain they should appear in. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016 DomainsCommon Elements User & Process Workplace Network Information Technology </ > User Network Device Process or Task Device or Client Client Application Access Network Technology Application or Configuration Server Storage Service </>
- 14. Common Modelling Modelling Guidelines 1. The Domain Model is a mandatory standard; no other domains should be introduced. 2. The Common Elements are a mandatory standard, no other element types should be introduced. 3. Additional domains and element types need to be carefully and centrally managed to ensure comparability across different architectures. 4. An actual elements can have different shapes and forms but should correspond to only one of the Common Elements (e.g. Device = Mobile, Laptop, Thin Client) Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 15. Common Modelling Modelling Guidelines 5. The Viewpoints represent a minimum standard, meaning that additional views, visualisations or descriptions can be added above and beyond as long as they refer to the same Common Elements. 6. External Services used by the solution can be represented as a black box, without domain association or common element use but an interface to other elements. 7. All interfaces and information flows should be shown as connectors between common elements. No element can be un-connected. 8. Elements or services one removed from the scope boundaries should be modelled to cover the interface or information flow. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 16. Common Modelling Viewpoints Overview Diagram – All used elements in their domains and interfaces. Process Diagram – Interactions of how the solution or service is used and maintained. Work Breakdown Structure – BoM and the associated work to be carried out (tasks). Plan – Sequence constraints of tasks, dependencies between tasks, durations. Information Security Diagram – Overlay of the Overview Diagram to address security. Service Level Assurance – Overlay of the Overview Diagram to show how service levels are achieved. Stakeholders & Concerns Purpose Common Modelling Modelling Guidelines § Domain Model Common Elements User & Process Workplace Network Information Technology </> Viewpoints The Business The Project IT Service Management Fellow Architects © Heinz Tonn , May 2016
- 17. Addressed Concerns Loop-Back from Common Modelling to Stakeholder Concerns The following table shows how and where Stakeholder Concerns are addressed by the Viewpoints of Common Modelling. © Heinz Tonn , May 2016 Stakeholders&Concerns The Business The Project IT Service Management Fellow Architects Overview Diagram Process Diagram Work Breakdown Structure Service Level Assurance Information Security Plan Viewpoints For information only Validation of Business Requirements Assurance of Value-for-Money Assurance of expected delivery Validating BoM and interfaces Deriving testing requirements Validating work scope Validating system requirements Assurance of feasibility Understanding security concept Identify potential IT dependencies or redundancies Assurance of standard and policy adherence Assurance of technical feasibility Assurance of security policies and standards For information only Understanding support and helpdesk requirements For information only Understanding support and management requirements Assurance of hand- over to service timeline Understanding security operations requirements For information only For information only Assurance of Business Security Requirements Identify potential business dependencies or redundancies
- 18. Summary • Introducing architecture to an organisation doesn't need to be a pain and is no rocket science. • Introducing architecture actually benefits the organisation. • It just depends of the framework which is proposed and the benefits it has. • The architecture framework proposed here provides the following benefits: • Architecture with a Purpose is purpose-driven as the main aim of Common Modelling is to address Stakeholder Concerns (see previous slide). • Architecture with a Purpose is light-weight (explained in under 20 slides). • Architecture with a Purpose can be extended by experienced architects to a full-scale architecture capability without change, only additions. • Architecture with a Purpose might just be the right way for some organisations to introduce an architecture capability from scratch or revitalise an existing architecture capability. © Heinz Tonn , May 2016
- 19. Thank you for your attention Heinz Tonn Freelance Enterprise Architecture Consultant Find me on LinkedIn uk.linkedin.com/in/heinztonn © Heinz Tonn , May 2016