Introduction to MODAF v1.2

Brief Introduction to MODAFBrief Introduction to MODAFwith v1.2 Updates

Ian [email protected]

www.modelfutures.com/training

This set of slides has been pulled together from various modules of the Model Futures MODAF Training Course.

Permission is granted for the IET to distribute these slides to attendees of their Architecture Framework Seminar

© Model Futures Ltd. 2008© Model Futures Ltd. 2008

Why MODAF ?• Any enterprise of the size of MOD is usually very complex

– No one person can have a detailed picture of how all the partsNo one person can have a detailed picture of how all the parts of the business are structured and how they function

– Decision making can therefore be difficult

• To be able to support complex decisions that may affect the whole enterprise, the decision maker needs:– correct information at their fingertips

– …that can distil the key points from the underlying complexity

– …presented the way they want to see it

• Such a model of business will be multi‐disciplinary– Need standards for presentation and storage

– Need clear separation of concerns

© Model Futures Ltd. 2008

Who’s Using MODAF in 2008 ?• UK Ministry of Defence & its suppliers

– Thales BAE Systems Lockheed Martin Serco BoeingThales, BAE Systems, Lockheed Martin, Serco, Boeing, General Dynamics, etc. etc.

• Intelligence Servicesg– GCHQ and others

• National Air Traffic Control (NATS)( )• Swedish Armed Forces• UK e‐borders projectUK e borders project• Adapted by NATO to become NAF Rev 3

– MODAF has since moved on with the release of v1 2– MODAF has since moved on with the release of v1.2– V1.2 uses the same SOA meta‐model elements as NAF


Background• Version 1.0 of MODAF released in 2005

– Effectively DoDAF with extensions to cover MOD’s approach to smart acquisition

– Decided not to use the DoD’s CADM model – instead MODAF is based on OMG standards

• Version 1.1 released in 2007– Significant move from DoDAF at this point

Cl di ti ti b t t t i l i l d h i l– Clear distinction between strategic, logical and physical architectures

– Very well received by architects and systems engineers– Used as the basis for NATO AF rev3 and adopted by several

other govt departments in UK and elsewhere• Version 1.2 released in 2008Version 1.2 released in 2008

– Adds Service‐Oriented Architectures– Fixes some minor issues with v1.1


What is MODAF ?• MODAF specifies a set of “views” of an enterprise

– Views are aimed at different stakeholders; business modellers, h ksystems engineers, programme managers, strategic thinkers,

procurement specialists, etc.• The views present slices of the enterprise architecture for p p

a specific purpose– There is one coherent model of business & technology, but with

standardised views of that model for different purposes:standardised views of that model for different purposes:

ProgrammeManagement

BusinessProcess Management

ViewProcessView

SolutionView

StrategyView


Enterprise Architecture

How the Views Stack up• Strategic and Service views specify standard capabilities and

services that are used across many architectures and projects• The logical views take those capabilities and services and put

them in context of each other for a particular purposeTh h i l i d fi h h l i l ifi i• The physical views define how the logical specifications are realised

New in v1.2

Re‐useable specifications& strategic governance& strategic governance

Scenarios, requirements, etc.

Solutions.


The MODAF Views• The architectural views are categorised into viewpoints:

– Strategic (StV) – defining the boundaries of the enterprise and l d b lits vision, goals and capabilities

– Services (SOV) – specifying services, the interfaces they present and how they may interact (but not how they are implemented)

– Logical (OV) – specifying how the enterprise is required to be logically structured and how it functions

– Physical (SV) – specifying how organisational and systemPhysical (SV) specifying how organisational and system resources interact in order to deliver capabilities and services(OV).

– Programmatic (AcV) – supporting information about whenProgrammatic (AcV) supporting information about when solutions are to be delivered and by whom

– Standards (TV) – listing the standards which apply to the architecturearchitecture

– All Views (AV) – meta‐data and standard terminology


The Strategic Views (StV)• Enterprises may be comprised of other enterprises• Enterprises may be divided into phasesEnterprises may be divided into phases• Enterprises/Enterprise phases have visions, goals and

capabilities: as‐is to‐bep

<<WholeLifeEnterprise>>

ACME Catering

as is to be

Beverage Division

Beverages05‐10

Beverages10‐15

TIME 2000 2005 2010 2015

<<Capability>>

Tea Making/

<<Capability>>

Tea Making(200 cups/day)

<<Vision>>

To be the foremost maker of tea in the

<<Vision>>

To be the fourth‐best maker of tea


(100cups/day) (200 cups/day) maker of tea in the British Isles

best maker of tea in the British Isles

StV – Taxonomy & Dependencies• Capabilities are specifications of an ability to do

something, without saying how it is to be done• Important to know how capabilities relate:

– which are special cases of other capabilitieswhich contribute to other capabilities– which contribute to other capabilities

– Which depend on other capabilities

S i li ti (StV 2)Composition (StV‐2&4)

<<Capability>>

Beverage Making

<<Capability>>

Tea Making

<<Capability>>

Water Boiling<<Capability>>

Tea Brewing

Specialisation (StV‐2)

<<Capability>>

Tea Making<<Capability>>

Coffee Making

<<Capability>>

Tea Delivery<<Capability>>

Sweetening

<<Capability>> <<Capability>>

g g

<<Capability>><<Capability>>

Dependency (StV‐4)


p y

Tea Making(100cups/day)

p y

Tea Making(200 cups/day)

Water BoilingWater Supply

v.1.2 ‐ SOA• The biggest change is the addition of the SOA aspects• New set of views for specifying the Services:p y g

– SOV‐1 – specifies types of services, their attributes and constraints– SOV‐2 – specifies the interfaces services either provide or consume

