DOD employs Primitives to bring enterprise architectures into the future

Using a common vocabulary could help reduce cost of developing and maintaining systems

When building an enterprise architecture, people must be able to effectively communicate so that information systems and services in development can talk to one another.

But the businesspeople who need the systems to do their jobs and the architects and engineers who design the systems lack a unified language that translates user requirements into a format that developers can understand.

Moreover, designers and engineers who specialize in design and development of specific aspects of architectures do not share best practices for how to communicate their plans with one another. For example, some are experts at defining business rules but not experienced in data modeling. That inhibits communication.

As result, they wind up developing systems that duplicate services and have propriety interfaces that can’t work easily with other systems.

The Defense Department’s Business Transformation Agency has worked on a solution to this problem through concepts called Primitives, Common Vocabulary and Design Patterns, said Dennis Wisnosky, DOD’s business mission area chief technical officer and chief architect at the Office of the Deputy Chief Management Officer.

“We started this a year and a half ago with only a couple of people,” Wisnosky said. “It has been a small effort, [but] it has grown with more people using Primitives as the DOD’s Business Enterprise Architecture is built.”

BEA 7.0 is slated for preview in March.

To illustrate the need for a unified language to build enterprise architectures, Wisnosky likes to use a music example. If an oboe player from the United States travels to Russia to play with a symphony, could he or she play with the Russian musicians even if he doesn’t know the language? Yes, because there is an common representation of music that allows a common understanding. The same is true in the world of electrical engineering — any engineer can read an electrical diagram because there are standard symbols for a resistor or capacitor.

“The problem is computers work with data and people work with information,” said Ed McCormack, an associate at Booz Allen Hamilton. “People will talk about a mailing address, but in a computer system, that piece of data might have various names in different places.”

The music example is the ultimate illustration of how a common vocabulary would work in a network-centric environment, McCormack said. “An A sharp is the same everywhere. You would be able to pass information and data simultaneously between different services.” And there wouldn’t be a need for mediation between an organization’s data architecture and business architecture.

However, that is the optimal stage, and both DOD and civilian agencies are working toward that goal, McCormack said.

Standard Formats

The Department of Defense Architecture Framework 2.0 is the foundation for architecture Primitives. Primitives are a standard set of viewing elements and associated symbols mapped to the framework's Meta-Model concepts and applied to viewing techniques.

Primitives provide standard formats for diagrams, data that represents the diagrams, and data that moves within and between the realities those diagrams represent, Wisnosky said. Primitives are elements of modeling techniques specific to a given perspective, such as a process model, data model or business rules model.

BTA is applying Primitives based on Business Process Modeling Notation, a graphical representation for specifying business processes in a workflow. The Object Management Group maintains BPMN.

The idea of Primitives fits nicely into service-oriented architecture, Wisnosky said. SOA represents the first time in the information technology world where it is clear how IT and business fit together, he said. So an SOA pattern made up of Primitives that are associated with business processes could execute those business processes with standard services.

“For example, ‘authenticate user’ is a standard service that is used in every single Web application,” he said. Under “authenticate user,” there are other standard services, such as “verify me” and “verify password,” Wisnosky said. “So, ‘authenticate user’ is a standard service that we would only have to write one time.”

“But what if this ‘authenticate user’ was described by me with a square, by you with a circle, and [by another designer] with a diamond?” Wisnosky asked. “We would have to explain what we meant by that and explain what it does.”

However, if "authenticate user" is the same symbol every single time, the software interpreting a model knows immediately to go to authentication services because those services are based on SOA standards internally.

“We know exactly what the payload of the information coming in must be, so we go to translate it, and we know exactly what has to go out to the next service,” Wisnosky said.

All businesses and government agencies have that problem, he said. “So this concept of Primitives applies to anyone building business process models or doing service-oriented architectures.”

Common Vocabulary

Another aspect of Primitives is a common vocabulary. DOD's multiple data environments inhibit sharing and reuse of applications and integrated user contribution.

“Once we started to do Primitives, which are the symbols and the meaning of the symbols, we began to discover different meanings of the words we use to describe these symbols and what the symbols are describing to the business processes,” Wisnosky said.

“We have a project called the Common Vocabulary Project — some might call it building ontology — to agree on the meaning of words that we use” he said. Two good examples are Social Security numbers and ZIP codes and the specific syntax for reading them. However, describing something more finite than a ZIP code, such as an address, poses more of a challenge because there are different interpretations.

Within DOD, the Business Enterprise Common Core Metadata Community of Interest is responsible for establishing a common vocabulary for terminology such as units of measure and purchase request numbers, he said.

Applying Primitives

Use cases that demonstrate how Primitives can be applied in real-world situations are being developed and will be used to drive pilot programs.

For example, Joint Close Air Support (JCAS) with Army Central Command in Kuwait is applying Primitives to aid in teaching personnel their part in the larger process of managed close air support. The unit also uses Primitives to automate the process as much as possible, Wisnosky said.

Close air support involves air action against hostile targets that are close to friendly forces. This requires detailed integration of each air mission with firepower and movement of those forces.

Primitives can help teach people because they describe a process flow model that is easier to read than instructions in a book, Wisnosky said.

For JCAS, applying Primitives and a common vocabulary simplified communication among domain experts, architects and modelers. In addition, it helps in the selection and development of services to support the electronic exchange of messages from system to system.

“We’ve been using Primitives to build scenarios for military training exercises; the scenarios have been defined by Primitives,” Wisnosky said. “We are using Primitives to model that process and beginning to exercise a model for teaching,” he said.

Wisnosky said the concept of Primitives resonates with every enterprise architect he talks with, both inside and outside DOD.

Office of Management and Budget officials involved with the development of the federal enterprise architecture for civilian agencies are looking at DOD’s work with interest.

“We are working with DOD and hope to bring these ideas into the broader [federal enterprise architecture] via potential integration into the Federal Segment Architecture Methodology,” an OMB official said.

BTA is looking to generate more interest in the concepts of Primitives and a unified language for enterprise architecture and SOA development at a SOA Symposium to be held April 21-22 in Crystal City in Arlington, Va.

Using architecture Primitives, “we will be able to greatly reduce the cost of building and maintaining of architectures and greatly reduce the cost of data transformation and mediation between systems,” Wisnosky said.

Reader Comments

Sun, Feb 14, 2010 Brand Niemann

Dennis Wisnosky has provided significant leadership in this area and since talked about this at the 5th SOA for E-Government Conference in May 2008 (see http://semanticommunity.wik.is/Federal_SOA_Community_of_Practice/Conferences/5_2008_April_30-May_1) and this is the key to doing "semantic SOA" and Linked open Data applications in support of the Open Government Directive and Data.gov/semantic

Thu, Jan 28, 2010

Using architecture Primitives, “we will be able to greatly reduce the cost of building and maintaining of architectures and greatly reduce the cost of data transformation and mediation between systems,” Wisnosky said. Here's a question for Mr. Wisnosky: Please remind us once again why it is so necessary and important to build "architectures" in the first place? Has any of the architecture work that has been going on in DOD for the last 14 years (i.e., since 1996, when the GAO somehow convinced the Congress to pass the Clinger-Cohen Act requiring everybody to start building "architectures") ever produced ANY measurable reduction in the cost of data "transformation and mediation" (whatever that phrase means). The DOD has spent many billions of dollars over the last 14 years trying to comply with "architecture" requirements in the Clinger-Cohen Act - to what end?

Thu, Jan 28, 2010

Base upon your article, do you know if all of DoD was or is being reviewed?

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above