The world is changing at an ever faster rate. Traditional methods of architecting both business functions and software functionality cannot keep up with the pace of this rapid rate of change. The luxury of crafting custom functionality in systems to tailor them to an enterprise’s specific needs is being overtaken by investment in commodity software. Enterprises are either changing business processes to adapt to the software or customizing the software to fit the business. Internal software development must also be leveraged. A change in the style with which traditional requirements-driven monolithic software was being developed is occurring. In this style of architecting, functional capabilities are implemented in modular, decoupled, scalable services that are individually implemented, and larger grain business functionality is achieved by composing multiple services, some home-grown, others purchased.

Conventional Information Technology Services

With the widespread adoption of cloud technology and the view of information technology services as a utility that can be purchased and expensed as a scalable collection of services from providers outside the enterprise, architecting services have become ever more important. Conventionally, services have been divided into the following, starting from the business end to the information technology components end:

• Business Services

• Software as a Service (SaaS)

• Platform as a Service (PaaS)

• Infrastructure as a Service (IaaS)

Business Services

In the area of business functions, vertically integrated enterprises that develop their own business functions are often outpaced by nimbler competitors that offload the functions to service providers and concentrate on managing the interfaces with these service suppliers. Even small businesses are outsourcing their payment transactions to card payment processing services that take over once a credit card is swiped. Enterprises are increasingly focused on their “core competencies” and offload mission support functions to business partners whose own core competency is providing that function. These offloaded business functions are deemed services, although any packaged business function that is loosely coupled and governed by agreement or contract between the provider and consumer may be deemed a business service.

The design of a service therefore requires architecture decoupling of interrelationships so that the service can be treated as a black box, whose behavior and performance can be negotiated as a level of delivery of service. It also requires clear definition of service interfaces—how the service looks to the consumer—that is independent of the internal implementation of the service. Atomic services by themselves are also stateless—their invocation processes maintain the state information needed to successfully orchestrate a collection of services needed to achieve a business objective or mission.

Business services for the consumer simply represent an undertaking by a provider to deliver service at an agreed upon grade, quality, and price through a service agreement (SLA). The service agreement also defines how the service will be delivered, how acceptance and payment is to be made, how to seek redress, as well as caveats, restrictions, and limitations.

The provider of the service, on the other hand, has to deal with many issues that surround the development, standing up, and delivery of a service to consumers. Business services encapsulate data, algorithms/process steps, and business rules as constraints, computational formulas, or guidance for decision-making. Services also need to be managed as secured objects that require controls for access and traceability of usage. For services that require transparency, they also need controls to enable auditing and logging. Services may also have to comply with regulations and concerns related to data privacy.

Software as a Service (SaaS)

In the area of software development, a similar solution based on vertically integrated software relies on in-house development of software functions that are tightly tied to the software solution being developed. Such tightly integrated systems are immune to adaptability, because the impact of change requires widespread change to the solution. At the same time, the enterprise cannot take advantage of market forces for a software component that can be purchased, leased, or supplied by external providers. Software services are standalone, loosely coupled, defined with clear published interfaces, and stateless providers of functionality that are used as building blocks to build software applications.

Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. A key characteristic of SOA is modularity that facilitates/enables service reuse across processes and organizational boundaries. A service that is designated for reuse or as an enterprise service, such as authentication, must reside in an environment that is discoverable, reliable, maintainable, and monitorable. An overarching architecture is needed to contain these services as they are developed and implemented.

SaaS is a natural evolution of thin client, fat server technology, where a web browser serves as a client and services are delivered by a cloud-based server that may or may not be owned or controlled by the enterprise but is managed through SLAs between the enterprise and the service provider—usually a third party. SaaS is the most ubiquitous model of services today with widespread adoption of cloud-based software providing e-mail, word processing, business presentation, spreadsheet, accounting, and tax preparation capabilities. As acceptance for the concept of “renting” software from businesses and users grows, more and more traditional installed commercial-off-the-shelf (COTS) software is being delivered as a service.

Platform as a Service (PaaS)

Gartner defines a PaaS offering as a broad collection of application infrastructure (middleware) services (including application platform, integration, business process management, and database services).