SOV 3 i t th biliti th t ib t t– SOV‐3 – maps services to the capabilities they contribute to– SOV‐4 – service specification – constraints, state transitions,

interaction specifications– SOV‐5 – service functionality (activity model)

• Modifications / Additions to existing views:OV 5 can now be used in an SOA context as the orchestration model– OV‐5 can now be used in an SOA context, as the orchestration model for services.

– Services provision/consumption may also be shown on OV‐2– SV‐12 added – shows how resources are configured to deliver a given

service


Service‐Oriented View (SOV)• Services are similar to capabilities

– Finer grain than capabilities and with well‐defined interfacesFiner grain than capabilities, and with well defined interfaces

– Services are defined independently of their implementation

– Services contribute to capability deliveryServices contribute to capability delivery

<<Capability>>

Capability Delivery (SOV‐3)

Tea Delivery

<<Service>> <<Service>>Taxonomy (SOV‐1)

<<Service>>

Customer Order Handling

<<Service>>

Hot Liquid Safety Assessment

<<Service>>

Safety Assessment

<<Service>>

Nuclear Safety Assessment

<<Service>>

Chemical Safety Assessment

<<Service>>


<<Service>>

Hot Liquid Input

TemperatureVolumeDistance

Interface (SOV‐2)


qSafety

Assessment Output Risk Measure

Logical (OV)• Called “Operational Views” for legacy reasons (DoDAF)• Specify what is to be done and the logical structure of the

( ) ( )enterprise – putting capabilities (StV) and services (SOV) in context

• May be several suites of OVs covering different scenarios /May be several suites of OVs covering different scenarios / options

<<Capability>>

Tea Making(200 cups/day) <<Service>>

Customer Order

OperationalNodes (OV‐2)

Operational Activities(OV‐5)

<<Node>>

Order Processing

<<Node>>

Order Fulfilment

<<OperationalActivity>>

Receive Order

<<O ti lA ti it >>

Handling

service

<<Node>>

tearequest

tea <<ProblemDomain>>

<<OperationalActivity>>

Boil Water

<<OperationalActivity>> <<Service>>

serviceorchestration


Customer Brew Tea<<Service>>


v1.2 ‐ Resources• There is a problem of context in architectures

One person’s “platform” is another person’s “system”– One person s platform is another person s system

– One person’s “system” is another person’s “materiel”

T bl ibl f hit t l l t• To enable sensible re‐use of architectural elements across the various MOD EA efforts, it was decided to h th d l i th SV Th lchange the resource model in the SVs. The only allowable resource types are: – RoleType, PostType , OrganisationType (organisational)

– Artefact (non‐human object)

– Software (executable code)

– Physical Architecture & Capability Configuration (re‐usable fi i )


configurations)

v1.2 – Resources (cont.)• The basic resource types may then be used in different ways:different ways:– Platform, System, Part (artefact)

UsedConfiguration (a PhysicalArchitecture being used by– UsedConfiguration (a PhysicalArchitecture being used by another)

– Role Post (in organisation) HumanResource (in Physical– Role, Post (in organisation), HumanResource (in Physical Architecture), sub‐organisation

– HostedSoftware (software running on an artefact)HostedSoftware (software running on an artefact)

• This allows the same type of resource to be used in a• This allows the same type of resource to be used in a number of different contexts.


Physical (SV)• The systems views (SVs) specify how human resources, systems and platforms are broughtresources, systems and platforms are brought together to realise the logical specification of the OVs

• Often there will be more than one possible solution,Often there will be more than one possible solution, and suites of SVs can be compared in a trade‐study

trade‐off

<<Platform>>

KitchenS t

<<Platform>>

KitchenS t

<<Platform>>

Kitchen<<System>>

trade off

<<System>>

Kettleboilingwater

<<System>>

Kettleboilingwater

<<System>>

Acme Tea Machine

<<System>>

Water Heater

teaoperative

<<System>>

Tea Pot

teateaoperative

<<System>>

Cup<<System>>

Tea Brewer


<<System>>

Cupcup of tea

Programmatic (AcV, SV & StV)• AcV‐2, SV‐8 and StV‐3 are time‐oriented views

– AcV‐2 shows programme milestones, and dependencies p g , pbetween programmes (extended Gantt chart).

– StV‐2 shows the capabilities levels of the enterprise over time –used for gap/shortfall analysisused for gap/shortfall analysis

Project “TeaPot”

Project “TeaBag”

Project “X”

Project “Water Supply”

j

T M kiTea‐Making100 Cups/Day

200 Cups/Day

1000 Cups/Day

CapabilityGap


1000 Cups/Day

MOD Ontology• The “All Views” viewpoint (AV) summarises terminology

that has been used in the architecture• Each new term must extend an existing concept in the

MOD ontology– Specialisation (e.g. Bowman specialises Radio)– Synonym (e.g. US DoD = United States Dept. of Defense)

I t ( B ildi A i i t f G t B ildi )– Instance (e.g. Building A is instance of Govt Building)

• This helps maintain consistency across architectures Makes them easier to integrate– Makes them easier to integrate

– New terminology introduced at the AV level can be “promoted” up to the MOD Ontology

– Provides a “terrain map” of the architectures that are being used across MOD.


In Summary• MODAF is in three parts:

– The views – standard ways to present architectures– The meta‐model – standard way to store and exchange architectural

data– The ontology – standard terms and conceptsThe ontology standard terms and concepts

• MODAF Architectures are contiguous– The architects produce joined‐up models of the business and

h ltechnology– This can then be queried by decision makers– Can be presented according to the viewsp g

• MODAF is light on methodology, but a minimum is required:– It forces the architect to keep the OV models logical so as not to

“ l ti ” t th i t t“solutioneer” at the requirements stage– Strategic architecture is intended to span multiple projects and

timelines


Technology

Introduction to MODAF v1.2