enterprise architecture for decision making in...

1

Enterprise Architecture for

decision making in MODAF

Ulrik Franke, Ph.D. student

Industrial Information and Control Systems

Royal Institute of Technology, Stockholm

ulrikf@ics.kth.se

SESAM, Stockholm, April 27, 2009

2

‘It defines a way of representing an EnterpriseArchitecture which enables stakeholders tofocus in on specific areas of interests in theenterprise, whilst retaining sight of the “bigpicture”.’

Ministry of Defence

Architecture Framework

‘To assist decision-makers, MODAF providesthe means of abstracting essential informationfrom the underlying complexity and presentingit in a way that maintains coherence andconsistency.’

3

‘Would you tell me,

please, which way I

ought to go from here?’

‘That depends a good

deal on where you

want to get to,’ said

the Cat.

‘I don’t much care

where—’ said Alice.

‘Then it doesn’t matter

which way you go,’

said the Cat.

4

LESSON #1

An Enterprise Architecture effort is not an

end in itself; it is a means to something

else. Never ever start an EA effort before

you know what you want to achieve.

5

IT DepartmentDecision Domain

Information System sDecision Domain

BusinessGoal Domain

DECISION MAKING

Delivery QualityDelivery Quality

100%0%

AvailabilityAvailability

100%0%

6

?

DECISION MAKING

7

MaturityMaturity

54321

MaturityMaturity

54321

Delivery QualityDelivery Quality

100%0%

BusinessElectricity Distribution

IT DepartmentAvailability Management

Information SystemsSCADA System

AvailabilityAvailability

100%0%

DECISION MAKING

8

BusinessElectricity Distribution

Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

IT DepartmentAvailability Management

Information SystemsSCADA System

AvailabilityAvailability

100%0%

DECISION MAKING

9

?

DECISION MAKING

10

MaturityMaturity

54321

MaturityMaturity

54321

Delivery QualityDelivery Quality

100%0%

BusinessElectricity Distribution

IT DepartmentAvailability Management

Information SystemsSCADA System

AvailabilityAvailability

100%0%

AvailabilityAvailability

100%0%

Delivery QualityDelivery Quality

100%0%

DECISION MAKING

11

BusinessElectricity Distribution

Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

IT DepartmentAvailability Management

Information SystemsSCADA System

AvailabilityAvailability

100%0%

AvailabilityAvailability

100%0%

DECISION MAKING

12

?Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

Delivery QualityDelivery Quality

100%0%

DECISION MAKING

13

LESSON #2

Different decisions require different

information. Good models structure what

you know before making decisions, and

enable scenario analysis.

14

Dependency analysis

• How do high-level operationalconcepts (airlift capability, searchand rescue, etc.) depend uponparticular technical systems(vehicles, radars, IT systems, etc.)?

• There is a gap between theenterprise-level decision making andthe low-level implementation

• If this gap is not bridged, decisionswill not be rational

15

Dependencies in MODAF

• ‘Dependencies of interest to

MOD include: capability

dependencies, programmatic

dependencies, technology

dependencies etc. Analysis of

dependencies of this type is

considered a key use of an

Enterprise Architecture.’

16

Sample MODAF products

17

How should MODAF modelslook?

• The challenge is to give just

enough contents to MODAF

models to enable the relevant

kind of decision making – no

more, no less!

18

LESSON #3

MODAF models are good for visualizing

dependencies, but not so good for

analyzing them. Therefore, they are

difficult to use for scenario analysis.

19

Can MODAF become a morepowerful decision making tool?

• Information on causal relationsenables decision making usingscenarios.

• As part of KTH research, we havedeveloped a method for extendingMODAF models with attributes andattribute relations for dependencyanalysis using Fault Tree Analysisand Bayesian networks

20

Simple FT-BN analysis example

21

From a MODAF model…

Ope

ration

alSystem

s/Services

<<System>>UGV TA

<<Op. Activity>>Kill target

<<System>>

Comms satellite to

TA system

<<Op. Activity>>

Target acquisition

<<Op. Activity>>

C2<<Op. Activity>>

Strike

<<System>>UAV TA

<<System>>

Comms satellite to

striking system

<<System>>

