• DODAF Home 
• Background 
• Architectural Development 
• Meta Model 
  • Conceptual 
  • Logical 
  • PES 
  • IDEAS Foundation Ontology 
• Viewpoints & Models
  • All Viewpoint 
  • Capability Viewpoint 
  • Data and Information Viewpoint 
  • Operational Viewpoint 
  • Project Viewpoint 
  • Services Viewpoint 
  • Standards Viewpoint 
  • Systems Viewpoint 
  • Models 
  • Model Categories
  • Levels of Architecture
  • Architecture Interrogatives 
  • Architecture Modeling Primitives
  • Mapping to DM2 
• Presentation Techniques
  • Composite Views 
  • Fusion Views 
  • Reference Models 
• DODAF-DM2 Configuration Management
• Related Links 
• Acronyms List and Glossary of Terms 
• Site Map 
• Archives

Services

A Service, in its broadest sense, is a well-defined way to provide a unit of work, through which a provider provides a useful result to a consumer. Services do not necessarily equate to web-based technology or functions, although their use in the net-centric environment generally involves the use of web-based, or network-based, resources.

Functionally, a Service is a set of strictly delineated functionalities, restricted to answering the what-question, independent of construction or implementation issues*. Services form a layer, decoupling operational activities from organizational arrangements of resources, such as people and information systems. Finally, Services form a pool that can be orchestrated in support of operational activities, and the operational activities define the level of quality at which the Services are offered.

The Services Data Group provides those data that support the definition and use of Services within the net-centric environment. Section 2.7.1 identifies and describes the data within the group; Section 2.7.2 provides an example method for collecting data on services; Section 2.7.3 provides illustrative uses of the data, and Section 2.7.4 provides presentation examples for using the Services-related data for presentation to/for management in decision-making.

Data Group Description

The DoDAF Meta Model for the data comprising services is shown in the figure below. Note the following guidance:

1. Services are activities done by a Service provider (Performer) to achieve desired results for a Service consumer (other Performer). A Service is a type of Performer which means that it executes an activity and provides a capability.
2. Capabilities and Services are related in two ways. One, the realization or implementation of a Capability by a Performer (usually a configuration of Performers, including Locations) may include within the configuration Services (or Service compositions) to access other Performers within the overall Performer configuration. Conversely, the realization or implementation of a Capability by a Performer (configuration, including Location) may provide the Performers that are accessed by a Service (or Service composition).
3. Unlike DoDAF V1.5, Services in DoDAF V2.0 include business services, such as Search and Rescue. This is important to keep in mind because much of the SOA literature is IT-oriented.
4. Although, in principle, anything has a description, the importance of self-description for discovery and use of Services merits its call-out as a class. Further, because only a public-facing side is described, the Service description needs to represent that it describes the Service Port, not the entire Service. A Service Port is a special type of Port that is self-describing and visible. The Service Description of the Service Port is of all aspects necessary to utilize the Service and no more. As such, it may include visible functionality, QoS, interface descriptions, data descriptions, references to Standards or other Rules (Service Policy), etc. The inner workings of the Service are not described in a Service Description.
5. Since Service inherits whole-part, temporal whole-part (and with it before-after), Service may refer to an orchestrated or choreographed Service, as well as individual Service components.
6. Since Service Ports are types of Ports and Ports are types of Performers, they inherit all of Performer's properties, including Measures associated with the Performer, performance of Activities (Service Functions) with associated Measures, and provision of objects (Materiel, Data, Information, Performers, Geopolitical Extents).
7. Any Performer that consumes a Service may have a Service Port that is described in the service request. This description indicates how the Service provider should provide or respond back to the Service consumer. That is, Service Ports are parts of Performers that may or may not be Services themselves.

DoDAF Meta Model for Services
(Click image to enlarge)

Usage in Core Processes

The Services Data Group captures service requirements for capabilities, performers and operational activities supporting all the core processes. The DM2 data elements describing Services are linkable to architecture artifacts in the Operational, Capability, System and Project Viewpoints.

Data for Service are used in the six core processes in the following ways:

1. JCIDS, PPBE, DAS and SE:
   1) Services, such as those reified into web or computer based software services (Software as a Service (SaaS), are considered Performers and are used in the same fashion (See Performer Usage in Core Processes 2.1.2).
2. Ops Planning:
   1) Service functions (activities and processes) and resources support operational Planning and other processes that facilitate the exchange of information among Performers, aid in decision making and support training. TT&P documents together with training materials generally contain the Service used in Operations.
   2) Business processes (e.g. Administrative, Logistics, etc) also can be reified as Services both manual and automated. 
3. CPM:
   1) Services such as SaaS can be part of a portofolio.

Presentation

Services are generally rendered using all the presentation techniques shown in Section 1.3. Typically Structural, behavioral and tree models are used to depict Services with amplifying tabular information.