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 , Dａｔａ & Ｒｅpository V3.0；Ｍａｔｕｒｉｔｙ Ｍｏｄｅｌ ； ＳDＩＬ、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 ＣＭＵ Ｋｅｎ ＭｃＭｉｌｌａｎ －ＳＭＶ Model Ｃｈｅｋｅｒ

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, Ｍedical devices healthcare, Ａir & Auto- mobiles, Ｒailroads, 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 Ｓｈｅｒｗｏｏｄ Ａｐｐｌｉｅｄ Ｂｕｓｉｎｅｓｓ Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ 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