This document provides an introduction to MODAF (Ministry of Defence Architecture Framework) version 1.2. It discusses the purpose of enterprise architecture and MODAF's views which provide standardized representations of the business, systems, services, and programs. The views include the Strategic view defining capabilities, the Services view specifying services and interfaces, the Logical view showing system context, and the Physical view defining system configurations. MODAF version 1.2 added aspects for service-oriented architectures.

1. Brief Introduction to MODAFBrief Introduction to MODAF
with v1.2 Updates
Ian Bailey
ian@modelfutures.com
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

2. 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

3. 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
© Model Futures Ltd. 2008

4. 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
© Model Futures Ltd. 2008

5. 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:
Programme
Management
Business
Process Management
View
Process
View
Solution
View
Strategy
View
© Model Futures Ltd. 2008
Enterprise Architecture

6. 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 purpose
Th 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.
© Model Futures Ltd. 2008

7. 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
© Model Futures Ltd. 2008

8. 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
Beverages
05‐10
Beverages
10‐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
© Model Futures Ltd. 2008
(100cups/day)
(200 cups/day) maker of tea in the
British Isles
best maker of tea
in the British Isles

9. 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 capabilities
which 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)
© Model Futures Ltd. 2008
p y
Tea Making
(100cups/day)
p y
Tea Making
(200 cups/day)
Water BoilingWater Supply

10. 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
© Model Futures Ltd. 2008

11. 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>>
Hot Liquid Safety
Assessment
<<Service>>
Hot Liquid
Input
Temperature
Volume
Distance
Interface (SOV‐2)
© Model Futures Ltd. 2008
q
Safety
Assessment Output Risk Measure

12. 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
Operational
Nodes (OV‐2)
Operational Activities(OV‐5)
<<Node>>
Order
Processing
<<Node>>
Order
Fulfilment
<<OperationalActivity>>
Receive Order
<<O ti lA ti it >>
Handling
service
<<Node>>
tea
request
tea <<ProblemDomain>>
<<OperationalActivity>>
Boil Water
<<OperationalActivity>> <<Service>>
service
orchestration
© Model Futures Ltd. 2008
Customer Brew Tea
<<Service>>
Hot Liquid Safety
Assessment

13. 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 )
© Model Futures Ltd. 2008
configurations)

14. 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.
© Model Futures Ltd. 2008

15. 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>>
Kitchen
S t
<<Platform>>
Kitchen
S t
<<Platform>>
Kitchen
<<System>>
trade off
<<System>>
Kettle
boiling
water
<<System>>
Kettle
boiling
water
<<System>>
Acme Tea Machine
<<System>>
Water Heater
tea
operative
<<System>>
Tea Pot
tea
tea
operative
<<System>>
Cup
<<System>>
Tea Brewer
© Model Futures Ltd. 2008
<<System>>
Cup
cup of tea

16. Programmatic (AcV, SV & StV)
• AcV‐2, SV‐8 and StV‐3 are time‐oriented views
– AcV‐2 shows programme milestones, and dependencies p g , p
between 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‐Making
100 Cups/Day
200 Cups/Day
1000 Cups/Day
Capability
Gap
© Model Futures Ltd. 2008
1000 Cups/Day

17. 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.
© Model Futures Ltd. 2008

18. 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
© Model Futures Ltd. 2008