Post on 17-Aug-2018
Architecture Centric Engineering and TOGAF to Platform
G. Edward Roberts
eroberts@elparazim.com
6/30/2011 1eroberts@elparazim.com Copyright 2011
Engineering “V”
http://www.nist.gov/director/planning/upload/report02-3.pdf6/30/2011 2eroberts@elparazim.com 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 4eroberts@elparazim.com 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 5eroberts@elparazim.com Copyright 2011
6
Enterprise Architecture’s Effect
Enterprise
TechnicalArchitecture
BusinessGoals
Governance
OrganizationBusinessRequirements
Influencers
QualityV&VMission
Assurance
6/30/2011 eroberts@elparazim.com 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 7eroberts@elparazim.com 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 8eroberts@elparazim.com 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 9eroberts@elparazim.com 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 10eroberts@elparazim.com 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 11eroberts@elparazim.com Copyright 2011
Architecture Tradeoff Analysis Method (ATAMTM)
Quality Attribute Goals
http://www.sei.cmu.edu/architecture/tools/atam/6/30/2011 12eroberts@elparazim.com Copyright 2011
Capture at a Conceptual Meta-Level
6/30/2011 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 19eroberts@elparazim.com 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
eroberts@elparazim.com Copyright 2011
Stakeholders and Views
6/30/2011 eroberts@elparazim.com 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?
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
eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 eroberts@elparazim.com 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 52eroberts@elparazim.com 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 53eroberts@elparazim.com 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 eroberts@elparazim.com 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 55eroberts@elparazim.com 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 57eroberts@elparazim.com 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 58eroberts@elparazim.com 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 59eroberts@elparazim.com 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 60eroberts@elparazim.com 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 63eroberts@elparazim.com 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 64eroberts@elparazim.com 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 eroberts@elparazim.com Copyright 2011
Reference
• See http://www.aprocessgroup.com/products/product_02_010402.asp
• http://www.opengroup.org/architecture/togaf9-doc/epf/
6/30/2011 66eroberts@elparazim.com 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 67eroberts@elparazim.com 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 68eroberts@elparazim.com 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 eroberts@elparazim.com 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 73eroberts@elparazim.com Copyright 2011
D-CASE: Assurance Case Process Metamodel (ACPM)
Yutaka MatsunoUniversity of Tokyo, Japanmatsu@cc.u-tokyo.ac.jp
6/30/2011 77eroberts@elparazim.com 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 79eroberts@elparazim.com Copyright 2011