Service Vs. System. Why do we need Services and a Services Viewpoint in DM2 and DoDAF? Fatma Dandashi, PhD March 4, 2011

Transcription

1 Service Vs. System Why do we need Services and a Services Viewpoint in DM2 and DoDAF? Fatma Dandashi, PhD March 4, 2011

2 1. Does DoD Need To Model a Service?

3 Bottom Line Up front (BLUF) DoD has a requirement to develop solutions that are Net-Centric Derived Requirement: Define the concept of a <logical solution domain> service, along with a Services Viewpoint in DoDAF 3

4 DoD Requirements For Services View DoDDs: Interoperability and Supportability of IT and National Security Systems (NSS) 4/23/ Management of the Department of Defense Information Enterprise 2/10/ Use of Commercial Wireless Devices, Services, and Technologies in the DoD Global Information Grid (GIG) 4/23/ Information Technology Portfolio Management 10/10/ Data Sharing in a Net-Centric Department of Defense 4/23/2007 DoDIs: Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS) 6/30/ Information Technology Portfolio Management Implementation 10/30/2006 4

5 DoD s Net-Centric Services Strategy Strategy for a Net-Centric, Service Oriented DoD Enterprise, May 4, 2007: The DoD s vision is to establish a Net-Centric Environment (NCE) that increasingly leverages shared services and Service Oriented Architecture (SOA) that are: Supported by the required use of a single set of common standards, rules, and shared secure infrastructure provided by the Enterprise Information Environment Mission Area (EIEMA); Populated with appropriately secure mission and business services provided and used by each Mission Area; Governed by a cross-mission Area board, which is chaired by the DoD Chief Information Officer (CIO); Managed by Global Information Grid (GIG) NetOps 5

6 Data Sharing in a Net-Centric Department of Defense 4/23/2007 (1 of 2) section 4. POLICY: It is DoD policy that: 4.1. Data is an essential enabler of network-centric warfare (NCW) and shall be made visible, accessible, and understandable to any potential user in the Department of Defense as early as possible in the life cycle to support mission objectives Data assets shall be made visible by creating and associating metadata ( tagging ), including discovery metadata, for each asset. Discovery metadata shall conform to the Department of Defense Discovery Metadata Specification (reference (d)). DoD metadata standards shall comply with applicable national and international consensus standards for metadata exchange whenever possible. All metadata shall be discoverable, searchable, and retrievable using DoD-wide capabilities Data assets shall be made accessible by making data available in shared spaces. All data assets shall be accessible to all users in the Department of Defense except where limited by law, policy, or security classification. Data that is accessible to all users in the Department of Defense shall conform to DoD-specified data publication methods that are consistent with GIG enterprise and user technologies. 6

7 Data Sharing in a Net-Centric Department of Defense 4/23/2007 (2 of 2) 4.4. Data assets shall be made understandable by publishing associated semantic and structural metadata in a federated DoD metadata registry To enable trust, data assets shall have associated information assurance and security metadata, and an authoritative source for the data shall be identified when appropriate Data interoperability shall be supported by making data assets understandable and by enabling business and mission processes to be reused where possible Semantic and structural agreements for data sharing shall be promoted through communities (e.g., communities of interest (COIs)), consisting of data users (producers and consumers) and system developers, in accordance with reference (b) Data sharing concepts and practices shall be incorporated into education and awareness training and appropriate DoD processes. 7

8 2. Why do we need DM2 + DoDAF Views? 8

9 Need for DM2 service-related elements: Definitions Model Based Approach Model Based implies: Only one definition can exist for any element of the model Unique representation in model repository Any number of presentations are possible Model is integrated Relationships between elements are themselves model elements Modeling language is based upon a generalized Metamodel INCOSE Model-Based Systems Engineering (MBSE) is an initiative of The International Council on Systems Engineering (INCOSE) 9

10 Need for DoDAF Services Viewpoint Definitions Architecture Framework* Definition Conventions and common practices for architecture description established within a specific domain or stakeholder community Characteristics Serves as a standard for architecture descriptions (a model or set of models) Describes a method for designing an information system in terms of A set of building blocks Showing how the building blocks fit together Contains a set of tools Provides a common vocabulary Terms and concepts pertaining to the content and use of architectural descriptions Defines a logical structure for classifying and organizing complex information to support acquisition decisions An architecture description includes one or more architecture views. Each architecture view (or simply, view) addresses some of the architecture-related concerns held by the stakeholders of the of the system. * IEEE P42010/D6::ISO/IEC WD , Systems and Software Engineering Architecture description,

11 DoDAF Is an architecture framework That supports 5 DoD Key Processes JCIDS, DAS, PPBE, Systems Engineering, Operations, Portfolio Management (IT and Capability) Question: Do DM2 and DoDAF Views currently enable architects to develop architecture descriptions to support all 5 DoD Key Processes? Today s Question: Do DM2 and DoDAF Views currently enable architects to develop architecture descriptions to support Net-Centric solutions? 11

12 3. Context: What is a <logical solution domain> service? Why do we need a Services Viewpoint in DoDAF

