Documenting Architecture IASA/ICS March 27th

Transcription

1 March 2014 Documenting Architecture IASA/ICS March 27th Alistair Herriott Gar Mac Criosta

2 2 Topics Background, why documentation? Skills Pillars Architecture Engagement Model Architecture Roadmap Views and ViewPoints etc

3 Background, why documentation? You have been asked by your prospective customer, CIO/CTO, Project Manager or Operations team to deliver the right IT architecture documentation for their project? Each of these different stakeholders will have their own drivers for having this documentation, which means for you, they will probably need different content. Even if you manage to get all the content together the next challenge will be to communicate the key IT architecture decisions that led to your proposed solution. To deliver this successfully you will have to apply a number of IT Architecture skills that IASA has identified including Business Technology Strategy, Human Dynamics, IT Environment, Design and Quality Attributes.

4 4 Topics Background, why documentation? Skills Pillars Architecture Engagement Model Architecture Roadmap Views and ViewPoints etc

5 Skills Pillars Enterprise Architecture Solution Architecture Specializations Software Architecture Infrastructure Architecture Information Architecture Business Architecture Foundation Body of Knowledge Business Technology Strategy Foundation IT Environment Quality Attributes Design Human Dynamics

6 6 Topics Background, why documentation? Skills Pillars Architecture Engagement Model Architecture Roadmap Views and ViewPoints etc

7 What role are you playing? Enterprise Architects Finance Sales LOB IT Business Architects Information Architects Business Capability Solution Architects Infrastructure Architects Data Center Software Architect Software Architect

8 Where in the process are you? Project Inception Architecture Gates Deploy Requirements Design Deliver Iterate Gated delivery process allows architects to review and approve Covers many more projects

9 9 Topics Background, why documentation? IASA Pillars Architecture Engagement Model Architecture Roadmap Views and ViewPoints etc

10 Architecture Roadmap - Layout Conceptual Model Capability Value Capability Transition Plan Current to Target Business Model Canvas Architectural Principles Engagement Model

11 Architectural Roadmap - Example

12 Architectural Roadmap Conceptual

13 13 Topics Background, why documentation? IASA Pillars Architecture Engagement Model Case Study - Business Online Retailer Architecture Roadmap Views and ViewPoints etc

14 You need to have a framework to describe the architecture to the different stakeholders. Key ideas Templates Completed templates - ViewPoints - Views

15 Example: Viewpoint Library-Definitions Functional Describes the system's functional elements, their responsibilities, interfaces, and primary interactions. A Functional view is the cornerstone of most ADs and is often the first part of the description that stakeholders try to read. It drives the shape of other system structures such as the information structure, concurrency structure, deployment structure, and so on. It also has a significant impact on the system's quality properties such as its ability to change, its ability to be secured, and its runtime performance. Information Describes the way in which the architecture stores, manipulates, manages, and distributes information. The ultimate purpose of virtually any computer system is to manipulate information in some form, and this viewpoint develops a complete, but high-level view of static data structure and information flow. The objective of this analysis is to answer the big questions around content, structure, ownership, latency, references, and data migration. Concurrency Describes the concurrency structure of the system and maps functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently and how this is coordinated and controlled. This entails the creation of models that show the process and thread structures that the system will use and the inter-process communication mechanisms used to coordinate their operation. Development Describes the architecture that supports the software development process. Development views communicate the aspects of the architecture of interest to those stakeholders involved in building, testing, maintaining, and enhancing the system. Deployment Describes the environment into which the system will be deployed, including capturing the dependencies the system has on its runtime environment. This view captures the hardware environment that your system needs (primarily the processing nodes, network interconnections, and disk storage facilities required), the technical environment requirements for each element, and the mapping of the software elements to the runtime environment that will execute them. Operational Describes how the system will be operated, administered, and supported when it is running in its production environment. For all but the simplest systems, installing, managing, and operating the system is a significant task that must be considered and planned at design time. The aim of the Operational viewpoint is to identify system-wide strategies for addressing the operational concerns of the system's stakeholders and to identify solutions that address these. v2.0, from Software Systems Architecture : Woods & Rozanski