Microsoft Corporation (https://azure.microsoft.com/en-us/overview/what-is-paas/). defines PaaS as “a complete development and deployment environment in the cloud, with resources that enable you to deliver everything from simple cloud-based apps to sophisticated, cloud-enabled enterprise applications. You purchase the resources you need from a cloud service provider on a pay-as-you-go basis and access them over a secure Internet connection.”

PaaS, like IaaS, includes infrastructure—servers, storage, and networking—but also middleware, development tools, business intelligence (BI) services, database management systems, and more. PaaS is designed to support the complete web application life cycle: building, testing, deploying, managing, and updating.

PaaS is built on top of virtualization technology. Enterprises can requisition virtual resources as they need them, scaling up as demand grows or scaling down when demand shrinks.

Infrastructure as a Service (IaaS)

According to Gartner, IaaS is a “standardized, highly automated offering, where compute resources, complemented by storage and networking capabilities, are owned and hosted by a service provider and offered to customers on-demand. Customers are able to self-provision this infrastructure, using a web-based GUI that serves as an IT operations management console for the overall environment. API access to the infrastructure may also be offered as an option.”

Architecting a DoDAF Solution Through Service Components

Regardless of the type of individual component services in use, a business or technology solution typically requires several service components that must be brought together and integrated. A service composition is an aggregate of services that automate a particular task or business process. Integrating the invocation of multiple services in a planned manner requires orchestration. Some of the architecture needs related to issues and concerns regarding the Services Viewpoint follow:

• Realize capability need through service solutions   Capabilities represent the statement of generalized needs to enable outcomes or achieve desired effects. Capabilities are used by the planner to determine what needs to be acquired. Services represent solutions that satisfy the capability need. The DoDAF CV-7: Capability to Services Mapping establishes an explicit association between the capability need and the service solution that guides the capability planner to specify what services will deliver desired capability.

• Identify service performers   In a SOA, services are provided by a service provider and used or consumed by a service consumer. Intermediary performers such as service brokers provide value-added services. Service performers, service brokers, and service consumers are tied together through service agreements that specify terms of provision and consumption of services, quality of services, and other parameters that govern how the service will be delivered on an ongoing basis. The key transactions between the performers are the request for service from a consumer and the ultimate provision of the service by the provider. The transactions are performed through a messaging infrastructure. In the DoDAF, services can result in transfer of resources other than information, in addition to transfer of information for notifications.

• Specify services functionality   Just as the operational activity was the prime ingredient for changing operational behavior, the service operation is the prime ingredient that describes service behavior. The SvcV-4: Services Functionality Description models the service operations that have been implemented or are planned for a system as a well-ordered taxonomy. The SvcV-4 is useful to compare services functions across multiple services, looking for duplication and overlaps. It also helps to establish a composition map for larger grain services in terms of smaller grain service components. The SvcV-4 also models the input/output behavior of service operations in terms of the information/resources they consume, transform, or produce. The SvcV-4 can be used to examine the orchestration of information exchanges/resource flows between multiple services and to drive the development of service specifications at the implementation level using specification languages such as the Web Services Description Language (WSDL).

• Analyze service resource flow/information exchange requirements   The counterpart to the OV-2: Operational Resource Flow Description is the SvcV-1: Services Context Description. The SvcV-1 replaces the operational performers and locations in the OV-2 with services performers and services hosting locations, and it also replaces the operational need lines that indicated needs for exchange of information/flow of resources with interfaces that indicate a need to exchange information/resource flows between services performers. If every operational performer were to be supported by a single service, the layout of the SvcV-1 would perfectly match the layout of the OV-2. But in reality, multiple services support a single performer, and nonautomated activities in the operational realm do not have a service counterpart in the services realm. The SvcV-3b: Services-Services Matrix is a compact model that represents some aspect of interaction between pairs of services. The SvcV-3b may also be used as a compact model for representing the many interfaces in a large and complex SvcV-1. Other services resource flow models such as the SvcV-6: Services Resource Flow Matrix focus on the details of the information exchanges/resource flows between specific services in the context of specific service operations being performed by the services.

• Analyze services connectivity   The interfaces that demonstrate the need for information exchange/resource flows between services inside the SvcV-1 need to be implemented physically using communication paths that connect the services together and provide a means for transmitting and receiving information/resources. In the IT sense, these are represented by paths through communication links, communication equipment, and computer networks. In the more general sense of resource flows, rather than simply information flows, these represent logistic chains that channel resources between services such as concourses in airports, baggage conveyor belts, and so on. The SvcV-2: Services Resource Flow Description models the physical paths that are travelled by information/resources between services. Since the physical path may have several intermediate links that are purely to route communications and resource transfer, the SvcV-1 may not have an exact correspondence with the SvcV-2 even though the end points for the path must coincide. The SvcV-2 is a depiction of the physical transfer path for information/resources that is depicted in the interfaces in the SvcV-1.

• Trace services to operational usefulness   Too often, services are built with many features that were required at the time by business or military operations. As time goes on, some of these features may not be very useful or may represent obsolete functions. The SvcV-5: Operational Activity to Services Traceability Matrix maps services and service operations to the operational activities they support. This is a useful view for analyzing the impact of change of either the operational activity or the service operation on each other. For future planned services, it also provides an explicit plan of which operational activities will be enabled/facilitated or automated by a service operation.

• Moving from a business process–focused approach to a business service–based approach   Enterprises that are contemplating migrating internally performed business processes to one or more business services need a plan to identify which service or collection of services would replace a specific business process. The SvcV-5 can be used as a mapper for a business service to an operational process to support the representation/replacement of a current internally performed business process with a candidate/actual business service that will provide the same functionality. Using a business service approach “detaches” a business process and provides the ability to outsource it to a service provider without worrying about the internals and focusing instead on outputs and outcomes.

• Specify service performance   Another useful view is the SvcV-7: Services Measures Matrix used to specify the measurements for acceptance of a service or specifications that drive the acquisition of service capabilities. The specification of performance measures early in a service specification enables tradeoffs to be made during the design process and establishes minimum acceptance criteria for various components as well as the service itself. Service measures are a key part of service agreements that bind providers and consumers to service levels and quality of service.

• Develop services evolution roadmap   For planners, one of the important models to build is a roadmap of services evolution. The SvcV-8: Services Evolution Description view offers the representation in two formats: evolution of features and functions for services in planned release increments, consolidation, and migration of multiple services into one or more target services. The SvcV-8 is a useful view for planning modernization initiatives as well as for allocating feature evolution to service increments.

• Map services to operating platforms   For technology infrastructure staff, it is important to map services to the operating platforms that they need to run on. The SvcV-9: Services Technology and Skills Forecast view provides the capability of expressing a platform migration strategy for specific services. A portfolio of SvcV-9 models can then be used at the enterprise level to determine mismatches in migration strategy or missed migrations, for example. Service platforms themselves provide technology services. Database platforms provide query services; operating systems platforms provide file retrieval services.

• Model service behaviors   For detailed views of services behavior, the SvcV-10a: Services Rules Model, SvcV-10b: Services State Transition Description, and the SvcV-10c: Services Event-Trace Description are available as counterparts of the OV-6a, OV-6b, and OV-6c operational behavioral views. These are useful for providing detailed representation of orchestration sequences of internal service operations, information/resource exchanges, and triggering events (SvcV-10c), or for detailed representation of constraints or algorithmic behavior used to implement service operations (SvcV-10a), or for detailed representation of the internal state transitions of a service in the face of triggering events and activities.

Services Viewpoint Views

This section discusses the various views associated with the DoDAF Services Viewpoint. Each of these views addresses some specific concern from the Services Viewpoint. Remember that within the Services Viewpoint, the issues and concerns of a service consumer may be different from those of a service provider.

For brevity, a partial subset of the Services Viewpoint is shown in Figure 17-1 to illustrate the concepts of integrated models in the context of the Services Viewpoint (missing are SvcV-9, SvcV-10a, SvcV-10b, and SvcV-10c). Figure 17-1 shows a simplistic view of the various elements that are visible in the Services Viewpoint. The figure is more a picture than a formal model, and the arrow in the relationships provides a reading order for the name of the relationship using the start concept of the arrow with the name on the arrow and the end concept of the arrow.

Figure 17-1   Integrated view of the Services Viewpoint

The Services Viewpoint also has a tight coupling of models for consistency purposes. Views share many common elements such as services, services functions, service locations, data flows, and so on.

Following are some examples of the needs for consistent use of architecture elements between Services Viewpoint views:

• SvcV-1 services must be consistent with SvcV-2 services. SvcV-1 interfaces must be consistent with SvcV-4 data flows and SvcV-6 data exchanges between the same end point services.

• SvcV-4 service operations must be consistent with SvcV-5 service operations.

In addition to the integration needs of views within the Services Viewpoint, there are integration needs implicit inside the views to other viewpoints. Here are examples:

• SvcV-5 maps the services functions and services to operational activities defined inside the Operational Viewpoint.

• SvcV-9 must be consistent in the evolution of system technology to the elements defined in the StdV-1: Standards Profile and the StdV-2: Standards Forecast.

SvcV-1: Services Context Description

Example: Passenger Identification SvcV-1

In the SvcV-1: Services Context Description (Figure 17-2), we have shown the services at different locations. The locations also represent different types of activities that are being performed by various performers at those locations.

Figure 17-2   Passenger identification SvcV-1: Services Context Description

The diagram shows the as-is interfaces in the circles along the outside of the figure. In the as-is situation, the various services are independently invoking their own passenger identification operations internally (not shown). The double-arrowed lines show the proposed interface configuration where a single passenger identification service (processIdentifyPAX) is provided centrally from the RMN Operations Center and can service each of the locations from a single point. The proposed solution will eliminate differing business rules in the separate implementations of passenger identification and provides uniform updates for all stakeholders.

The lines with single arrows indicate the as-is need for interaction between services representing independent passenger identification capabilities and the double arrow-headed lines the proposed configuration, with a centralized service processIdentifyPAX at the RMN Operations Center that provides identification services to all invoking services located at the various locations.

SvcV-2: Services Resource Flow Description

Example: Passenger Identification SvcV-2

The SvcV-2 shown in Figure 17-3 is for architecting the boarding gate kiosk. The kiosk allows a passenger to insert a combination of magnetically encoded identification cards and/or machine readable passports. The kiosk invokes a common service validateIdentityDocument provided by the RMN data center to all consumers who want to validate magnetic cards and machine readable passports.

Figure 17-3   Passenger identification SvcV-2: Services Resource Flow Description

SvcV-3a: Systems-Services Matrix
SvcV-3b: Services-Services Matrix

Example: Passenger Identification SvcV-3a

The SvcV-3a shown in Table 17-1 depicts current interfaces between systems and services as well as the planned interfaces. We notice clearly the planned transition of all systems to a single consistent identifyPassenger service that will eliminate the inconsistencies, ambiguities, and inaccuracies that are evident in the current multiplicity of independent interfaces to independent services. We show the time frame for the migration that is implied inside the SvcV-3a in the SvcV-8: Services Evolution Description. The advantage of each of these views is that they elaborate some aspect of the architecture, but each view adds a different dimension for a different audience. Without integration, the views would very quickly become inconsistent.

Table 17-1   Passenger Identification SvcV-3a: Systems-Services Matrix

The SvcV-3b expresses relationships between services in much the same way the SvcV-3a showed the relationship between systems and services. The cell intersections can carry any information that is a characteristic of the association between system and service (or service and service) such as planned/actual as we have chosen to do in the SvcV-3a example.

The SvcV-3 views provide a compact representation for interactions between systems and services and also between services themselves. The meaning of the intersection cell is left to the modeler and must be described in a legend accompanying the view. The SvcV-3 views can be used to display compactly the information in a large and complex SvcV-1 in a single matrix instead of a large diagram running into several pages.

SvcV-4: Services Functionality Description

Example: Passenger Identification SvcV-4

Notice in Figure 17-4 that the way we have broken down the large grain “Read Identity Document” into various sub-functions of smaller grain services is by using two techniques:

• Breaking down the life cycle of the larger grain service into component services that form the life cycle steps such as Recognize Identity Document Type, Acquire Identity Dataset, Process Identification Dataset, and Format Identification Master Record.

• Specializing a type of service into subservices that perform the same function on different payloads because of business rule differences or the need to reach out to different external resources. In this example, the larger abstraction Recognize Identity Document Type is specialized into Recognize Drivers License, Recognize Machine Readable Passport, and Recognize Machine Readable Travel Document.

Figure 17-4   Passenger identification SvcV-4: Services Functionality Description

SvcV-5: Operational Activity to Services Traceability Matrix

Example: Passenger Identification SvcV-5

In Table 17-2, although it appears that the intersections of services are for all operational activities (within the scope of this SvcV-5 view), the important finding is that the reuse potential for the services is extremely high, since identity documents are read and validated in every context in which determining a passenger’s identity through an identification document is important.

Table 17-2   Passenger Identification SvcV-5: Operational Activity to Services Traceability Matrix

In general, the SvcV-5 view enables the service architect to establish correspondence between a service and the operational context in which it is useful. Planning a family of services is similar to a product planning exercise where the planner is determining the product features that maximize market coverage and minimize development investments.

SvcV-6: Services Resource Flow Matrix

Example: Passenger Identification SvcV-6

Table 17-3 shows a sample resource flow matrix that corresponds to the SvcV-2 view presented earlier. The SvcV-6 tabulates the resource flows (in this case, data exchanges) and also optionally depicts standards, formats, media types, criticality, and other attributes of the resource exchange that help the architect assess and promote interoperability between the exchanging services. This example does not include service functions.

Table 17-3   Passenger Identification SvcV-6: Services Resource Flow Matrix

SvcV-7: Services Measures Matrix

Example: Passenger Identification SvcV-7

In Table 17-4, the SvcV-7 specifies baseline (current), threshold (acceptable), and objective (desired) performance parameters for the identifyPassenger service. In reality, an SLA is used to specify service levels for both business and software services and acts as a durable agreement between service provider and service consumer that guarantees a level of service under contractual penalties.

Table 17-4   Passenger Identification Service Measures Matrix SvcV-7

SvcV-8: Services Evolution Description

Example: Passenger Identification SvcV-8

Figure 17-5 shows the evolution of the IdentifyPassenger service and the migration of independent services currently used by various systems (as shown in the SvcV-3a: Systems-Services Matrix) to a common IdentifyPassenger service that incorporates common algorithms and business rules, and researches a comprehensive data sources to provide a single unified, consistent service.

Figure 17-5   Passenger Identification Services Evolution Description SvcV-8

The SvcV-8 can be built using one of two styles:

• Migration style diagram that shows how multiple services are migrated over time into one or more services, as shown in the example.

• Evolution style (not shown) that generally describes how a service or collection of services from a single provider evolves in terms of functionality over a time period.

SvcV-9: Services Technology and Skills Forecast

The SvcV-9: Services Technology and Skills Forecast (not shown) is similar to the SV-9: Systems Technology and Skills Forecast and depicts the planned insertion of technology into a collection of services over a period of time. It may also depict the need to acquire and insert skills for operators, developers, and maintainers of these services at the same time to ensure that skill development is orchestrated with service upgrades.

SvcV-10a: Services Rules Model

Example: Passenger Identification SvcV-10a

Service rules constrain some aspect of the service such as behavior. Service rules are embedded inside the logic that implements the service. For business services, service rules may be provided as a constraint specification by the business entity that is sponsoring the service. Typically, these may be rules that must flow through to service providers such as in regulatory scenarios or in compliance with requirements of policy. Table 17-5 shows an example.

Table 17-5   Passenger Identification SvcV-10a: Services Rules Model

SvcV-10b: Services State Transition Description

Example: Free Wi-Fi Kiosk Service SvcV-10b

Figure 17-6 represents the states of a hypothetical kiosk service that entitles passengers (PAX) to free Wi-Fi services for Internet connectivity. In this example, we insert a few conditions that are to be fulfilled before a passenger receives Wi-Fi services. (1) A passenger is required to identify himself/herself to the service through a contactless identity document. Without valid identification, Wi-Fi access is denied. (2) He/she is also required to provide a travel document such as a boarding pass that shows that they have arrived or are departing within the space of twenty-four hours from the time of the Wi-Fi request. (3) The passenger should not have previously availed themselves of the Wi-Fi service within the last twenty-four hours. If these conditions are satisfied, the service will provide four hours of free Wi-Fi access through the kiosk that also has a built-in web browser to connect to the worldwide web.

Figure 17-6   Passenger Kiosk Free Wi-Fi Service SV-10b: Services State Transition Description

SvcV-10c: Services Event-Trace Description

The SvcV-10c: Services Event-Trace Description (not shown) is similar to the SV-10c: Systems Event-Trace Description, except that the lifelines depict services (and service providers) and the exchange of messages represents interactions between the services as depicted over a timeline. The SvcV-10c enables the architect to describe detailed interactions between services to examine issues related to timing as well as responsibility. The SvcV-10c is typically used to elaborate a scenario or contained situation and is generally too fine-grained for enterprise-level architectures. In much the same way activities performed by their performers are depicted on the lifelines, service operations performed by the respective services may also be depicted on the lifelines.

DoD View of Services (DoD Information Enterprise Architecture)

The Department of Defense Information Enterprise Architecture (DoD IEA) version 2.0 was approved by the DoD Chief Information Officer on August 10, 2012 for immediate use and supersedes the previous DoD IEA v1.2. It provides the common vocabulary for describing the capabilities, activities and services to achieve the Joint Information Environment (JIE).

The DoD IEA uses the DoDAF to represent the views that describe (i) a set of common capabilities that are required to support the JIE, (ii) the operational activities that are required to stand up and sustain the information enterprise, (iii) a common vocabulary for the types of services that will be provided to support the JIE from the viewpoint of the Joint enterprise, (iv) relationships between these architecture elements to provide an integrated architecture. The DoD IEA provides the roadmap for services that will be delivered to DoD applications and systems enterprise-wide to promote consistency and uniformity between independently developed applications that are required to work together in a peacetime and wartime environment.

TOGAF View of Services

TOGAF 9 distinguishes business functions from business services from information system services using the following definitions:

• Function   A thing that a business does. Services support functions, are functions, and have functions, but functions are not necessarily services. Services have more specific constraints than functions.

• Business service   A thing that a business does that has a defined, measured interface and has contracts with consumers of the service. A business service is supported by combinations of people, processes, and technologies.

• Information system service   A thing that a business does that has a defined, measured interface and has contracts with consumers of the service. Information system services are directly supported by applications and have associations to SOA service interfaces.

TOGAF Service Artifacts

The business architecture developed in Phase B of the TOGAF Architecture Development Method (ADM) contains the following artifacts relevant to the Services Viewpoint:

• Business Service/Function Catalog   Contains a catalog of organizational units, business functions, business services, and information system services, and relationships among these.

• Business Service/Information Diagram   Shows the information needed to support one or more business services. Shows what data is consumed or produced by a business service and may also show the data source for that information. Similar to the DoDAF SvcV-4: Services Functionality Description.

• Goal/Objective/Service Diagram   Defines the ways in which a service contributes to the achievement of a business vision or strategy. Services are associated with the drivers, goals, objectives, and measures that they support. Useful for making the business case for a service. Similar to the DoDAF CV-1: Vision combined with the CV-7: Capability to Services Mapping.

• Business Footprint Diagram   Describes the links between business goals, organizational units, business functions, and services and establishes line of sight from service to goal. Each line of sight is represented on a swim lane for each organizational unit. Useful for planning services and making a business case and identifying sponsors.

• Business Use Case Diagram   Displays the relationships between consumers and providers of business services. Business services are consumed by actors or other business services. The business use-case diagram provides added richness in describing business capability by illustrating how and when that capability is used. The artifact is similar to the CV-7: Capability to Services Mapping with added information about consumers and providers.

The application architecture developed in Phase C of the ADM contains the following artifacts relevant to the Services Viewpoint:

• Application Portfolio Catalog   Intended to identify and maintain a list of all applications in the enterprise. It contains instances of logical application components, physical application components, and information systems services as well as relationships among these.

• Interface Catalog   Scopes and documents the interfaces between applications to establish overall dependencies between applications to be scoped as early as possible. This artifact can be tailored to reflect service interface agreements between information system services. The functionality of the artifact is similar to the SvcV-1: Services Context Description.

• Application/Organization Matrix   Depicts the relationship between applications and organizational units that use the applications. This can be tailored to include information system services used by organizations and also add relationships that reflect ownership/stewardship/responsibility for provision concerns.

• Role/Application Matrix   Depicts the relationship between applications and the business roles that use them within the enterprise. This artifact can be tailored to reflect relationships between user roles and information system services to support an access control strategy for such services. The function of this artifact can be accomplished by authorization rules in the DoDAF SvcV-10a: Services Rules Model.

• Information Exchange Matrix   Documents the information exchanges between applications (tailored for information system services) showing source, destination, unique label, the data that is exchanged, and the triggering (business) event. This artifact is similar in scope to the DoDAF SvcV-6: Services Resource Flow Matrix.

• Enterprise Manageability Diagram   Shows how one or more applications (tailored to be information system services) interact with application and technology components that support operational management of a solution. This is a useful artifact for supporting a service management framework.

• Process/Application Realization Diagram   Depicts the sequence of events when multiple applications are involved in executing a business process. The artifact is similar to a swim lane process diagram where the performers can be either applications, systems, or information system services. The DoDAF SvcV-10c: Services Event-Trace Description is similar to this artifact.

• Software Engineering Diagram   Breaks applications into packages, modules, services, and operations from a development perspective and is a bill of materials for driving the development of applications and information system services.

• Application Migration Diagram   Identifies application migration from baseline to target application components. When tailored to represent information system services, this artifact becomes similar to the SvcV-8: Services Evolution Description.

The technology architecture developed in Phase D of the ADM contains the following artifacts relevant to the Services Viewpoint:

• Technology Standards Catalog

• Technology Portfolio Catalog

• System/Technology Matrix

• Platform Decomposition Diagram

• Networked Computing/Hardware Diagram

TOGAF Technical Reference Model

The TOGAF Technical Reference Model is part of the TOGAF foundation architecture (compare reference architecture discussions in Chapter 1). The TOGAF foundation architecture is an architecture of generic services and functions that provides a foundation on which more specific architecture and architectural components can be built. The foundation architecture has two main elements: The technical reference model (TRM), which provides a model and taxonomy of generic platform services, and the standards information base, which provides a database of standards that can be used to define the particular services and other components of an organization specific architecture. Figure 17-7 depicts the TRM.

Figure 17-7   Technical Reference Model (used with permission from TOGAF)

FEAF2 and Federal View of Services

Service-Oriented Framework

The Services Viewpoint caters to the interest of people responsible for planning, architecting, developing, implementing, and deploying service-oriented solutions. This is an evolutionary field that is arguably more well defined toward the construction of software services but less so in the planning and architecture realms.

Figure 17-8 depicts the layers of an agile enterprise based on a service-oriented paradigm [CIO Council 2008]:

Figure 17-8   Service-oriented framework (graphic from the Federal CIO Council)

• Service-oriented enterprise (SOE)   The business, management, and operational processes, procedures, and policies that support a services model. In essence this is an organizational behavior model aligned with the service model and designed to facilitate and govern its effective maturation. Organizational behavior drives the enterprise to seek a services-oriented solution approach to capability needs rather than the all-encompassing, integrated, monolithic solution of the day (purchased or developed) that is difficult and expensive to extend, evolve, customize, or modularize.

• Service-oriented architecture (SOA)   Enhanced architecture practices that leverage robust models to capture and facilitate service architecture engineering best practices. SOA is the application of the service model from EA, through segment architectures to solution architectures. Today there is much interest in micro-services—small units of functionality delivered as a service that have more universal reuse potential than larger granularity domain-specific services.

• Service-oriented infrastructure (SOI)   The service-enabling environment, itself delivered as a collection of robust enterprise services that enable runtime connectivity and interoperability. SOI represents the operational environment that supports the service model. Today’s infrastructure of choice is based on cloud deployment, concentration of data centers, virtualization of computing facilities, and a utility services view of infrastructure investments rather than as capital investments.

FEAF2 Service Artifacts

The business subarchitecture domain in the FEAF2 recommends the following artifact that is relevant to the Services Viewpoint:

• Business Service Catalog (B-3)   Presents the business services, taken from a business reference model that are provided within the scope of the architecture and may also indicate business services that are consumed or used internally within the architecture.

The applications subarchitecture domain in the FEAF2 recommends the following artifacts that are relevant to the Services Viewpoint:

• Application Interface Diagram (A-1)   The identification of application (service) resource flows and their composition. This artifact is similar to the SvcV-1: Services Context Description.

• Application Communication Diagram (A-2)   The means (communication paths) by which resource flows between applications (services) occur. This is equivalent to the SvcV-2: Services Resource Flow Description in the DoDAF.

• Application Interface Matrix (A-3)   The interface relationships among systems (services). This is equivalent to the DoDAF SvcV-3a: Systems-Services Matrix and SvcV-3b: Services-Services Matrix.

• Application Data Exchange Matrix (A-4)   The details of resource flows among systems (services), the activities performed, the resources exchanged, and the attributes (rules and measures) associated with these exchanges. This artifact is similar to the DoDAF SvcV-6: Services Resource Flow Matrix.

• Application Service Matrix (A-5)   Interface relationships between services and applications. This artifact is similar to the DoDAF SvcV-3a: Systems-Services Matrix and SvcV-3b: Services-Services Matrix.

• Application Performance Matrix (A-6)   The measures (metrics) of applications tailored also to define measures of service delivery and performance. This artifact is similar to the DoDAF SvcV-7: Services Measures Matrix.

• System/Application Evolution Diagram (A-7)   The planned incremental steps toward migrating a suite of systems and/or applications and/or services to a more efficient suite, or toward evolving a current system or application to a future implementation. This artifact is similar to the SvcV-8: Services Evolution Description.

• Enterprise Service Bus Diagram (A-8)   Describes the interaction and communication between mutually interacting software applications in a SOA.

• Application Inventory (A-10)   A registry of applications and services and the system functions or service activities they perform, which are, optionally, prioritized or ranked.

FEAF2 Business Reference Model

The business reference model (BRM) is a classification taxonomy used to describe the types of business functions and services that are performed in the federal government. The BRM provides a standard classification scheme under which business services are listed. These services may also represent application services that provide business/mission support capabilities. The expectation by OMB is that by using a common taxonomy for services, agencies can compare their needs to the availability of services from other agencies or offer their own services for sharing across the government.

The structure of the BRM is three layered, as shown in Figure 17-9:

Figure 17-9   FEAF2 BRM (graphic from the OMB)

• Mission Sector   Identifies the ten business areas of the federal government in the common approach to EA

• Business Function   Describes what the federal government does at an aggregated level, using the budget function classification codes provided in OMB Circular A-11

• Service   Further describes what the federal government does at a secondary or component level

By using the BRM service categories and classification schemes as attributes for the services in their service catalogs, agencies can align and report on their services to a standardized rubric.

Summary

The Service Viewpoint is becoming increasingly attractive as enterprises move away from monolithic systems that are complex, often undocumented and updated multiple times in their history to packaged services that can be independently invoked to provide capabilities. Service-oriented architectures are architected using the principles of separation of concerns and loose coupling. As enterprises adopt cloud computing, the scope of service-based implementation extends to software, platforms, infrastructures, and other capabilities that were traditionally purchased as capital items. The Service Viewpoint represents the solution counterpart to the requirements described within the Capability Viewpoint. The Capability to Services Mapping (CV-7) explicitly relates the capability requirement to the service solution.

In this chapter we describe the views that are described in the DoDAF for representing the concerns of service architects. The chapter describes views that present the overview of services that are developed within the scope of an architecture and the needs for orchestration and interactions between services and systems (SvcV-1, SvcV-2, SvcV-3a, SvcV-3b); the specific detailed functionality provided by the services (SvcV-4); the relationship between operational activities and the services that assist/augment/perform them (SvcV-5a, SvcV-5b); the protocols and resource exchanges between services (SvcV-6); performance specifications typically used for service level agreements (SvcV-7); the consolidation, migration, deprecation of services over time (SvcV-8); the evolution of technology and skill requirements over time needed to sustain services (SvcV-9); and representation of behavioral aspects of services such as rules and constraints that are embedded in the service algorithms, or constrain the use of the service (SvcV-10a), state transitions of services during the execution life cycle (SvcV-10b), and event trace of messaging on a timeline between services to understand latency, delay and timeliness issues (SvcV-10c).

TOGAF and the FEAF also address the service viewpoint with artifacts that extend the types of views described in this chapter. The area of service modeling and representation is constantly evolving, especially in the area of what is popularly termed, “the Internet of Things (IoT).” As the traditional boundary between hardware and software starts to disappear, service orientation provides a modular way to deliver functionality that is generally free of side effects and provides pin-pointed functionality for parts of a capability requirement from providers who specialize in that part.

Questions

1. What is a service? Distinguish between a business service and a software service.

2. What are the issues and concerns of a service consumer? What are the issues and concerns of a service provider? How do they differ?

3. What is a service level agreement? Which of the Services Viewpoint views describes the elements of a service level agreement?

4. How are operational performers such as service providers reflected in the Services Viewpoint? Which views represent service providers?

5. True or false?

a. Service models can be represented from the view of the service provider or the service consumer. These views are different. (Why?)

b. A service can be provided by more than one provider.

c. A service can be provisioned from more than one location.

d. The SvcV-2 view can represent service brokers because they are intermediaries and are not involved in the providing or consumption of the service directly.

6. What is the usefulness of the SvcV-1?

7. Which view would you develop to forecast and plan for platform migrations for a family of services?

8. Which view would you use to develop and refine service functionality and represent in detail, the decomposition of services down to the level of WSDL operations?

9. Which view would you use to compactly represent the interfaces between services?

10. Which view would you use to describe the data exchange protocols between services using message templates and automated data exchanges?

11. How would you restrict the scope of detailed, fine-grain behavioral modeling such as for the SvcV-10b and SvcV-10c?

12. What is the relationship between the SvcV-6 and the SvcV-10c? Which elements are required to be consistent for the views to be part of the same integrated architecture?

13. Which view would you use to trace a service back to the operational activities that it supports?

14. Which view would you use to trace the service back to a capability that was identified as a requirement by the enterprise?

15. Compare and contrast the SvcV-1: Services Context Description, the SvcV-6: Services Resource Flow Matrix, and the SvcV-10c: Services Event-Trace Description. All of these views depict resource flow exchanges between services. Which type of view is useful for what purpose?

References

Architecture and Infrastructure Committee, Federal Chief Information Officers Council (CIO Council). 2008. “Enabling the Mission: A Practical Guide to Federal Service Oriented Architecture, Version 1.1.” https://s3.amazonaws.com/sitesusa/wp-content/uploads/sites/1151/2016/10/Enabling-the-Mission-A-Practical-Guide-to-Federal-Service-Oriented-Architecture-1.pdf.

CIO Council. 2013. “Federal Enterprise Architecture Framework, Version 2.” https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf.

Department of Defense. 2009. DoDAF Architecture Framework Version 2.0, “Volume 2: Architectural Data and Models, Architect’s Guide.” http://bea.osd.mil/bea11/products/dodaf_volume_II.pdf.

DoD Information Enterprise Architecture. Retrieved 6/17/2018 from https://dodcio.defense.gov/IntheNews/DoDInformationEnterpriseArchitecture.aspx

Erl, Thomas. 2004. Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Upper Saddle River, NJ: Pearson Education/Prentice Hall.

Erl, Thomas. 2005. Service-Oriented Architecture: Concepts, Technology, and Design. Boston: Pearson Education.

Erl, Thomas. 2016. SOA: Principles of Service Design. Boston: Prentice Hall.

Gartner Research. IT Glossary. Retrieved 12/5/2017 from www.gartner.com/it-glossary.

Microsoft Corporation. “What Is PaaS? Platform as a Service.” Microsoft Azure web site. Retrieved 12/5/2017 from https://azure.microsoft.com/en-us/overview/what-is-paas.

The Open Group. “The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Architecture Contracts.” Retrieved 12/5/2017 from http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap43.html.