Architecture Centric Engineering and TOGAF to Platform
G. Edward Roberts
6/30/2011 [email protected] Copyright 2011
Engineering “V”
http://www.nist.gov/director/planning/upload/report02-3.pdf6/30/2011 [email protected] Copyright 2011
Standard Definition of Architecturearchitecture: the fundamental organization of a system embodied in its
components, their relationships to each other and to the environment and the principles guiding its design and evolution. - ISO 42010:2007
In TOGAF 9, "architecture" has two meanings depending upon its contextual usage:
1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation
2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
Version 1.0
Evolution
Version 2.0
Design
Implementation
6/30/2011 [email protected] Copyright 2011
My DefinitionArchitecture: “Capturing the Larger Context (Meta-level)”
??
?
Non-Functional Functional
SystemTo be built
Non-Functional (Software/Hardware Example):Memory FootprintLatencyExecution Time“Security”RiskMTF – Mean Time to Failure
“Capturing The Larger Context (influencers) that effects the system to be built.”
6/30/2011 [email protected] Copyright 2011
6
Enterprise Architecture’s Effect
Enterprise
TechnicalArchitecture
BusinessGoals
Governance
OrganizationBusinessRequirements
Influencers
QualityV&VMission
Assurance
6/30/2011 [email protected] Copyright 2011
ACE (Architecture Centric Engineering)
http://www.sei.cmu.edu/library/abstracts/brochures/aceinitiativeinformation.cfm
ACE@SEI: to improve product development and quality by using architecture to gain early confidence in achieving system-related business and mission goals.
One component of the SEI Architecture is AADL (Architecture Analysis and Design Language)
6/30/2011 [email protected] Copyright 2011
ACE View of Architecture
• Architecture is the primary carrier of system qualities, such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision.
• Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system.
• Architecture holds the key to post deployment system understanding, maintenance, and mining efforts.
• Architecture is the conceptual glue that holds every phase of the project together for all its many stakeholders.
6/30/2011 [email protected] Copyright 2011
Example: Medical Imaging Company
Fundamental Questions (for an architect):1. Is the Architecture Scalable?... Why? they wantto do twice the business they now have ,but can they do it?
2. Is the Architecture Repeatable?... Why? They want to openUp new business centers
3. Is the Architecture Replaceable?... Why? They have a lot of old systems that are coming due to be changed out… and some“single point of failure” people
From Elparazim, my consulting business
Architectural Description
6/30/2011 [email protected] Copyright 2011
“illities”http://www.softwarearchitecturenotes.com/architectureRequirements.html
An "ility" is a characteristic or quality of a system that applies across a set of functional or system requirements. So, performance is an "ility" because it is applied against some of the functional or system requirements. Anything that can be expressed in the form "for a set of functional or system requirements, the system must fulfill them this way (this fast, this reliable, etc.)" is an "ility."
The architecture has other requirements. It is the job of the software architect to find and talk to the right people about them -- the system "ilities.“
6/30/2011 [email protected] Copyright 2011
Some “illities”
• accessibility
• accountability
• accuracy
• adaptability
• administrability
• affordability
• auditability
• autonomy
• availability
• credibility
• process capabilities
• compatibility
•composability•configurability•Correctness•customizability•debugability•degradability•determinability•demonstrability•dependability•deployability•discoverability•distributability
http://en.wikipedia.org/wiki/Ilities
6/30/2011 [email protected] Copyright 2011
Architecture Tradeoff Analysis Method (ATAMTM)
Quality Attribute Goals
http://www.sei.cmu.edu/architecture/tools/atam/6/30/2011 [email protected] Copyright 2011
Capture at a Conceptual Meta-Level
6/30/2011 [email protected] Copyright 2011 13
Detonation
Weapon SystemCommand Center
DetonationMessage
Bu
sin
ess
Pro
cess
Lev
elSo
luti
on
Sp
ace
ReliabilitySecurityLatency
Architecture “illities”
“Channel”
ContinuouslyTransmitting
Launch Vehicle
Operation Policy
“Requirement”
Capturing a Domain Issue
6/30/2011 [email protected] Copyright 2011 14
Abstractions
Merger 1
Merger 2
Merger 3
This takes skill and experience
“Eliminate x% of CO2 emissionsFrom our cars.”
Is this really the business goal?
Be careful you may not be at anAbstract enough level.
Outside the Box thinking
6/30/2011 [email protected] Copyright 2011 15
1 kg of meat from produces kg CO2e
beef 34.6
lamb 17.4
pork 6.35
chicken4.57
A Cow releases 70 and 120 kg of Methane per year. Methane is 23 times higher than the effect of CO2.
100 kg Methane per year for each cow is equivalent to about 2'300 kg CO2 per year.
Let's compare this value of 2'300 kg CO2: The same amount of carbon dioxide (CO2) is generated by burning 1'000 liters of petrol. With a car using 8 liters of petrol per 100 km, you could drive 12'500 km per year (7'800 miles per year).
Business Goal: Eliminate Y amount of CO2
Maybe our problem is makingChicken taste like beef?
MDA: Tool Support
6/30/2011 [email protected] Copyright 2011 16
MDA: Model Driven Architecture From the OMG (Object Modeling Group)
CIM
PIM
PSM
Concept Independent Model
Platform Independent Model
Platform Specific Model
Why Does This Type of Architecture Not Happen
6/30/2011 [email protected] Copyright 2011 17
“Its Hard”
Business-ist Technology-ists
The Great Divide
Language 1 Language 2
“They Play Golf, WeSit in Cubicles”
“We take risks, theyplay it safe”
Much of architecture is having to Deal with the personalities involved.
Architects
Team Dimension Profile
6/30/2011 [email protected] Copyright 2011 18
C - Creators
A - AdvancersR - Refiners
E - Exectors
x
Lists
Ideas
TOGAF 9 Parts(The Open Group Architecture Framework)
Enterprise Architecture
These are items to develop Architecturesand Architecture Capabilities
(process and framework)6/30/2011 [email protected] Copyright 2011
TOGAF 9 Part Relationships
6/30/2011 [email protected] Copyright 2011
History of TOGAF
6/30/2011 [email protected] Copyright 2011
TOGAF 9 Phases
6/30/2011 [email protected] Copyright 2011
Views of TOGAF
6/30/2011 23
Prelim (Capability and Tailoring)
VisionPhase A
DomainSpecificationPhase B,C,D
Solutions and DevelopmentPhase E,F,G
GoverancePhase H
WHAT HOW CHANGE
B - BusinessC - Data/ApplicationD - Technology
[email protected] Copyright 2011
Preliminary Phase
6/30/2011 [email protected] Copyright 2011
Phase A: Architecture Vision
6/30/2011 [email protected] Copyright 2011
Stakeholder Map
6/30/2011 [email protected] Copyright 2011
Stakeholders and Views
6/30/2011 [email protected] Copyright 2011 27
Business Cost View
What does it cost to collect entity data?What does it cost to store data?What Revenue are we generating from the data?
Legal Risk View
What potential risk is there in havingthe data?What is the cost of those risks?
Phase B: Business Architecture
6/30/2011 [email protected] Copyright 2011
Phase B: Workproducts
6/30/2011 [email protected] Copyright 2011
“Standard” Domains in TOGAF 9
6/30/2011 [email protected] Copyright 2011
General Process over Domain Specification
6/30/2011 31
Identify Stakeholders
Produce Views of the Architecture
Select Reference Models
Select Tools
Develop BaselineArchitecture Description
DevelopTargetArchitecture Description
Do Gap AnalysisRoadmap
Components
Impact on Architecture
Review with Stakeholders
ArchitectureDefinition Document
Finalize Architecture
[email protected] Copyright 2011
Phase C: Information System Architecture
6/30/2011 [email protected] Copyright 2011
Workproduct: Data Migration Diagram
6/30/2011 [email protected] Copyright 2011
Workproduct: Application Communication Diagram
6/30/2011 [email protected] Copyright 2011
Phase D: Technology Architecture
6/30/2011 [email protected] Copyright 2011
Phase E: Opportunities and Solutions
6/30/2011 [email protected] Copyright 2011
Phase F: Migration Planning
6/30/2011 [email protected] Copyright 2011
Phase G: Implementation Goverance
6/30/2011 [email protected] Copyright 2011
Phase H: Architecture Change Management
6/30/2011 [email protected] Copyright 2011
Phase Interation
6/30/2011 [email protected] Copyright 2011
Content Metamodel
6/30/2011 [email protected] Copyright 2011
Enterprise Continuum
6/30/2011 [email protected] Copyright 2011
Architecture Repository
6/30/2011 [email protected] Copyright 2011
Capability Framework
6/30/2011 [email protected] Copyright 2011
Example Reference Architecture
6/30/2011 [email protected] Copyright 2011
TOGAF 9 People Certification
6/30/2011 [email protected] Copyright 2011
Architecture at a Glance
Performance & Quality Attributes
Key Dimensions of an Architecture Verification&
ValidationData Structure Behavior
Perf
orm
ance
Safe
ty,S
ecu
rity
,Ass
ura
nce
Rel
iab
ility
, Ava
ilab
ility
Op
enn
ess
(MO
SA) Business / Operational Layer
Bu
sin
ess
Un
der
stan
din
g &
An
alys
is
Pro
toty
pin
g, t
esti
ng
Eval
uat
ion
, C&
A
Service (Capability) Layer
Logical System Layer
Physical System (Hardware, Software) Layer
•An Architecture Has Breadth and Depth•Breath covers as a minimum the Data, Structure and Behavior (Service)•Depth includes the Business/Operational, Service, & System Layers (logical and Physical)
•Trades are used to derive an optimum solution to solve the Business Problems•Gray scale shows relative emphasis to the Layers
47
Trades
Drives Verifies
Edwin Lee 20106/30/2011 [email protected] Copyright 2011
48
The Matrix – Section 1
Architecture Conceptual Layers
Architecting Methods & Tools
Framework / Method
Modeling Language(Covering: Use Cases, Behavior, Data,
and Structure)
Enterprise / Operational Architecture
TOG
AF
(AD
M)
DO
DA
F M
OD
AF
NA
F
Zach
man
UM
LSy
sML
Service Architecture (Abstract)
SoaM
L
System Architecture (Abstract)
TOG
AF
To
The
Pla
tfo
rm
Implementation Physical Architecture (Architecting To The Edge) A
AD
LM
AR
TE
By Edwin Lee, Raython6/30/2011 [email protected] Copyright 2011
49
The Matrix – Section 2
Architecture Conceptual Layers
**Quality Attributes (QA) Principles & Standards
Information Security(Confidentiality ,Integrity,
Availability)Safety
(Reliability…)
Openness (Cost reduction,
Open Competition) Timeliness
Enterprise / Operational ArchitectureCyber Security Policy
Threat / Risk Assessment
Safety Policy Threat / Risk Assessment
MO
SA
OR
L
Service Architecture (Abstract)Cross Domain Security
MLS
SOA
System Architecture (Abstract)
Implementation Physical Architecture(Architecting To The Edge)
Network Security Platform Security
MILSMILS Profile, API
SC JAVARTSJ
Multi-Core API
**Quality Attributes are Non-Functional Characteristics of an Architecture
By Edwin Lee, Raython6/30/2011 [email protected] Copyright 2011
50
The Matrix – Section 3
**Quality Attributes are Assured through V & V and Associated Methods and Testing
Architecture Conceptual Layers
Quality Attributes Assurance: Validation & Verification (V&V)
Information Security(Confidentiality, Integrity,
Availability)Safety
(Reliability…)
Openness (Cost reduction,
Open Competition) Realtime-ness
Enterprise / Operational Architecture
DIS
CA
PD
IAC
AP
Vulnerability Assessment
Safety Assessment
MO
SA
OR
LA
sses
smen
ts
Service Architecture (Abstract)Cross Domain
SecurityMLS Use Case
Verification
SOA
Std
. C
om
plia
nce
System Architecture (Abstract)
CC Evaluation DO-178B
PO
SIX
C
om
plia
nce
Implementation Physical Architecture (Architecting To The Edge)
By Edwin Lee, Raython6/30/2011 [email protected] Copyright 2011
51
RTESF: TOGAF to the Platform
WorkproductProducer
BusinessVisionary
Descriptive
Prescriptive
Traceable?
Complete Process for Multiple Domains
Toolable
…
…process
If one removed that Business Goal would the workproduct stop?
Workproduct
BusinessGoal
6/30/2011 [email protected] Copyright 2011
Assurance Additions
Assurance has extra Roles, Skills, Process Steps, and Workproducts to add to ADM
Assurance has its ownReference models to Add
Assurance has its ownMeta-models to AddTo the Content Framework
Assurance has extendedGuidance on how to developAssured Systems
Assurance has extraThings that must be stored in a repository
Assurance has extraThings that must be done to ensure an Assurance capability is built in an organization
6/30/2011 [email protected] Copyright 2011
RTESF TOGAF to the Platform Big Picture
TOGAF(Modeled)
RTESF Plugin
DevelopmentProcess (e.g.
RUP)
AADL
SysML
UML
SPEM2
SPEM2
RTESFTechnologyProcess
MARTEINCOSE OOSEM?
RTESF ReferenceModel etc.
ADMDomain Specific GuidanceRoles (i.e. Skill Sets)Added WorkproductsAdded TasksEtc.
Assurance Cases
6/30/2011 [email protected] Copyright 2011
54
Process?
TOGAF
SysML
AADL
Acceleo
UML2
RT Java 5With Annotations
ATL
ATL
System
Enterprise
“Electronics”
Software
Implementations
Phase D
ATL = Atlas Transform Language6/30/2011 [email protected] Copyright 2011
How: Modeling And Plugins
Base TOGAF Plugin
EPF
Tailoring Plugin
“weave”
Tailored Process (e.g. HTML)
1. Changes: Name changes (we call phase B task 2 “this” instead of “that”2. Replacements: Instead of doing Phase B task 2, we require one to do this task3. Additions: after doing Phase B task 2 , then we add this extra task4. Workproducts: you must do an additional workproduct out of that task5. Roles: there is a role on the team for a person with these real-time skill sets
New Task
New Role New Workproduct
Primitives
Value: Process Adoption is Quicker because one does not Have to start from scratch.
6/30/2011 [email protected] Copyright 2011
HTML output from EPF
6/30/2011 [email protected] Copyright 2011
Plugin TypesWhat if we could give a industry vertical version of TOGAF (e.g. Banking)? What about a domain version of TOGAF (e.g. Real-time)?
TOGAF Tailoring
Industry Domain( e.g. Banking)
Technology Domain( e.g. SOA)
Disipline Domain( e.g. Security, Realtime)
Techniques( e.g. ROI)
Modularized TOGAF
Specific Workproducts(e.g. DODAF)
More/Less Detailed Modules
Profiles/Configurations –(take pieces of different Modules and combine together forA particular purpose)6/30/2011 [email protected] Copyright 2011
Multi-Module Issue
Base TOGAF Plugin
Tool
e.g. SOA, Security, High Assurance
Extentsion Plugin
“weave”
“Requirement: need to be able to extend TOGAF with many different extensions at the same time”
e.g. HTML
6/30/2011 [email protected] Copyright 2011
Value: Less Risk of AdoptionWhat if we could make your investment in TOGAF sustainable (i.e. minimal changes when we go from version n to n+1)?
Base TOGAF Plugin
Tool
Future TOGAF Changes
“weave”
New TOGAF Plugin
Need to Retain investment in tailoring as new releases comeAlso mitigates rate-of-change issues
Base TOGAF Plugin $
6/30/2011 [email protected] Copyright 2011
Imagine This: Benchmarking
What if we could benchmark different configurations of TOGAF?
Isn’t this what every industry is trying to get to… Capability Maturity Models (CMM)That allow one to measure and improve a process…
6/30/2011 [email protected] Copyright 2011
Eclipse Process Framework (EPF)
6/30/2011 [email protected] Copyright 2011
EPF: Work Breakdown
6/30/2011 [email protected] Copyright 2011
RTESF TOGAF to the Platform Big Picture
TOGAF(Modeled)
RTESF Plugin
DevelopmentProcess (e.g.
RUP)
AADL
SysML
UML
SPEM2
SPEM2
RTESFTechnologyProcess
MARTEINCOSE OOSEM?
RTESF ReferenceModel etc.
ADMDomain Specific GuidanceRoles (i.e. Skill Sets)Added WorkproductsAdded TasksEtc.
Assurance Cases
6/30/2011 [email protected] Copyright 2011
Two Areas of Interaction with TOGAF
• (Area 1) Extend TOGAF to include Real-time and Embedded concepts (Requirement: Add Extentions into TOGAF)
• (Area 2) Integrate TOGAF with a much more prescriptive process such as RUP (Rational Unified Process) or openUp, for a complete Enterprise to working code approach to Real-time and Embedded projects
New Task
New RoleNew Workproduct
6/30/2011 [email protected] Copyright 2011
65
Requirement: Integrate TOGAF with other Processes and Lifecyces
Descriptive
Prescriptive
TOGAF Realm
e.g. RUP or openUP Realm
touchpoints
workproducts<<flow>>
<<produce>>
<<reference>>
openUP Model
TOGAF Model
6/30/2011 [email protected] Copyright 2011
Reference
• See http://www.aprocessgroup.com/products/product_02_010402.asp
• http://www.opengroup.org/architecture/togaf9-doc/epf/
6/30/2011 [email protected] Copyright 2011
Assurance Cases
SysA Metamodels of Interest• ARM (Argumentational Metamodel)
• SAEM (Software Assurance Evidence Metamodel)
These are being combined into one metamodel:
• SACM (Structured Assurance Case Metamodel)
6/30/2011 [email protected] Copyright 2011
Toulmin’s Model
the position or claim being argued for; the conclusion of the argument
exceptions to the claim; description and rebuttal of counter-examples and counter-arguments
reasons or supporting evidence that bolster the claim
specification of limits to claim, warrant and backing. The degree of conditionality asserted (Assumptions)
support, justification, reasons to back up the warrant
the principle, provision or chain of reasoning that connects the grounds/reason to the claim.
Implications
6/30/2011 [email protected] Copyright 2011
Toulmin’s Example
6/30/2011 [email protected] Copyright 2011
70
SAEM And ARM
Claims & Arguments
(ARM)
Evidence
artifacts
Statements
‘Leaf’ Statements
Things/Relations
Inferential support between
statements
Assurance Case
ISO 15026
Propositions are based on a particular
ontology
Leaf Claims require
non-inferential support
Who did What Whenontology/vocabulary
Evidence documentadministrative
Evidence element
from ARM
fact model
Claims and subclaims
6/30/2011 [email protected] Copyright 2011
ARM Metamodel
6/30/2011 [email protected] Copyright 2011
SAEM Meta-model
6/30/2011 [email protected] Copyright 2011
GSN
Toulmin: Warrant
Supported By
Goal
Strategy
A strategy describes the nature of the inference that exists between one or more goals and another goal.
presents a claim forming part of the argument.
SolutionToulmin: Evidence
6/30/2011 [email protected] Copyright 2011
6/30/2011 [email protected] Copyright 2011
Example: From D-CASE
6/30/2011 [email protected] Copyright 2011
D-CASE Tool
6/30/2011 [email protected] Copyright 2011
D-CASE: Assurance Case Process Metamodel (ACPM)
Yutaka MatsunoUniversity of Tokyo, [email protected]
6/30/2011 [email protected] Copyright 2011
D-CASE: Changing the Basic Process
6/30/2011 [email protected] Copyright 2011
Summary
RTESF (Real-Time Embedded System Forum) of The Open Group is forging TOGAF to the Platform, Why don’t you join us!
Questions we AnsweredWhy Architecture: Engineering “V” show us that we need to capture errors soonerWhat is Architecture: Capturing Larger ContextWhat do we do with Architecture: Manage the “illities”What Level do we want with Architecture: Enterprise, nothing less will doWhat Architecture Standard do we use: TOGAF 9
ProjectsTOGAF to the PlatformAssurance Cases with D-CASE
6/30/2011 [email protected] Copyright 2011