Post on 30-May-2020
How to embed the O-DA in TOGAF EA Activityes of ADM cycle
Junkyo(Jack) Fujieda President & CEO of ReGIS Inc.
Representative and Chairman of The Open Group Japan
• Tuesday 17 July 0900-1800 Hours – DEOS Continued -- Dr Mario Tokoro, Sony R&D/Dr Yutaka Matsuno, University of Tokyo
– Preparing IT for Mega Disasters Continued -- Dr Jane Liu, Institute of Information Science - Academia Sinica/
Dr Chi-Sheng (Daniel) Shih, National Taiwan University
• Wednesday 18 July 0830-1800 Hours – Mils™ Architecture Going Forward including Compositional Certification in a Distributed Environment -- Rance
DeLong, LynuxWorks
– Mils™ Development Practices Working Group (MDP WG) -- Steve Kuehl, Raytheon
• Project DETER – Steve Kuehl
• Security Framework - Marc Brown
• Mils Approach – Jim Alves-Foss
– TOGAF to the Platform – Ed Roberts, Elparazim
– Assurance Cases/Templates/Patterns -- Dylan McNamee, Galois/Ed Roberts, Elparazim
• Thursday 19 July 0830-1800 Hours – Architecting to the Edge -- Glen Logan, US Army
– Avionics Software Certifications Standards – Dr James Hunt, CEO & President, aicas inc.
– Component Competition Readiness Levels (CCRLs) -- Gerald Walles, US Navy – NAVAIR
– Update EC Projects -- Scott Hansen, The Open Group
– RTES Forum Going Forward -- Joe Bergmann et al., The Open Group
© 2013ReGIS Inc.
2
Real Time Embedded System Forum
1950 1960 1970 1980 1990 2000 2010 2020
Architecture SOP SOP SOP BSP
CPS ZMF
CPS ZMF
Programing
COBOL RPG AC LISP Formal Theorum
PL1 APL SP C Model Check
ADL OO
AADL
Dependability Reliability
Availability Performance
Security Integrity
Security Privacy
Safety Business Continuity
Architecture to Dependability
TOGAF
DEOS/ D-case
Dependability Architecture Framework
Dependability Through Assuredness
Exec& Op
Computable TOGAF
3 © 2013ReGIS Inc.
標準名 責任部門 Announcement
Certification
① MILS( Multi-Independent Level of Security)
Real Time Embedded System Forum
2002 YES
② Real Time Java Real Time Embedded System Forum
2014 Target
Yes
③ O-DA +Dependability Through Assuredness
Real Time Embedded System Forum
2013 -08-06
Plan
④ RISK Management Taxonomy Security Forum 2009-1 ?
⑤ OTTPF( Open Trusted Technology Partners Framework)
Board Initiative 2013-4 ?
⑥ FACE (Future Airborne Capability Environment) Board Initiative 2013-2 ?
⑦ Dependency Model (O-DM) Board Initiative?
2012-11 ?
Open Group Standard on Safety/Trusted/Dependability area
Dependability Mapping Dependability Relia
bility Availability
Serviceability
Integrity
Security
Safety
Performance
Privacy
Business Continuty
On Premises ○ ○ ○ ○ ○ ○ ○ ▽ ▽
Cloud Public ◎ ◎ ◎ ● ◎ ● ◎ ● ●
Cloud Private ◎ ◎ ◎ ◎ ○ ● ◎ ● ●
Real time Embedded
◎ ◎ ◎ ◎ ○ ● ◎ ● ●
Hardware Architecture
● ○ ○ ◎ ○ ◎ ● ▽ ▽
Software Architecture
◎ ◎
◎
◎ ●
◎ ◎ ◎
◎
Operation Architecture
- ◎
◎ ● ● ● ○ ● ●
- a few impact ; ▽ relatively less impact; ○ Average + Impact; ◎ Higher ; ● Highest Impact to Dependability
Architecture based Dependability Meta Model
Availability
Environment--Society –Enterprise-People--Operation -Software--Hardware
Reliability
DEFINED
Service Ability
Why Not Defined
DEFINED
Integrity
WHY NOT DEFINED
DEFINED
Security
WHY NOT DEFINED
Value--- COST—Trade Off
Dependability for -Management GOAL--
REDUNDANCY Makes Quality
Performance
Privacy Business
Continuity
Measure data from D-Case monitoring
nodes . Metrics being corrected [IEC 62628]
Availability
Failure frequency
Time 2 Fail
Restoration time
Fault Density
Function point
Code coverage
Failure Removal rate
Architecture ● ● ● ● ● ● ● ●
Solution ○ ○ ○
○ ○
○ ○ ○
Operation ○ ●
●
●
●
●
●
●
Residiual Failurerate
Time to Software release
Software Complexity
Functional Complexity
Safety Dependability chain
Security Dependability Chain
Privacy Dependability Chain
Business Conti- nuity Chain
Architecture ● ● ● ● ● ● ● ●
Solution ○ ○ ○ ○ ○ ○ ○ ○
Operation ○ ● ● ● ● ● ● ●
ArchiMate® Drawing Dr. Yokote;Keio Univ.
TOGAF: Architecture Governs Implementation
It’s all bout Architecture of services and products.
Architecture
Implementation
Architecture governs Implementation.
DEOS Process: D-Case Governs Change
It’s about Lifecycle of services and products.
It is iterative processes of Failure Response cycle and Change Accommodation cycle.
D-Case governs Change.
D-ADD maintains dependability chains.
Architecture
Implementation
Dependability Performance Measure
• Method No.1 – Define the basic pattern of D-Case (e.g. one Goal and one
Evidence), which is considered as “1” unit. – Calculate “units” from a given D-Case. – Calculate “coverage” of Evidence against “units”. – Compare the units than others, which can be considered as
comparison of dependability readiness.
• Method No.2 – Measure data from D-Case monitoring nodes. – Metrics being corrected [IEC 62628]:
availability, failure frequency, time-to-failure, restoration time, fault density, function point, code coverage, fault removal rate, residual faults in software, time for software release, software complexity, functional complexity.
Dependability Performance Measure
• Method No.3 – Each D-Case monitoring node has (an) In-Operation Range (IOR). – With probability approach estimates probability of occurring
“out of” IOR. • This is probability at the time of calculating it based on D-Case, i.e. we
can consider it both at development and operation. • On Implementation Governance phase of ADM, it is recommended to
evaluate it periodically.
– On estimation of probability, failure recovery directed by corresponding D-Case Action node could be taken into account.
– Such probability can be calculated with inductive statistics, based on historical records as a consequence of D-Case monitoring nodes.
– How the structure of D-Case can be considered on probability estimation needs more investigation.
Dependability Performance Measure
• Method No.4 – There are multiple dependability chains, each of which starts
from a stakeholder’s requirement through its corresponding implementation, can be measured.
– Degrading the measure is caused by: • missing chain: it cannot reach to an implementation that meets a
given consent requirement. • wrong chain: it can reach to an implementation that is irrelevant to a
given consent requirement. • each chain can be weighted based on suitability assessment.
– On Migration Planning phase in ADM, we can evaluate this measure.
• On Architecture Change Management phase, it is helpful for compliance assessment and requirements impact assessment.
Priority ISSUES to be discussed 1. Architecture Based --TOGAF ADM Based D-Case Guide Book Publish
By Jan.2014 in English 2. Target 18 Use cases implementation in Japan(9), EU & USA (9) in
Safety/Security(6) ,Business(6) Software (6);in 2014 -2015:< US $ X K per project: < Local project office : Regional management Office: Global management>
3. Target market feasibility assessment after the use cases evaluations: 4. In Parallel, D-ADD part, Repository into Guide Book of version 2.0 target
by 2014 June. 5. Guide book Version 3, Real time monitoring & adaptive change versions 3 by 2015 June; To do that can we proceed minimum of your current team activity for standardization through Real Time Embedded Systems Forum here. In Guide Book levels minimum 2 years as we had in the past two years plus some motivational funds for real Use cases implementations. To do that we need to get fund by current members, get support from US,EU & Japan government to subsidize to keep alive this standards continued to the stage Until we get global use cases keep implemented.
O-DA Landscape Architecture
Enterprise Architecture
Business
Data
Application
Technology
Architecture
TOGAF Risk management
Dependability
Architecture
TOGAF Dependability Architecture
DEOS
D-Case
D-ADD
Run Time
O-DA V1.0 Assurance V2.0 Development , Data & Repository V3.0;Maturity Model ; SDIL、update from Use cases
Mitigation for DR Plan at Architecture time
Execute at Operation time
① Get the consensus of the board on its gross values and importance of D-case assessment talking to major stake holders using any reference use cases in Repository of D-Cases. ② Get The authorization of Dependability Architecture Board development by CEO. ③Write Dependability Architecture Principle ④ Design the Board & Working group Membership official kick off
① Define the scope of Dependability with Goal, Strategy and evidence with Architect ure visions ② Define the methods of evaluation by quantitative and qualitative measures(SIL) ③ D-Case Capability defining parameters of Dependability
① Define the value of Dependability targets to achieve ② DBA( Value & Cost) ③ DBA of Goal,Staraegy, Evidence, need to be signed by head of business)
① Develop IA assurance case ②IA Assurance case Reviews(RASIS +Performance+Privacy + Business Continuity and integrated Level of Dependability )
①Dependability TA development ② DTA Review(Any change of Technology would impact on Dependability, in what context and level of integrity, asumption of risk and benifit)
Dependability ADM (Preliminary to Technology Architecture)
All process of Assurance case,Claim ,Argumentation, and Evidence issues are to be managed iteratively by Chief Dependability Architect)
① Architecture time, Solution, Operation Assurance case with evidence versioning control ② Record of un evidenced cases with its alternate solution actions reporting and filing③ All Risk management report and Hazard analysis to be managed in repository with warning to management
Governance of all phase out put for rules and principles came out from P,A,B,C,D for implementation and operation is the job of Chief Dependability Architect
① operation management (all points where people would interact has to have a special scruteny on Security Privacy Operation Sabotage and attacks in open discussions ② Assurance case development with Evidence reviewed.③ Process also to be validated with evidences of rightness④ Complete matrix cross check with all string with evidence check lists.
① Integrate BA, IA, TA dependability Cases ② Integrity check of the D-cases among phases.: ③ Outer case conditions happenen what is the remedy plan to be is the most important agreement needed with consensus with boards.
Dependability ADM (Oportunity & solution Requirement process)
Monitoring Recording Reporting
Real Time Monitor to any
change needed for normal
exceptional handling & reuse best practice standard record & Report to management
O-DA V.-3.0
ODA-V-1.0
Static D-Case
Monitor
& Record in Repository
& Report
By O-DA V-2.0
DRP
Design
O-DA Vision(JF)
“Adaptive to Changes”“Control model”
1. 人
制御モデル
物理ブロック
対応理モデㇽ
人間ブロック
DR モデル
環境ブロック
Changes with in Architecture Scope
Change in outer space of architecture
Monitor Yes Find unexpected Change
Execute Prepared Recovery solution
Yes Find Unexpected Changes
Execute Disaster Recovery Plan prepare
Execute research of other architecture Through other side of scope
Research & Architecture
Yes Find expected range of changes
Execute Real time failure recovery
yes Forecast other change item of outer Architecture
Set new monitor sensor To find other changes
Execute New outer scope based EA
Controllable Block
Yes Proof needed Formal methods
yes Proof needed
GSN/CAE Assurances
After getting enough evidence Re-architect
Operational Block
Yes Logical Validation Needed
GSN/CAE Yes GSN/CAE Argument ation
Execute Re-Architecting In a long scale
History Of Theorem Prover ; Formal Language To O-DA
CF( Prof. Robin Milner ) LOTOS
PARCH(John Guttag &Jim Horning)
B & Z (Prof. Jean-Raymond Abrial)
SAT(Boolean Satisfiaility) 1992 CMU Ken McMillan -SMV Model Cheker
Patrick Cousot Gunnar Stalmarck President and CEO,Prover
PRAXIS Anthony Hall REVEAL Jim Woodcock,
Tim Kelly, York Univ.
David Jackson ; MIT Alloy
Manfred Broy , TUM
Tony Hoare
VDM (Dines Bjørner )
From EA to Dependability We seek dependability for assuredness per the need of most perfect
proof needed building block we adapt Formal method, safety, Security, Privacy and business Continuity Dependability requirement, we choose
GSN, or SACM with TOGAF ADM process,especially operational area where human interact.transformation
O-Depend
Dependability
Architecture
Operation
Excellency
& V
1.0 O-DA
Assurance
Constant monitorng if Architecture scope changes ,then, prepare
Remedy plan as DR,
If changes are still within the scope ,then full recovery plan
be employed
Assure Business goal, strategy were met by ICT architecture to produce the capability to
achieve the goal
Technology Application Data Business
O-DA V 2.0
DADD
Repository
O-DA V.3.0 Real Time Capability Optimization & New Scope Re-Architect
Back TO
A
Start A Architecture
23
Solution Architecture
O-DA Standard Area to adopt (1) SAFETY CRITICAL INDUSTRY
(2) Business Critical Real time
(3) Consumer products Manufactures
(4) ALL Governments & SME
S pacecraft, Medical devices healthcare, Air & Auto- mobiles, Railroads, Transportation Energy , Nuclear power, Defense systems, Logistics, Advanced Manufacturing & process facilities.
Finance Information Network Distribution Services Education Retail Visiting places Entertainment For mass
people assembles
Electronic equipment Toy Tool Food Housing Farming tool
All IT end users need to review their architectures in terms of non functional dependability targets and have to have a Responsible explanation accountability for its rightness of architecture at any time, before and after the failures happen!
LIST of Industry Domain Architecture Projects Industry Domain Name of Domain Architecture Based /MAPPED
① Defense DODAF・MODAF TOGAF
② Government FEA・TOGAF TAFIM
③ Airline SABRE/AMADEUS/Galileo/World span SOP
④
Intelligent Transportation System
ITS National/ Regional Architecture SOP + FEA+ TOGAF
⑤
Tele Management Forum
195 Countries 900 Companies 65K registered TOGAF
⑥
Banking BIAN (Banking Industry Architecture Network) TOGAF
⑦ SABSA Sherwood Applied Business Security Architecture TOGAP
⑧ Energy Public Utility SMART GRID Interoperability Panel NIST・SGAC
TOGAF
⑨ Disaster Management network
Preparing IT for Mega Disasters Continued – Dr . Jane Liu, Institute of Information Science - Academia Sinica
DODAF
⑩ Medicare Architecture of clinical Message and application
TOGAF 2009 >2014
25
Core Industry Architecture Development MAPPED by TOGAF
SMART XX Requirements
Smart Government
Smart Safety Management
Smart Medicare
Smart Grid Intelligence Transportation System
Full Duplex・ Multi-modal Customer centric Architecture
Embedded Real Time Communication mobile
Big data
Cloud ・NET Virtual/Autonomy
Architecture & Analysis