Modular Open Systems Approach Review Team MOSART LTC P Ken Flowers Director, Open Systems Joint Task Force 27 Febr

1. 1 Modular Open Systems Approach Review Team (MOSART) LTC (P) Ken Flowers Director, Open Systems Joint Task Force 27 February 2004 Overview Mission Statement and recent charter guidance Highlevel milestone (from Garber�s chart) Products & Services Personnel (boxes for vacancies and needs, with names) Funding Composition (organize according to major activities)Overview Mission Statement and recent charter guidance Highlevel milestone (from Garber�s chart) Products & Services Personnel (boxes for vacancies and needs, with names) Funding Composition (organize according to major activities)

2. A Real-World MOSA Success Story

3. 3 Today�s Agenda

4. 4 Admin OSJTF contact number: 703-602-0851 x159 Restrooms: Rear Hallway Meeting notes will be emailed per attendee list

5. 5 Opening Remarks Dr. Garber Director, Systems & Mission Integration (OUSD AT&L DS/SMI) Overview Mission Statement and recent charter guidance Highlevel milestone (from Garber�s chart) Products & Services Personnel (boxes for vacancies and needs, with names) Funding Composition (organize according to major activities)Overview Mission Statement and recent charter guidance Highlevel milestone (from Garber�s chart) Products & Services Personnel (boxes for vacancies and needs, with names) Funding Composition (organize according to major activities)

7. 7 Modular Open Systems Approach (MOSA) and Joint Integrated Warfare Mr. Wynne�s Vision for MOSA Apply MOSA to the internals and externals of major systems, and Enforce its implementation across all programs/system levels This includes Application to the integration of joint warfare, and therefore to Joint System Architectures The application to the system of systems level should leverage gains made for the application to the program or system level so that all our system architectures are open and affordable. So the MOSART was formed to identify issues and developing department-wide consensus regarding the implementation of MOSA that transcend its application within an individual program. The JWISC will look to the MOSART to elevate unresolved issues pertaining to the application of MOSA to achieve joint integration objectives, and provide recommendations for consideration and potential adjudication. Mr. Wynne�s Vision for MOSA Apply MOSA to the internals and externals of major systems, and Enforce its implementation across all programs/system levels This includes Application to the integration of joint warfare, and therefore to Joint System Architectures The application to the system of systems level should leverage gains made for the application to the program or system level so that all our system architectures are open and affordable. So the MOSART was formed to identify issues and developing department-wide consensus regarding the implementation of MOSA that transcend its application within an individual program. The JWISC will look to the MOSART to elevate unresolved issues pertaining to the application of MOSA to achieve joint integration objectives, and provide recommendations for consideration and potential adjudication.

8. 8 MOSA Policy & Enforcement Enforcement across all programs, ACAT levels and phases Primarily focused on programs in the acquisition process Enforcement across all programs, ACAT levels and phases Primarily focused on programs in the acquisition process

9. 9 MOSA Implementation Memo

10. 10 GOALS

11. 11 Proposed MOSARTRole & Structure Proposed Mission Statement Provide the way ahead for applying MOSA to joint warfare integration. Elevate unresolved issues pertaining to the application of MOSA to achieve joint integration objectives. Offer recommendations for consideration and potential adjudication. Synchronize the Services� mgmt approach to MOSA implementation. Align MOSA implementations across and within the Joint community. Members Service architecture and integration reps Agency / Program integrators JFCOM, JS, & OSD OSJTF (chair / facilitator) Related Activities JIWSC MOSA Workshops Industry

