Principles and Patterns at the U.S. Department of Defense
Join the DZone community and get the full member experience.
Join For Free"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
Through SOA, the DoD's business IT solutions are being united via an
infrastructure and standards-based pattern termed the Business
Operating Environment (BOE). As a result, many of the projects and
interrelated sub-projects that drive these mission areas are
fundamentally based on the development of services through SOA and
service-orientation with the support of proven principles and patterns.
This article explores how the BOE relates to common SOA principles and
patterns.
The following article which is written by Dennis Wisnosky
is comprised of an excerpt from SOA Design
Patterns [REF-1] and references patterns published at SOAPatterns.org
[REF-2].
Introduction
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.
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 interrelated
sub-projects that drive these mission areas are fundamentally based on the
development of services through SOA and service-orientation.
The Business Operating Environment (BOE)
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 1: The BOE can be represented as a broad compound pattern encompassing SOA design and governance patterns, as well as a number of patterns specific to the DoD. |

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.

Principles, Patterns, and the BOE

![]() |
Figure 2: BOE guiding principles have a strong relationship with service-orientation principles and share many common goals. |

The following sections highlight how BOE guiding principles relate to SOA design patterns and service-orientation design principles.







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, Contract Centralization, and Canonical Protocol to ensure consistent interoperability.

When working with data from legacy repositories, common Service Broker patterns, such as Data Model Transformation and Protocol Bridging, 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.



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.



Positioning data assets and services as authoritative sources of data relies upon the application of Official Endpoint, the compound pattern comprised of Logic Centralization and Contract Centralization.

When following this guiding principle on a data architecture level, Schema Centralization 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.



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 and Service Decomposition.



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.



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 or any of the Service Broker patterns.



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.


The Future of SOA and the DoD
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.
SOADoD.org
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.
References
[REF-1] SOA Design Patterns, Thomas Erl et al., Prentice Hall, www.soapatterns.com
[REF-2] SOAPatterns.org Community Site, www.soapatterns.org
[REF-3] SOA Principles of Service Design, Thomas Erl, Prentice Hall, www.soabooks.com/psd/
This article was originally published in The SOA Magazine (www.soamag.com), a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" (www.soabooks.com). Copyright ©SOA Systems Inc. (www.soasystems.com)
Published at DZone with permission of Nitin Bharti. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments