Upload
iandbailey
View
1.187
Download
3
Tags:
Embed Size (px)
DESCRIPTION
An overview of the MOD Architecture Framework (MODAF) presented at the IET in London in Sept 2008.
Citation preview
Brief Introduction to MODAFBrief Introduction to MODAFwith v1.2 Updates
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
© Model Futures Ltd. 2008
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
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
© Model Futures Ltd. 2008
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.
© Model Futures Ltd. 2008
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
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
© Model Futures Ltd. 2008
(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)
© Model Futures Ltd. 2008
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
© Model Futures Ltd. 2008
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
TemperatureVolumeDistance
Interface (SOV‐2)
© Model Futures Ltd. 2008
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
© Model Futures Ltd. 2008
Customer Brew Tea<<Service>>
Hot Liquid Safety Assessment
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)
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
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
© Model Futures Ltd. 2008
<<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
© Model Futures Ltd. 2008
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.
© Model Futures Ltd. 2008
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