documenting architecture iasa/ics march 27th · architecture decisions that led to your proposed...
TRANSCRIPT
March
2014
Documenting Architecture
IASA/ICS
March 27th
Alistair Herriott
Gar Mac Criosta
v2.0,
2013
Topics
Background, why documentation?
Skills Pillars
Architecture Engagement Model
Architecture Roadmap
Views and ViewPoints
etc
2
v2.0,
2013
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.
v2.0,
2013
Topics
Background, why documentation?
Skills Pillars
Architecture Engagement Model
Architecture Roadmap
Views and ViewPoints
etc
4
v2.0,
2013
Skills Pillars
Software
Architecture
Infrastructure
Architecture
Information
Architecture
Business
Architecture
Enterprise Architecture
Foundation Body of Knowledge
Human Dynamics
Design
Quality Attributes
IT Environment
Business Technology Strategy
Specializations
Foundation
Solution Architecture
v2.0,
2013
Topics
Background, why documentation?
Skills Pillars
Architecture Engagement Model
Architecture Roadmap
Views and ViewPoints
etc
6
v2.0,
2013
Finance Sales LOB IT
Business Capability
Data Center
Solution Architects
Software
Architect
Software
Architect
What role are you playing?
Business
Architects
Information
Architects
Infrastructure
Architects
Enterprise
Architects
v2.0,
2013
Where in the process are you?
“Gated” delivery process allows architects to review and approve
Covers many more projects
Project Inception
Requirements Design Deliver
Iterate
Deploy Architecture
“Gates”
v2.0,
2013
Topics
Background, why documentation?
IASA Pillars
Architecture Engagement Model
Architecture Roadmap
Views and ViewPoints
etc
9
v2.0,
2013
Architecture Roadmap - Layout
Conceptual Model Capability
Value
Capability
Transition Plan
Current to Target
Business Model Canvas Engagement
Model
Architectural
Principles
v2.0,
2013
Architectural Roadmap - Example
v2.0,
2013
Architectural Roadmap – Conceptual
v2.0,
2013
Topics
Background, why documentation?
IASA Pillars
Architecture Engagement Model
Case Study - Business Online Retailer
Architecture Roadmap
Views and ViewPoints
etc
13
v2.0,
2013
You need to have a framework to describe the
architecture to the different stakeholders.
Key ideas
Templates - ViewPoints
Completed templates - Views
v2.0,
2013
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.
Example: Viewpoint Library-Definitions
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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
from Software Systems Architecture : Woods & Rozanski
v2.0,
2013
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 State the architecture design issue being addressed.
Decision Clearly state the solution chosen.
Status 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 Outline why a position was selected.
Implications Describe the decisions implications e.g. side effects.
Related Decisions List decisions related to this decision.
Notes Any background notes.
v2.0,
2013
End of Section