13 What is a service? A service provides well defined, self-contained functionality that is loosely coupled from other functionality/services. 1. The service functionality is well encapsulated- 2. -Except for the information required by the consumers to determine whether a given service is appropriate for their needs is exposed in the service interface (specification/description) [7], accessible through a service port. 3. The semantics of a service should be documented, either directly or indirectly, by its specification/description, or set of messages (resources produced and consumed [9]). 4. Services have coarse granularity, they tend to use a small number of operations with relatively large and complex messages which are exchanged between the provider and consumers. 5. A service is location transparent (i.e., consumers do not need to be aware of the physical location of a hosting server); 13

14 What is a service? Definitions DoDAF Adopted: (Net-Centric Services Strategy, 3/2007): A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. (OASIS SOA RM): A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. 14

15 What is a service? Definitions (Cont d) (The Free On-line Dictionary of Computing): Work performed (or offered) by a server. This may mean simply serving simple requests for data to be sent or stored (as with file servers, gopher or http servers, servers, finger servers, SQL servers, etc.); or it may be more complex work, such as that of irc servers, print servers, X Windows servers, or process servers. E.g. "Access to the finger service is restricted to the local subnet, for security reasons". (Mark Lankhorst, et. al., Archimate Language Primer, Telematica Institut, the Netherlands, p 4.): A service is defined as a unit of functionality that some entity (e.g., a system, organization or department) makes available to its environment and which has some value to certain entities in the environment. 15

16 Manufacturing/Hardware Interchangeable parts are parts that are, for practical purposes, identical. They are made to specifications that ensure that they are so nearly identical that they will fit into any device of the same type. One such part can freely replace another, without any custom fitting (such as filing). This interchangeability allows easy assembly of new devices, and easier repair of existing devices, while minimizing both the time and skill required of the person doing the assembly or repair. The concept of interchangeability was crucial to the introduction of the assembly line at the beginning of the 20th century, and has become a ubiquitous element of modern manufacturing. 16

17 Software: What is SOA? SOA is a form of distributed systems architecture based on services (as defined above) where a consumer does not need to know the internal structure of a provided service, including features such as its implementation language, process structure, and even database structure [9]. In SOA, the focus is on the sequence of operational activities or business process. The process is then mapped to a systems architecture description with specific applications that support the process cast as services. Thus, the architecture supports an operational/business process via a set of independent, reusable, but collaborative services. 17

18 Advantages of SOA SOA offers several advantages: An operational process orchestrates simple services into complex services Services allow the exchange of information and data (resources) between: different computers, from different vendors, different programs, from different functional areas, or different members of a Community of Interest (CoI), SOA supports globalization and the integration of geographically dispersed organizations (net centricity) through service orchestration of distributed services owned and executed across ownership boundaries [6]. 18

19 4. Service vs. System 19

20 Service vs. System Operational Viewpoint, describing the problem, "Coast Guard Search and Rescue (SAR)" maps to the concept we currently call capability in DM2. Systems Viewpoint, describing the physical solution, one of the systems supporting SAR maybe a Maritime Monitoring System. This maps to the concept we currently call a system in DM2 (where a system is defined as a combination of hardware, software, and people, with all needed training, supplies, etc.) If one is to develop systems that support net-centricity, one needs to first develop a Service Oriented logical solution Services Viewpoint, describing the logical solution, one of the services supporting a SAR capability maybe a Track Boat Service. This will map to a service as defined by OASIS RM and DoD Such a service would have characteristics as defined in a SOA approach, and would be a logical description of a solution (devoid of implementation detail). 20

21 Service vs. System Viewpoint One does not HAVE to define services and develop Services Views, if the intended physical solution is not desired to have SOA characteristics, OR if the architecture model is to describe an existing solution (AS- IS) If the desired solution: is to be service oriented, reflecting all characteristics as defined by industry and collectively termed SOA, then DM2 and DoDAF must enable architects to do so: by defining concepts and supporting views that reflect this definition 21

22 Summary 1. Defined a DoD requirement DoD to support development of net-centric solutions 2. Established that DM2 + DoDAF (we need both) are the constructs defined within DoD to enable architects to create architecture descriptions (models) 3. Provided definitions for the term service as used in industry, and as adopted by DoD to support development of net-centric solutions 4. Established that in this context Service and System are not equivalent terms 22

23 Bottom Line Up front (BLUF) DoD has a requirement to develop solutions that are Net- Centric DOD has a requirement to model services and SOA as defined by industry Derived Requirement: Define the concept of a <logical solution domain> service, along with a Services Viewpoint in DoDAF 23

24 Conclusion A Service, as defined in OASIS RM and adopted by DOD, is NOT the same as a System, as defined by DoD and in DM2 Currently (DoDAF v2.02), DM2 s service related elements and DoDAF defined service viewpoint models Do Not support this need (see numerous reviews/comments submitted by SAF/A6PA) There is an identified requirement to enhance DM2 and DoDAF to enable architects to do so: by defining concepts and supporting views that reflect this definition 24