12. 12 Modular Open Systems Approach an Overview MOSA is a business and technical strategy that: Identifies system modules using a reference model or architecture Identifies internal interfaces (between system modules) and external interfaces (to other systems that must be interoperable) Identifies key interfaces based on both operational and acquisition considerations that are germane to the system Designates open interface standards (with sufficient application and implementation guidance) that will guide and influence the system's design Uses an IPPT to achieve and document these objectives As the graphic shows, the focus is on an integrated business and technical approach or process that should lead to a modular, open system. The business and technical requirements and considerations dictate how MOSA will be leveraged and therefore how it manifests itself in a particular application. Further, MOSA is best done as a part of a sound IPPD and SE processes This provide a bounded context for making the tradeoffs that are part of any good SE process. MOSA indicators are in the form of questions The ultimate goal of MOSA is an �open system� But we can�t wait until a system is produced or fielded to judge whether its an �open system. So we need indicators to predict if an acquisition is likely to produce a modular, open system. At a macro level, MOSA can be assessed by the following questions: Does the program: Employ a modular design for the system? Designate the system�s key interfaces? Use open standards for the key interfaces? See the PM Guide for the specific definition and meaning of each concept. Related Benefits 1. Employ design modularity Promotes ease of change Isolates functionality Facilitates evolutionary acquisition 2. Identify key interfaces within the system and between systems Facilitates technology insertion Provides foundation for joint integrated architectures 3. Use open standards for interfaces where appropriate Facilitates ease of upgrade Increases competition and flexibilityMOSA is a business and technical strategy that: Identifies system modules using a reference model or architecture Identifies internal interfaces (between system modules) and external interfaces (to other systems that must be interoperable) Identifies key interfaces based on both operational and acquisition considerations that are germane to the system Designates open interface standards (with sufficient application and implementation guidance) that will guide and influence the system's design Uses an IPPT to achieve and document these objectives As the graphic shows, the focus is on an integrated business and technical approach or process that should lead to a modular, open system. The business and technical requirements and considerations dictate how MOSA will be leveraged and therefore how it manifests itself in a particular application. Further, MOSA is best done as a part of a sound IPPD and SE processes This provide a bounded context for making the tradeoffs that are part of any good SE process. MOSA indicators are in the form of questions The ultimate goal of MOSA is an �open system� But we can�t wait until a system is produced or fielded to judge whether its an �open system. So we need indicators to predict if an acquisition is likely to produce a modular, open system. At a macro level, MOSA can be assessed by the following questions: Does the program: Employ a modular design for the system? Designate the system�s key interfaces? Use open standards for the key interfaces? See the PM Guide for the specific definition and meaning of each concept. Related Benefits 1. Employ design modularity Promotes ease of change Isolates functionality Facilitates evolutionary acquisition 2. Identify key interfaces within the system and between systems Facilitates technology insertion Provides foundation for joint integrated architectures 3. Use open standards for interfaces where appropriate Facilitates ease of upgrade Increases competition and flexibility

13. 13 Terms of Reference MOSA � An integrated business and technical strategy that employs a modular design and, where appropriate, defines key interfaces using widely supported, consensus-based standards that are published and maintained by a recognized industry standards organization. Key Interfaces � An interface for which the preferred implementation uses an open standard to design the system for affordable change, ease of integration, interoperability, commonality, reuse and other essential considerations such as criticality of function. Open Standards � Standards that are widely used, consensus-based, published and maintained by recognized industry standards organizations. Integrated Architectures � An architecture consisting of multiple views or perspectives (operational view, systems view and technical view) that facilitates integration and promotes interoperability across family of systems and systems of systems and compatibility among related architectures. [CJCS 3170.01c]

14. 14 Terms of Reference � Cont. Interoperability � The ability of systems, units, or forces to provide data, information, materiel, and services to and accept the same from other systems, units, or forces, and to use the data, information, materiel, and services so exchanged to enable them to operate effectively together. (DoDD 5000.1) Integration - The process of aligning missions, resources, functions, processes, architectures, and performance to create a cohesive warfighting system and a highly capable force. Joint Integrated Warfare � The collaborative efforts to unify missions, connect architectures, and standardize key interfaces within warfighting systems. Open Systems � A system that employs modular architecture and uses widely-supported and consensus based standards for its key interfaces.

