Update brief presented to SAF February 2006 Lt. Col Mikael Hagenbo, Sw. AF HQ “With a good model comes discovery, with discovery comes understanding, with understanding comes control” Credits to all expert architects at FMV, Svein M Olaussen, Syndicate Leader NRS and MODAF Partners, UK Quote source: http: //www. crowddynamics. com/Egress/legion. html
Information Sharing Statement • The main efforts regarding architecture work in Sweden in this timeframe is done within NATO/EAPC and on a bilateral basis with UK. • The goal is to participate in the development of the NAF version 3/MODAF as an Architecture Description Framework (called Architecture Framework in NATO) for NATO respectively UK. • Sweden has no mandate to share the actual results from this development with any nation outside NATO/EAPC and thus is prevented to share all information available with SAF. • Results on a ”high level” can eventually be shared (as in this presentation) after review and approval from syndicate leader NAF Revision Syndicate and MODAF Partners working with MODAF. • A more technical sharing regarding design rules from Ledsyst. T can be achieved if the current “commercial confidential” classification is adjusted to allow releasability to SAF. Stefan Westman has that responsibility.
Role of Architecture Activity - Usage - System development - Aquisition - Lifecycle management
Why Enterprise Architecture? “The committee believes that the absence of an enterprise architecture has been a major contributor to the problems faced by the implementers of the [FBI's] Trilogy program. That is, the lack of an architecture to guide the planning of an information and communication infrastructure has resulted in improvisation that has virtually no chance of resulting in a well-ordered infrastructure for the enterprise to build upon. In fact, merely providing parts (e. g. , computers and accessories, piece-part applications, and so on) is like buying brick, mortar, and lumber and expecting a builder to produce a functional building without benefit of building codes, blueprints, or an understanding of how people will use the building. ” National Research Council, “A Review of the FBI’s Trilogy Information Technology Modernization Program”, Computer Science and Telecommunications Board, National Academies Press, Washington, D. C. , 2004
Some well known Enterprise Architecture Definitions • ”Enterprise Architecture is a strategic information asset base which defines the business mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs. ” [USA Federal CIO Council] • ”Enterprise Architecture is the holistic expression of an organisation’s key business, information, application and technology strategies, and their impact on business functions and processes. The approach looks at business processes, the structure of the organisation, and what type of technology is used to conduct these business processes. ” [Meta Group, Inc. ] • ”Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements inter-relate. ” [The Open Group]
As a case study reference: Other Concepts of Enterprise Architecture. ”How to survive in the jungle of Enterprise Architecture Frameworks” Jaap Schekkerman Founder and Chairman of The Institute For Enterprise Architecture Developments
The Focus of the Sw. AF EA • The focal point of the Sw. AF EA is the Situation Adapted System concept (Sit. Syst) – This is what the Swedish tax payers pay for. • Sit. Syst shall be possible to assemble quickly to meet new demands of services by combining existing system elements, exposing services in new processes built in the Sit. Syst and by making use of external services available from other systems. • The way services shall be defined and how system elements shall be designed in order to allow for the building of large number of Sit. Systs of potential interest is also a task calling for extensive modelling and simulation activities.
The concept of EA – Sw. AF approach. • Our concept of Enterprise Architecture (EA) is based on a Systems Approach. • To us, an enterprise is a system. • We define system as ”a combination of interacting elements organized to achieve one or more stated purposes. ” [ISO/IEC 15288]. • Every system has an architecture. • We define architecture as ”The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. ” [IEEE 1471]. • An enterprise is a system. Hence, our definition of ”enterprise architecture” is the same as our definition of ”system architecture”.
Architecture Description Perspectives (models (aspects) of the architecture) • System description view (system hierarchy) – What system elements are present at this system level in the internal information exchange model (IER)? • Organisation description view (Actor model) – What system elements are able to act and what roles do they act upon? • Process description view (Procedures) – How do actors in the system act (activities of the system) and the internal information exchange model (IER = Information Exchange Requirements) • Personnel description view – Rules diagram that controls the acting within the system • Information description view – Conceptual model (CM), Information model (IM), Information exchange model (IEM), Data model (DM), Data exchange model (DEM) and Storage model (SM) for each use case instance and additional models for each domain (CD = Cognitive behavioural domain, RD = Representation domain (Information domain), PD = Physical domain (technical models) • Technology description view – Technical component descriptions • Environmental description view – The internal security environment of the system
Think of the Enterprise Architecture as a collection of ‘Lego Blocks’ Architectural Building Block [ABB] - is a specific type of lego block, eg window, wheel, brick. Ÿ ABBs are often grouped together as a type of parts eg windows Enterprise Architectural Framework A catalog of lego parts. A good catalog sorts components so they are easy to find and use. Do you sort your blocks by color, or by shape, or by holes? Which is more productive? What is more efficient? Principle - a recommended way of putting the Lego together Logical Functional Environment - a subassembly of lego which can be implemented in one or more locations Hypothetical Architecture - a box of Lego, with a picture on the front of what's inside, plus building instructions.
Example of a part of Sw. AF EA Sw. AF Systems Management process Strategy process Financial process Production system Mission system Production process Mission process T FP FP FP CP FP FP FP MCP T Service Producer Service Consumer CP = Capability Packet, MCP = Mission Capability Packet T
Future structure of Sw. AF AF Description principles Life cycle principles Design principles Framework fundament E. g: (IEEE 1471, ISO/IEC 15288, Systems’ theory from prof. Derek Hitchins (http: //www. hitchins. net/)
Structure Sw. AF AF Possible different description principles when working with international partners vs. Swedish Authorities (Homeland Defence) Description principles Common principles Life Cycle principles Design principles DR, Design Rules is a container of design patterns and principles (knowledge). Field-of-Application Design Rules Package (DRP) is a packet of Design Rules for a specific problem domain. Generic applicable principles Domain specific applicable principles
Relation between Framework Modules Description Principles Concept Development Production Usage Life cycle principles Design principles Maintenance Retirement
Suggested Notation of The Sw. AF Enterprise System Credits to Per Johannisson, Senior Technical Expert on Enterprise Architecture at FMV
The four defence systems Generic/common = VPX VP = Effect on (from Swedish ”Verkan På”) L = Air, S = Sea, M = Ground, I = Representation (Information)
The Generic and recursive OLV-pattern MCP Behaviour O System L System V System Logistics information Manoeuvre information Full dimensional protection information Combat information Logistics C 2 Manoeuvre C 2 Full dimensional protection C 2 Combat C 2 Logistics Manoeuvre Full dimensional protection Combat Capability O = Observe/Orient L = C 2 V = Effect Mission Unit Interaction
Federations of system I. e. : Area control Defence System LS Control service OS MCP VS Service (MRS) Resource dimension MRS = Mission Related Service MCP = Mission Capability Package SENII = Sweden Networking and Information Infrastructure (software/distributed information) SECOE = Sweden Common Operating Environment (hardware/technology)
Reflection of the dynamics in an Enterprise system “A segment of the surrounding world in that we´re a part of ourselves” (Enterprise) Purpose/Goal The Enterprise Dimension 1 * Flexibility, Adaptability The Service Dimension * 1 * * The System Dimension The Resource Dimension
Loose coupling – ”Carpe Momentum” • Different factors influence and defines the aim of the Enterprise. The sum of these factors is formulated as requirements on capability and is realized in the Enterprise through development and implementation of ability. • The implemented ability can be seen as a forecast and is manifested first through an activity's initiative. • Ability is developed through setting resources into systems, i. e. we organize the activity's resources, describes rules for the resources' use and creates acting patterns for the resources' activities. • Through a service oriented approach we create an additional layer between requirements and resources that increase the flexibility when the service hides activities as well as resources. • In this way, we do not lock up the activities through that on an early stage link resources against an desired capability. The position leads to flexibility, adaptivity and more possible ways to act. • The next slide shows this graphically.
Connections between the purpose of the Enterprise and inward bound resources are presented in four dimension. Political will Example of factors that put demands on the Enterprise The response from the Enterprise upon the demands are expressed as capability ”Situation” Conditions Doctrine Task Influence Capability As a result; • Flexibility By assigning a Service • Adaptively approach we create Oriented • More possiblelayer between an extra actions demands and resources that increases the flexibility when as well as activities and resources are hidden by the service definition. The Enterprise Dimension (E) The Service Capability is achieved by putting resources into system, that is organisation of the inward bound resources of the Enterprise, descriptive rules for the usage of the resources and action patterns for the Dimensionof the resources. activities (SO) The System dimension (S) The Resource dimension (R)
Dimension: Enterprise Purpose Business in focus Goal Service System Resource The Enterprise Dimension describes the Enterprise with the purpose of creating at birds eye view over the Enterprise and achieve a common understanding for the goals and objectives for the Enterprise. In order to understand the Enterprise, relevant parts in the surroundings of the Enterprise has to be described. In this dimension, such tings as conditions (environment), COI-ontology's and terms are found.
Dimension: Service Purpose Business in focus Goal Services in focus Service System Resource The Service Dimension describes what to be achieved in the Enterprise without describing specific activities or resources. In that way capability can be described without the need to lock upon specific action patterns or resources.
Dimension: System Purpose Business in focus Goal Service System in focus Resource The System Dimension describes the Enterprise from a system view. The Sw. AF EA prescribes that a system at least is to be described from the views as follows: Interface, Organisation (of resources), Process (action patterns), Information resources, Technical Resources and Environmental factors
Dimension: Resource Purpose Business in focus Goal Service The Resource dimension deals with/describes the inward bound resources of the Enterprise at a type level. Resources can be personnel, supplies, information or terrain. Please note that this dimension only describes different types of resources. System Resources in focus
GAP-analysis – NOV 1 Capability demands Ability (forecasted)/ Capability (manifested) Resources WHY Aim/Goal, Conditions with new activity Is Ought WHAT What must be done BECAUSE Aim/Goal, Conditions with on-going activity Ought HOW How shall WHAT be done WITH WHAT With what shall WHAT be done Ought Is Is WHAT What can be done HOW How can WHAT be done WITH WATH With what can WHAT be done
The Red String Manifested Capability The Enterprise Dimension (E) WHY Is reflected in the Enterprise Network Based Capability The Service dimension (SO) WHAT HOW The System dimension (S) WITH WATH The Resource dimension (R) Prognostic Capability
The Red String Manifested capabilities Capability Package Build capability to construct Situation Adopted Systems Latent capabilities Build Situation adopted systems
NAF Revision Syndicate Disclaimer: • The information from NATO is based on preliminary work which are not yet finalized. • Changes to what will be presented can be expected, as the NAF v 3 matures and converge in to a stable document Credits to Svein M Olaussen, Syndicate Leader NAF Revision Syndicate
NC 3 B Recommendation • NC 3 B and SC 2 considers that the development of an updated NAF by mid-2006 is an essential pre-requisite for the successful delivery of NNEC. • Completion of the NAF v 3 in this timeframe requires the addition of 18 man-months of expert effort to be applied in the first half of 2006. • Maximum leverage should continue to be obtained by utilising ongoing National architecture framework developments, like DODAF, MODAF and Sw. AF AF.
NAF v 3 development schedule NAF Revision Syndicate Internal releases for Review Feb Workshop London Mar NAF v 3 Draft Ed 1 Feedback from Review Jul NAF v 3 Initial release for External Review in NATO Aug /Sep Oct Nov NAF v 3 ed 1 Final release to NATO
Components of NAF v 3 in a NOV 1 diagram Architecture Data Exchange Views Stakeholders NATO Architecture Meta Model Taxonomy Definitions Configuration Management and Governance Architecture Elements
Basic Assumptions • There is a close relationship between stakeholders (chapter 2), architecture data model (chapter 5), standard products descriptions (chapter 4) and models and architecture elements (chapter 3) • Every data element in a viewpoint description will be reflected in the data model • Architecture views and perspectives are standard slices of an architecture, but users can generate slices to suit their own purposes • All architecture thinking is linked to the – NATO Capability Development Process, – Force Planning Process and – Operational Planning Process • The NAF should be a generic enough to satisfy unanticipated users and requirements
Proposed changes to views • Minor changes needed to develop consistency through the Meta Model • Evaluate UK and US proposed changes to AFs • Extend NSV to show Bandwidth and Spectrum requirement information • Extend All View to cover Metadata and Architecture Compliancy • Extend Technical View to cover Service Interface Point Description • Add Capability Views • Add Service Views • Add Program Views
NAF III – Content (draft) • • • CHAPTER 1 INTRODUCTION TO NATO ARCHITECTURE FRAMEWORK CHAPTER 2 NATO ARCHITECTURE STAKEHOLDERS CHAPTER 3 NATO ARCHITECTURE CONCEPTS AND ELEMENTS CHAPTER 4 NATO ARCHITECTURE VIEWS AND SUBVIEWS CHAPTER 5 NATO ARCHITECTURE META MODEL AND ARCHITECTURE DATA EXCHANGE SPECIFICATION – Appendix 1 Conceptual Model (IDEAS agreed) – Appendix 2 NMM with definitions • CHAPTER 6 NATO ARCHITECTURE LIFECYCLE MANAGEMENT AND GOVERNANCE • CHAPTER 7 NATO ARCHITECTURE DEFINITIONS, TERMINOLOGY, ONTOLOGY • ANNEX A NATO STANDARD ARCHITECTURE METHODOLOGY • ANNEX B TRANSITION GUIDANCE FROM NAF v 2 to NAF v 3 • ANNEX C 1 VIEW PRODUCTS FOR OVERARCHING ARCHITECTURE • ANNEX C 2 VIEW PRODUCTS FOR REFERENCE ARCHITECTURE • ANNEX C 3 VIEW PRODUCTS FOR TARGET ARCHITECTURE
NATO ARCHITECTURE FRAMEWORK v 3 Ch. 1 Ch. 2 Ch. 3 Ch. 4 Ch. 5 5 6 Ch. 7 Annex Vol. Ch. A B C NATO Architecture View Products for OA, RA, TA Transition Guidance from NAF 2 to NAF 3 NATO Architecture Methodology NATO Architecture Terminology, Ontology NATO Architecture Lifecycle & Management NATO Architecture Meta. Model and Exchange NATO Architecture Views & Sub-Views NATO Architecture Concepts & Elements NATO Architecture Stakeholders Introduction & Overview Executive Summary
Resolution of terms • TEMPLATE as a term will no longer be used in the NAF. • Stakeholders drive VIEWS and requirements for VIEWS. (What the stakeholders want and how he wants it represented. ) • Instantiation of a VIEW is a product • A VIEW can be represented/divided in several SUBVIEWS • The VIEWS will have a definition and a layout. The layout could be optional. • Every item and symbol in all VIEWs must be explained. • Architecture element is a fundamental building block that represents a topic relevant for structuring a System
NAF View Determination Types of stakeholders dictates define Developm’t models Needs for arch influences determines influences Views contain Developm’t methodology influences Sub-views comprise instantiation Meta-model structures Repository contains Definition Attributes Product reflects Layout corresponds to Elements
NAF Perspectives and Views Provides summary information for the architecture that enables it to be indexed searched and queried Documents the strategic picture of how military capability is evolving in order to support capability management and equipment planning Documents the operational processes, relationships and context to support operational analyses and requirements development NATO CAPABILITY VIEW NATO ALL VIEW NATO OPERATIONAL VIEW NATO SYSTEM VIEW Documents system functionality and interconnectivity to support system analysis and through life management Documents programme dependencies, timelines and status to inform programme management and procurement synchronization NATO PROGRAM VIEW NATO TECHNICAL VIEW Documents policy, standards, guidance and constraints to specify and assure quality expectations NATO SERVICES VIEW Documents Services functionality, constraints and interoperability
Capability Views • Capability Views – Will reuse elements from MODAF, add necessary NATO specific elements and adapt to NATO processes – Relate to Transformational Objective Areas (TOAs) and Capability development
Example Capability Views NCV-3 a Capability Phasing NCV-5 Capability to System Deployment Mapping
Programme Views Logistic Support Systems Beyond Line of Site ISTAR & Effects Bi-SC AIS START FIN Information AGS Effects DISP START Imagery START Strike AGS Sensors FIN Electronic Warfare ELINT Surveillance AWACS ACCS Special Projects Tomahawk Missile AWACS TMD Artillery INT Equipment 20 XX Training Equipment Personnel Logistics Information Lo. D 'Segment' No outstanding issues Infrastructure Key to View Manageable issues NPV-2 Program to Capability Mapping Doctrine/ Concepts Organisatio n Critical issues 20 XX Comms Project Phase Pre-IG IG to MG MG to Comms Land. IOC Sat Comms Specialist Comms IOC to FOC In Service TACOM P 2000 Disposal SATCOM P 2 K Specialist Comms NGCS NPV-1 Program Portfolio Relationships
Service Views • NATO Definition of a Service: – A distinct part of the function, capability or behaviour that is provided by a producer (part of) system on one side of an interface to a consumer (part of) system on the other side of an interface. • A service should be implementation independent. Services are relevant in all aspects of an architecture. • Services are delivered in accordance with defined patterns and agreements. • Service term should not be used without a relevant context.
NATO SOA Definition • An architecture within which all functions are defined as independent services with well-defined interfaces which can be called separately or in defined sequences to form business processes. • The interface is the focus and is defined in terms of the required parameters and the nature of the result when the service is invoked. • A SOA enables services to be published, discovered and utilized. • Interfaces are defined in a neutral manner that are independent of the hardware platform, the operating system, and the programming language the service is implemented in. Source: NNEC FS Glossary
What is a Service ? provided interfaces environmental effect (if any) functionality required interfaces • A packaged capability or function – i. e. the service may or may not have effect on its environment • Presenting a standard information interface to users and/or other services – Provided interfaces – the interfaces which the service exposes. In other words, the interfaces by which you use the service – Required interfaces – the interfaces by which the service uses other services
Prototype Service Views • NSo. V-1 – Service Taxonomy • NSo. V-2 – Service Specification – NSo. V-2 a – Service Definition (Properties) – NSo. V-2 b – Service Definition (I/F Specification – NSo. V-2 c – Service Definition (Interaction) – NSo. V-2 d – Service Definition (Rules) • NSo. V-3 – Service Composition • NSo. V-4 – Service Orchestration (mapping to Op activities)
Other Views with SOA relevance • NCV-3 b. . • NOV-8. . • NSV-7 b. . • NSV-13 Capability to Services Mapping Operational Activities to Services/Systems Functions Mapping Services Performance Parameters Matrix System service Provision
Introduction Chapter 1 All Terms& Ontology Chapter 7 Architecture Elements Chapter 3 Stakeholders Chapter 2 Meta Model Chapter 5 Experiences NAF v 2 Experiences UK UK Experiences SW US Exp. Others CM Chapter 6 All Views Chapter 4 View chapters Chapter X-X+? Sub Views
EBO, NNEC and Capability development
NNEC Strategic Framework NAF v 3 NNE CF Strategic Concepts Education & Training Defence Planning ibili ty S ty li abi Dec Cap 2004 ie Rev May 2005 Architecture NNEC Strategic Framework tud y MCM NNEC Development Research & Technology eas Foundation Document Concept Development & Experimentation Compliant Inputs from ICTs, ACO, NC 3 O, … Strategic Framework Development Vision & Concept Architecture NNEC Implementation Business Case Roadmap (CAP) (CAIPs) w National Initiatives Dec 2005 to mid 2006
NC 3 TA Version 7 and 8 • NCOW RM will be summarized in Volume 2 • Core Enterprise Services • Impacts Volume 5 • Description in Main Body • Details in Supplement In Vers 7 • TTV • Impacts structure of Volume 4 • Categorization of Standards • Impacts Volume 2 • Model In Vers 8
NC 3 TA Version 7 and 8 • NC 3 TA Vers 7 is a Transition Document • High Level Description of Do. D NCOW RM (V 1. 1) • Enterprise Core Services • Use of NCSP Remarks Column • Major Changes to NC 3 TA Vers 8 • NATO Version of the US NCOW RM
Areas of co-operation “Architecture” • If agreed by US, contribute to the UK/US effort in defining Net Centric Enterprise Services (NCES). • Further development of MODAF. – Modelling Enterprise Services in the MODAF Meta Model reflecting EBO. – Sharing experiences from using MODAF leading to its refinement and further maturity. – Development of a tutorial describing how to use MODAF and an architectural methodology.
Key elements for the EA work ahead ! • • Interoperability (ability to exchange Architecture Data Elements) with NATO and selected nations. Significant contributions to the multi-national effort in developing the future military standard architecture data meta model by actively perform work in NAF Revision Syndicate and on bi-lateral terms with MOD UK (MODAF). Procurement of a Federated Tooling Environment and Architecture Data Repository (leaving powerpoint engineering behind). Setting up an Architecture Management Board Sw. AF AF - as step one develop a Architecture Description Framework based on MODAF/NAF version 3 Sw. AF AF - next steps as stated in the framework structure Sw. AF EA as the Sw. AF Architecture as a whole
Key elements for the EA work ahead ! • • • Sw. AF EA principles' in focus, System concept, Service concept, Lifecycle concept, Information concept, Sit. Syst concept. Technical design rules from Ledsyst. T based on DRP: s and meta design rules from Sw. AF EA, and the NBD system engineering developing method as the main deliverables from Ledsyst. T. Collaborate and contribute to the work done with NC 3 TA in NATO Systems Open Group (NOSWG) – 1. Net Centric Reference Models, – 2. Standards – 3. Net Centric Enterprise Services. Collaborate in developing EU NEA (Network Enabled Ability) Standards Collaborate with selected key partners, Architecture & Methods
NC 3 B and Sub-Structure NATO C 3 Board NC 3 REPS Joint Requirements and Concepts Frequency Management SC/5 SC/3 SC/1 Interoperability Identification Systems Information Security SC/7 Communication Networks Navigation Systems SC/4 SC/2 SC/4 SC/6 SC/8
NC 3 B SUB-STRUCTURE NC 3 O Transformation AHWG Goals & Objectives AHWG SC/1 JRCSC SC/2 ISC SC/3 FMSC SC/4 INFOSECSC NHQC 3 S (2) NC 3 B NATO PKI Management Authority NC 3 REPS SC/5 ISSC SC/6 CNSC PKI Advisory Cell SC/7 IDENTSC SC/8 NAVSC Jnt Civil/Mil session WG/4 Interoperability Policy & Procedures WG/1 Policy WG AHWG/4 Interconnection of Networks Civil/Mil Session WG/5 NATO Interoperability Requirements, Testing & Support WG/2 Military Frequency WG AHWG/6 Application Security WG/1 Data Link SG/1 on Network Management WG/2 Message Text Format WG/3 Technical WG AHWG/10 Common Criteria AHWG/1 BLOS Comms AHWG/4 NATO Mode S/Mode 5 Identification SC/8 -AHWG/6 SC/8 & NAFAG Air Group 5 Approach & Landing Systems Joint WG AHWG/2 V/UHF Radio SC/8 -NAVWAR AHWG/3 Multi-Media Conferencing WG/3 NATO Data Admin Gp (NDAG) AHWG/11 NATO/ non-NATO Cooperation SC/8 -Precision Positioning System (PPS) Certification AHWG WG/1 TACOMS WG/4 NATO Open Systems (NOSWG) WG/2 SATCOM AHWG/13 INFOSEC Architectures Meets with Partners(1) Open to Partners No meetings planned with Partners (1) AHWG/14 Cryptographic Documentation WG/5 Military Message Handling System WG/6 Directory Services Sub-Committees SC/1 = Joint Requirements & Concepts SC/2 = Interoperability SC/3 = Frequency Management SC/4 = INFOSEC SC/5 = Information Systems SC/6 = Communication Networks SC/7 = Identification SC/8 = Navigation AHWG/15 Technical INFOSEC Documentation 1. “Open to Partners” = All meetings open, in principle, to Partners. “Meets with Partners” = Partners are only invited to some meetings. (This does not take into account workshops, expert visits etc. which may also be arranged from time to time by elements of the NC 3 B/NC 3 O). 2. The NHQC 3 S support the NC 3 B and NC 3 REPS and NC 3 B sub-structure but are not part of the NC 3 B sub-structure or NC 3 O (see AC/322 -D/1, Annex, Section VII, E.
Way Ahead?
Possible areas of Information Sharing • Possible architectural issues that occur as a consequence of Sweden as a partner nation in MNE 5, possible acting as a sponsor nation for Singapore as a possible participant nation in MNE 5. • Information modelling and experiences regarding model driven implementation and C 2 application implementation (both in terms of new development and integrating legacy) • Service Oriented Architecture approach regarding the technical implementation, core services definitions, model notifications, languages and UML based documentation. • EA Team implementations, the struggling and the way ahead, best practice etc. .
EBO’s Purpose • Effects-Based Operations (EBO) enables warfighters to plan and execute operations that are: – Clearly linked to strategic objectives – Coherently coordinated with those of other instruments of power – Made truly adaptive through effective assessment
Modelling Enterprise Services • How to model the knowledge base development (The four functions of the Effects-Based operations). • Provide an Enterprise Services Taxonomy for military operations conducted within EBO as a framework.
Framework for the Enterprise - Information View Conceptual Model (CM) Information Model (IM) Information Exchange Model (IEM) Data Exchange Model (DEM) Data Model (DM) Storage Model (SM) Platform Specific Model (PSM) Source: Per Johannisson, Technical Expert Enterprise Architecture at FMV
Architecture - A tool for reducing complexity • “The central tenet of effects-based operations is that we can somehow purposefully shape the interactions of players in our security environment so as to produce both individual and overall behaviour that meets our needs. • To do this, effects-based operations must be able to deal with complexity. • The definition of effects-based operations as “co-ordinated sets of actions directed at shaping the behaviour of friend, foe and neutral in peace, crisis, and war” underlines this complexity”. Source: Complexity, Networking, and Effects-Based Operations: Approaching the "how to" of EBO Author: Dr. Edward A. Smith, Jr. Executive Strategist, Effects-Based Operations - The Boeing Company
Multinational Experimentation Task: Provide to the warfighter MN Effects Based Operations to include: Effects Based Planning, Execution, and Assessment, and Knowledge Base Development. • Sponsors: • Australia • Canada • Finland • France • Germany • Sweden • NATO • UK Team: Expanded Support to Operational Commander: Processes, organization and tools to conduct multinational effects based operations that enable a holistic understanding of the operating environment and effective integration of all elements of coalition and national powers in achievement of the commander’s desired endstates. Goals: 3, 4, 6, 7 Dimensions: Org, Pro, Cap Partners: • NC 3 A • DTRA • US Services • NSA • ARL/ARI • Supports Turnkey C 2 Architecture support Events / Products 4 Q FY 05 3 Q FY 05 • EBP IPs (US) • EBE/EBA CONOPS • • and strawman IPs (US & ACT) KM CONOPS / CONEMP (CA) Intel CONOPS (US) MNIS capability (US) MNE 4 strategic guidance (FR) • KBD CONOPS/IPs (GE) • • • ONA supporting tools (GE & US) EB Plan Template (NATO) KM SOPs and IPs (CA & US) MNE 4 KM Plan (CA) IO White Paper (GE) MNE 4 IO plan (GE) EBO integrated tools (US) MNIG CONOPS (AS) Coalition Pol-Mil planning guidance (FR) • IO in EBO CONOPS (GE) • Logistic CONOPS (US) 1 Q FY 06 • Training and documentation materials for MNE 4 • 2 Star Peers Meeting (MNE 5) at end of CD&E conference in Berlin 2 Q FY 06 • MNE 4 Capstone Event • MNE 4 Analysis 3 Q FY 06 4 Q FY 06 • MNE 4 • MNE 5 SLS Pre-CDC • MNE 4 Final Report • MNE 5 POA&M • 2 Star Peers VTC to discuss MNE 4/MNE 5 Efforts 1 Q FY 07 • MNE 5 CDC
Скачать презентацию Update brief presented to SAF February 2006 Lt
f372651e5572b3bee382387986c29ddd.ppt