16 Viewpoints Taxonomy/Layout Definition Overview of the viewpoint Concerns Which concerns it addresses Models Which diagrams are used within it Pitfalls Limits and issues with its use Stakeholders Stakeholders interested in the viewpoint Applicability The scope and context to which it applies v2.0, from Software Systems Architecture : Woods & Rozanski

17 Viewpoint Functional Functional the functional structure of the system Content: the system s runtime functional elements and their responsibilities, interfaces, and primary interactions Concerns: functional capabilities, external interfaces, internal structure, and design philosophy Models: functional structure model Pitfalls: poorly defined interfaces, poorly understood responsibilities, infrastructure modelled as functional elements, overloaded view, diagrams without element definitions, difficulty in reconciling the needs of multiple stakeholders, inappropriate level of detail, God elements, and too many dependencies v2.0, from Software Systems Architecture : Woods & Rozanski

18 Viewpoint Information The information structure, ownership and processing in the system Content: how the system stores, manipulates, manages, and distributes information Concerns: information structure and content; information flow; data ownership; timeliness, latency, and age; references and mappings; transaction management and recovery; data quality; data volumes; archives and data retention; and regulation Models: static data structure models, information flow models, information lifecycle models, data ownership models, data quality analysis, metadata models, and volumetric models Pitfalls: data incompatibilities, poor data quality, unavoidable multiple updaters, key matching deficiencies, poor information latency, interface complexity, and inadequate volumetrics v2.0, from Software Systems Architecture : Woods & Rozanski

19 Viewpoint Concurrency The packaging of the system into processes and threads Content: the concurrency structure of the system, mapping functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently, and how this is coordinated and controlled Concerns: task structure, mapping of functional elements to tasks, inter-process communication, state management, synchronization and integrity, startupand shutdown, task failure, and re-entrancy Models: system-level concurrency models and state models Pitfalls: modelling of the wrong concurrency, excessive complexity, resource contention, deadlock, and race conditions v2.0, from Software Systems Architecture : Woods & Rozanski

20 Viewpoint Development The architectural constraints on the development process Content: how the architecture supports and constraints the software development process Concerns: module organization, common processing, standardization of design, standardization of testing, instrumentation, and codeline organization Models: module structure models, common design models, and codeline models Pitfalls: too much detail, overburdening the AD, uneven focus, lack of developer focus, lack of precision, and problems with the specified environment v2.0, from Software Systems Architecture : Woods & Rozanski

21 Viewpoint Deployment The runtime environment and the distribution of software across it. Content: the environment into which the system will be deployed, including the dependencies the system has on its runtime environment Concerns: types of hardware required, specification and quantity of hardware required, third-party software requirements, technology compatibility, network requirements, network capacity required, and physical constraints Models: runtime platform models, network models, and technology dependency models Pitfalls: unclear or inaccurate dependencies, unproven technology, lack of specialist technical knowledge, and late consideration of the deployment environment v2.0, from Software Systems Architecture : Woods & Rozanski

22 Viewpoint Operational How the system is installed, migrated to, run and supported Content: describes how the system will be operated, administered, and supported when it is running in its production environment Concerns: installation and upgrade, functional migration, data migration, operational monitoring and control, configuration management, performance monitoring, support, and backup and restore Models: installation models, migration models, configuration management models, administration models, and support models Pitfalls: lack of engagement with the operational staff, lack of backout planning, lack of migration planning, insufficient migration window, missing management tools, lack of integration into the production environment, and inadequate backup models v2.0, from Software Systems Architecture : Woods & Rozanski

23 Architecture is the decisions not the model or diagram. You need a register of decisions Heading Description Issue ID Provide and ID for the register. Issue Decision Status State the architecture design issue being addressed. Clearly state the solution chosen. What is the status of the decision, pending, decided or approved. Group Technology domain that the decision is made application, integration, data, etc. Assumptions Describe the assumptions made relevant to the decision. Alternatives List alternative options that were considered before the decision was made. Argument Implications Related Decisions Notes Outline why a position was selected. Describe the decisions implications e.g. side effects. List decisions related to this decision. Any background notes.

24 End of Section