15. 15

16. 16 Modular Design Benefits

17. 17

18. 18 With this understanding of a very generic kind on �interoperability� and the various system levels where it could have meaning, we would like to review and contrast considerations for achieving interoperability At the system-of-systems level and Internal to major systems and platforms (generally refer to as integrated systems). This is our response to one of your questions: at what level do we specify interoperability standards and where should we permit design innovations, or more specifically, where do we establish specification boundaries? A system-of-systems is �a set or arrangement of systems that are related or connected to provide a given capability. The loss of any part of the system will degrade the performance or capabilities of the whole.� (CJCSI 3170.01B). �System-of-systems interoperability� is hard to achieve because the overall system and corresponding mission capability Are hard to visualize and bound, Are often literally �assembled on-the-fly� by operational commanders in response to emerging threats, or requirements, Have a relatively short lifecycle when compared to traditional systems that remain �intact� for extended periods of time, and Are usually not managed or funded under a singular or consolidated authority. Conversely, the application of a modular open system design approach is less risky because major system acquisitions Are managed by competent program managers and regulated by a robust acquisition process, and Are well understood by your major system integrators who have successfully applied them. The lack of distinction between these two different kinds of �interoperability� is a major contributor to the contention that currently exists in the JTA process. To address all these considerations, we recommend that The JTA be focused on �system-of-systems interoperability� because it is: At the core of the Department�s interoperability challenges, Not as well understood or defined as integrated systems, and Beyond the contractual scope of major system integrators. Design considerations inside the system�s boundaries (denoted by the modules inside the graphic on the right) be left to program managers and their contractors. This includes determining the standards that facilitate technology insertion and minimizes obsolescence. This approach will lead to more affordable systems because: It will discourage over-specification of a system�s design and therefore not discourage innovation, and It will focus DoD�s interoperability efforts on identifying the minimal set of standards for key interfaces between systems that are required for mission capability packages. In cases where having the same design in multiple platforms is a prudent acquisition strategy, we believe that the CAEs and PEOs are in the best position to determine the level and type of standardization needed.With this understanding of a very generic kind on �interoperability� and the various system levels where it could have meaning, we would like to review and contrast considerations for achieving interoperability At the system-of-systems level and Internal to major systems and platforms (generally refer to as integrated systems). This is our response to one of your questions: at what level do we specify interoperability standards and where should we permit design innovations, or more specifically, where do we establish specification boundaries? A system-of-systems is �a set or arrangement of systems that are related or connected to provide a given capability. The loss of any part of the system will degrade the performance or capabilities of the whole.� (CJCSI 3170.01B). �System-of-systems interoperability� is hard to achieve because the overall system and corresponding mission capability Are hard to visualize and bound, Are often literally �assembled on-the-fly� by operational commanders in response to emerging threats, or requirements, Have a relatively short lifecycle when compared to traditional systems that remain �intact� for extended periods of time, and Are usually not managed or funded under a singular or consolidated authority. Conversely, the application of a modular open system design approach is less risky because major system acquisitions Are managed by competent program managers and regulated by a robust acquisition process, and Are well understood by your major system integrators who have successfully applied them. The lack of distinction between these two different kinds of �interoperability� is a major contributor to the contention that currently exists in the JTA process. To address all these considerations, we recommend that The JTA be focused on �system-of-systems interoperability� because it is: At the core of the Department�s interoperability challenges, Not as well understood or defined as integrated systems, and Beyond the contractual scope of major system integrators. Design considerations inside the system�s boundaries (denoted by the modules inside the graphic on the right) be left to program managers and their contractors. This includes determining the standards that facilitate technology insertion and minimizes obsolescence. This approach will lead to more affordable systems because: It will discourage over-specification of a system�s design and therefore not discourage innovation, and It will focus DoD�s interoperability efforts on identifying the minimal set of standards for key interfaces between systems that are required for mission capability packages. In cases where having the same design in multiple platforms is a prudent acquisition strategy, we believe that the CAEs and PEOs are in the best position to determine the level and type of standardization needed.

