By Dennis Wisnosky, Chief Architect, Business Mission Area, U.S. Department of Defense
“The Department of Defense (DoD) is perhaps the largest and most complex organization in the world. It manages more than twice the budget of the world’s largest corporation, employs more people than the population of a third of the world’s countries, provides medical care for as many patients as the largest health management organization, and carries five hundred times the number of inventory items as the world’s largest commercial retail operation.”
—DoD Enterprise Transition Plan, September 2005
In 2005, the U.S. Congress passed the National Defense Authorization Act for FY2005 to modernize and streamline automated business systems within the DoD with the purpose of improving organizational agility and increasing the value of IT in general, while also reducing the historically escalating operational IT costs.
This legislation resulted in the creation of the Business Enterprise Architecture (BEA), which serves as the master blueprint for guiding and constraining the DoD’s investments in business systems. These investments total to approximately 53% of the DoD’s IT budget, roughly equivalent to the sum of the remainder of the budget for the entire U.S. Federal Government.
In 2006, the Business Mission Area (BMA) decided to plan and manage these investments via an architectural approach based upon SOA as a means of achieving modularity, interoperability, and the DoD’s overall goals of “net-centricity” and disciplined information sharing.
Note
Net-centricity is the realization of a networked environment that includes infrastructure, systems, processes, and people. Its purpose is to enable net-centric operations—a completely different approach to warfighting, intelligence, and business functions.
Through SOA, the DoD’s business IT solutions are being united via an infrastructure and standards-based pattern termed the Business Operating Environment (BOE). The other DoD mission areas (Warfighting, DoD Intelligence, and the Defense Information Environment) are following this same approach. As a result, many of the projects and inter-related sub-projects that drive these mission areas are fundamentally based on the development of services through SOA and service-orientation.
Due to the scale, complexity, and diversity faced by project teams when progressing with SOA adoption and roll-out efforts, the DoD developed a strategy with guiding principles that correlate with service-orientation design principles and with approaches that apply many established SOA design patterns. This strategy is represented by the BOE, and because it encompasses many SOA design patterns, it can therefore itself be considered compound pattern (Figure 24.1).
The emphasis of the BOE is to enable the incremental, phased adoption of SOA within DoD enterprise environments by framing individual service-oriented architecture implementations in support of the overarching business vision and supporting enterprise architectures. Within the BMA, it is intended as a key realization of the DoD’s vision for a Global Information Grid and to also integrate and leverage the DoD common SOA infrastructure by establishing a set of core enterprise services and standards to be used across all DoD Components (departments, divisions, organizations that comprise the DoD) and Mission Areas.
This framing approach essentially relies on the identification of the key parts and requirements of an effective service-oriented technology architecture implementation and then guides the development, acquisition, and incorporation of services across multiple business units within the overall enterprise. As such, it sets a model for various parts of the enterprise to follow as they transition to and standardize on service-orientation. The BOE defines and helps propagate a common shared vision of how IT enterprises create and deploy services, resulting in a target state whereby shifts in business and IT strategy can be accommodated at the speed of service composition.
Within the DoD, the BOE essentially establishes a modernized, services-based IT ecosystem.
The BOE is based upon a set of guiding principles formulated to keep the delivery of business capabilities aligned with the net-centric guidance of the DoD while providing support for business transformation. BOE guiding principles individually correspond and relate to a number of SOA design patterns, as well as the service-orientation principles (Figure 24.2) documented in Thomas Erl’s SOA Principles of Service Design.
The following sections highlight how BOE guiding principles relate to SOA design patterns and service-orientation design principles.
Note
To avoid confusion between BOE and service-orientation principles, BOE principles are referred to as “guiding principles” in the upcoming sections.
Information assurance relates specifically to information security. This guiding principle states that the development and application of the BOE will incorporate IA requirements as a core part of the DoD infrastructure and in conformance with pre-defined security standards and directives. Security patterns, such as Direct Authentication (656), Brokered Authentication (661), Data Confidentiality (641), and Data Origin Authentication (649), can play a key role in supporting the goals of this guiding principle.
Vendor neutrality and openness is advocated throughout a technology architecture and realized through the adherence to open standards for consistent system and data interoperability. This is supported by the Standardized Service Contract principle but can also be associated with service-orientation as a whole when it represents the standard paradigm for solution design.
In support of attaining the goals of DoD Business Transformation and carrying out various related activities (including those described in the DoD Net-Centric Data Strategy and the DoD Net-Centric Services Strategy), business data and services need to be easily located, understood, and reused by authorized users.
To follow this guiding principle, pre-defined protocols and other forms of standardization are applied to information sharing in general. While this is directly supported by the Standardized Service Contract, Service Discoverability, and Service Reusability principles, it also requires the successful application of patterns such as Canonical Schema (158), Contract Centralization (409), and Canonical Protocol (150) to ensure consistent interoperability.
When working with data from legacy repositories, common Service Broker (707) patterns, such as Data Model Transformation (681) and Protocol Bridging (687), may be further required. Also worth noting is that due to their utility-centric nature, data services are generally reliant upon the application of Utility Abstraction (168).
The BOE is very much focused on the creation of independent business services in support of the overall DoD SOA initiative (and building upon core infrastructure capabilities provided by the Defense Information Systems Agency). Its ultimate goal is to establish a “suite” of loosely coupled services and service-oriented solutions to automate cross-enterprise business processes.
While this is clearly aligned with the Service Loose Coupling design principle, it is also supported by the Service Autonomy principle due to the emphasis on establishing independent services that can be readily composed. Service Statelessness may also play a part in realizing the goals of this guiding principle when scalability issues arise.
Because the goal of establishing collections of loosely coupled services is foundational to service-oriented computing in general, this guiding principle can be supported by the application of most SOA design patterns.
Metadata repositories should be provided for business data asset and service producers so that such data sources can be registered and become visible to potential consumers. When associated with the discovery of data services this can relate to the Service Discoverability principle as well as Metadata Centralization (280).
Positioning data assets and services as authoritative sources of data relies upon the application of Official Endpoint (711), the compound pattern comprised of Logic Centralization (136) and Contract Centralization (409).
When following this guiding principle on a data architecture level, Schema Centralization (200) can become necessary to ensure that individual document schemas provide standardized representations of data sources as well as providing data service consumers with the means to understand the data provided.
Users and consumers are separated from technical and implementation details by requiring access to only the metadata describing the character and invocation interfaces of the services, as opposed to the underlying technology platforms and approaches used for implementation. This builds upon the search, discovery, and registry extensions established by the preceding guiding principle to create an environment wherein service implementations can be independently governed and evolved without impacting those that use and bind to them.
The Service Abstraction principle embodies the fundamental concepts of information hiding in support of these goals so that services are positioned as black boxes that can be subject to a variety of governance patterns, such as Service Refactoring (484) and Service Decomposition (489).
Open source software solutions will be viewed and used on an equal basis with regular commercial offerings, thereby enabling the DoD to leverage the cost savings and source code availability of open source software.
With the increasing amounts of services-centric open source projects, following this guiding principle opens the door to applying the Service Reusability and Service Composability principles in new ways by building pure open source or hybrid (open source plus commercial) service-oriented solutions.
For COTS product acquisitions to be considered, they must provide built-in support for standardized service interface contracts or for readily producing the same from COTS services that can be customized and pulled into existing service inventories, as per the policies and standards outlined as part of the BOE. A related aspect of this requirement is that COTS functions or capabilities that duplicate common functionality provided by the DoD and BMA enterprise services should be factored out in favor of invoking or using the DoD services.
This relates to several service-orientation principles, including Service Reusability, Service Composability, and Standardized Service Contract. To overcome limitations within (existing or new) COTS products, it may also be necessary to apply legacy-centric patterns, such as Legacy Wrapper (441) or any of the Service Broker (707) patterns.
Services produced by projects that follow the BOE approach are in compliance with the overarching DoD enterprise and can interoperate with existing services, such as the DoD enterprise services, regardless of tier.
Principles focused on repurposing services (such as Service Reusability, Service Discoverability, and Service Composability) are critical to achieving this goal, as are core design patterns associated with inter- and intra-inventory interoperability.
BOE technology and services should support a wide range of mobile and intermittently-connected devices. This requires that the Service Reusability principle be applied with different types of consumers in mind. Multi-Channel Endpoint (451) can directly address the requirements of this guiding principle, especially when legacy encapsulation is part of the overall service architecture.
As SOA adoption continues to grow throughout DoD Components (the Office of the Secretary of Defense, the DoD Services, the Combatant Commands, DoD Agencies and Field Activities, etc.), so does the awareness of service-orientation and the necessity for standards, patterns, and principles to be applied appropriately and consistently. In support of these objectives, the BOE remains the driving and guiding force behind the numerous SOA projects that are currently underway in the BMA.
There are numerous public documents available about the SOA initiatives at the U.S. Department of Defense. SOADoD.org is a new portal site dedicated to providing specifications, project descriptions, and other resources pertaining to the on-going SOA adoption effort at the DoD.
—Dennis Wisnosky, Chief Architect, Business Mission Area, U.S. Department of Defense