Armed UAV

<<System>>

Artillery

<<needlin

e>>

<<needline>>

<<

need

line>

>

<<needline>>

<<n

eedlin

e>>

<<ne

edline>>

<<

ne

ed

line>

> <<needlin

e>>

<<

ne

edl in

e>

>

22

…to a fault tree…

Ope

ration

alSystem

s/Services

<<System>>UGV TA

<<Op. Activity>>Kill target

<<System>>

Comms satellite to

TA system

<<Op. Activity>>

Target acquisition

<<Op. Activity>>

C2

<<Op. Activity>>

Strike

AND

<<System>>UAV TA

OR

<<System>>

Comms satellite to

striking system

<<System>>

Armed UAV

<<System>>

Artillery

AND OR

23

… to a Bayesian network

Antonov et. al and Dixon et. al

System

s/Services

Operational <<Node>>

UAV operator

platform

<<Node>>

Target

<<System>>

UGV TA

<<Op. Activity>>

Kill target

<<System>>

Comms satellite

<<Op. Activity>>

Target acquisition

<<Op. Activity>>

C2

<<Op. Activity>>

Strike

AND

<<System>>

UAV TA

OR

<<System>>

Armed UAV

<<System>>

Artillery

AND OR

- Quality - Quality - Precision

- Successful kill

- Signal latency

- Autopilot

status

- Video UI

enhancement

status

- System

status

- System

status

- System status

- System

status

- System

status

- Moving

- Moving

System Status

satellite

Signal delay

Moving target Yes No Yes No Yes No Yes No

High 0.3 0.4 0.6 0.7 0 0 0 0

Medium 0.1 0.2 0.2 0.2 0 0 0 0

None 0.6 0.4 0.2 0.1 1 1 1 1

Quality

of C2

Non-failed Failed

Yes No Yes No

System status

of UGV

System status

of UAV

Video UI

enhancement

status

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

High 0.6 0.6 0.4 0.4 0.6 0.4 0 0

Medium 0.3 0.3 0.2 0.2 0.3 0.2 0 0

None 0.1 0.1 0.4 0.4 0.1 0.4 1 1

Quality

of TA

Failed

Non-failed Failed

Non-failed

Non-failed Failed

Inspired by Fincannon et. al [10]

Inspired by Dougherty [7]

Inspired by Antonov et. al [1] and Dixon et al. [6]

System Status of Armed UAV

System Status of Artillery

Moving UAV op. Plattform

Autopilot status

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

Non-

failed Failed

High 0.6 0.6 0.8 0.7 0.6 0.5 0.8 0.6 0.6 0.6 0.6 0.6 0 0 0 0

Medium 0.2 0.2 0.1 0.2 0.2 0.3 0.1 0.2 0.2 0.2 0.2 0.2 0 0 0 0

None 0.2 0.2 0.1 0.1 0.2 0.2 0.1 0.2 0.2 0.2 0.2 0.2 1 1 1 1

Failed

Failed

Yes No Yes No Yes No Yes No

Non-failedNon-failed Failed

Non-failed

Precision

24

Scenarios for decision making

25

LESSON #4

Fault Tree Analysis and Bayesian networks

enable causality based analysis in close

support of decision making needs

26

Summary of the lessons

1. Set the goals before you choose themeans

2. Scenario analysis is a powerful wayto visualize the impact of decisions

3. Traditional MODAF analysis is weakon causality and not very good forscenario driven decision making

4. Fault Tree Analysis and Bayesiannetworks enable causality basedanalysis in close support of decisionmaking needs

27

Thank you!

Questions and feedback?

28

References

• Ulrik Franke, Waldo Rocha Flores, Pontus Johnson:

Enterprise Architecture Dependency Analysis using

Fault Trees and Bayesian Networks, Proc. 42nd

Annual Simulation Symposium (ANSS), pp. 209-

216, March 2009

• Ulrik Franke, Pontus Johnson, Evelina Ericsson,

Waldo Rocha Flores, Kun Zhu: Enterprise

Architecture analysis using Fault Trees and MODAF,

Proc. CAiSE Forum 2009, June 2009, to appear

• Read more on www.ics.kth.se