19. 19 Navy Open Architecture NOA brf.ppt

20. 20 Single Integrated Air Picture (SIAP)

21. 21 The Way Ahead�..

22. 22 Navy Open Architecture (NOA) �affordable evolutionary combat capability� SIAP is Joint Track Management application based on MOSA NOA is leveraging the use of SIAP across a number of ship and aircraft types/classes �system-of-systems interoperability� FORCEnet is the Navy�s gateway to joint network-centric operations NOA is an enabler for FORCEnet

23. 23 MOSA May be Applied at Different System Levels Different does not mean multiple Each application must have its own context that determines the benefits and motivations and scope (boundaries) for that application. It is very likely that different applications have different �driver� and therefore have different manifestations of MOSA, including selected architectures, key interfaces and standards. However, at the system-of-systems level major platforms will be �components� of the overall system. So, the external interfaces of these systems may in fact be key interfaces of the overall system-of-systems.Different does not mean multiple Each application must have its own context that determines the benefits and motivations and scope (boundaries) for that application. It is very likely that different applications have different �driver� and therefore have different manifestations of MOSA, including selected architectures, key interfaces and standards. However, at the system-of-systems level major platforms will be �components� of the overall system. So, the external interfaces of these systems may in fact be key interfaces of the overall system-of-systems.

24. 24 Example: MOSA Applied at Major Subsystem Level

25. 25 MOSA Enforcement Process This chart shows the major steps in enforcing MOSA within the acquisition process. The block entitled �Institutionalize MOSA� contains several mechanisms that are need to ensure a consistent application of MOSA. applies at both levels and is really putting the infrastructure in place. At the systems level we will work with program managers and program IPTs as well as appropriate oversight personnel to assure that open systems are implemented. The block entitled �Ensure MOSA� is a very simplex depiction of a complex set of processes. We have more detailed charts to help guide our steps. A similar process will be followed at the system of systems (Implement System of Systems) level but the processes here will involve new issues and a collaborative of people similar yet different from the system level. The chart is color coded by the lead organization as shown in the upper left hand corner. Fundamentally we have two areas where we will work from a systems level and two where we will work from a systems of systems level. What you do not see here though is the fact that for all three of these blocks or areas, we have a written goal. And we have developed specific objective for each of the goals to help us assure that we get where we need to go to ensure open systems are used through the Department. Meeting the objectives will assure that we do properly influence the system. Now that we have a plan and are well on our way to transforming the OSJTF, we unfortunately need to see what sort of program plan we will need to accomplish all these things. The first of two options is on the next chart.This chart shows the major steps in enforcing MOSA within the acquisition process. The block entitled �Institutionalize MOSA� contains several mechanisms that are need to ensure a consistent application of MOSA. applies at both levels and is really putting the infrastructure in place. At the systems level we will work with program managers and program IPTs as well as appropriate oversight personnel to assure that open systems are implemented. The block entitled �Ensure MOSA� is a very simplex depiction of a complex set of processes. We have more detailed charts to help guide our steps. A similar process will be followed at the system of systems (Implement System of Systems) level but the processes here will involve new issues and a collaborative of people similar yet different from the system level. The chart is color coded by the lead organization as shown in the upper left hand corner. Fundamentally we have two areas where we will work from a systems level and two where we will work from a systems of systems level. What you do not see here though is the fact that for all three of these blocks or areas, we have a written goal. And we have developed specific objective for each of the goals to help us assure that we get where we need to go to ensure open systems are used through the Department. Meeting the objectives will assure that we do properly influence the system. Now that we have a plan and are well on our way to transforming the OSJTF, we unfortunately need to see what sort of program plan we will need to accomplish all these things. The first of two options is on the next chart.