In-Depth

DOD Employs Primitives To Bring Enterprise Architectures into the Future

The DOD looks to a common vocabulary to help reduce cost of developing and maintaining systems. Plus a Q&A Dennis Wisnosky, the DOD's business mission area CTO and chief architect.

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.

Q&A with Dennis Wisnosky CTO of the Defense Department’s Business Transformation Agency

Dennis Wisnosky, chief technology officer of the Defense Department’s Business Transformation Agency, has been at the forefront of efforts to develop a unified vocabulary that will make it easier for business users to describe their requirements to systems architects and designers. With a better understanding of those requirements, designers and engineers can use best practices and basic building blocks known as Primitives, a common language and design patterns, to build the systems that users actually need, reducing costs, duplication and waste. But how do we understand Primitives and their role in building next-generation systems based on service-oriented architectures? ADTmag.com's sister publication GCN spoke recently with Wisnosky about the primordial origins of Primitives. -- Rutrell Yasin

GCN: What is this concept of Primitives?

Wisnosky: My background is in physics. As a physicist or chemist or scientist, we learn basic principles. And one of those principles is what things are made of. They are made up of elements. There are only 117 that we know of. With those 117 elements in the Periodic Table of Elements, we can make anything that we want to make or discover anything that God has made. Water is two hydrogens and one oxygen. That is pretty simple. We can’t get along without it. Air is only O (oxygen). Those are primitives, those are basic building blocks. We can subdivide them further for science purposes, but for all practical purposes in life, we get along with 117 elements.

How does this tie into enterprise architecture and service-oriented architecture?

In this business, [what] we call architecture [is] applied to business processes -- not applied to the kind of architecture we use to build buildings. We’ve allowed the practitioners of this art to build three or four architectures.

The same way you go to the Metropolitan Museum of Modern Art, you see modern art that is an abstraction of what is in someone’s head. It means nothing to anybody else, only to that artist. But it means nothing to me. Now you try to tell a story with the abstractions of several artists and those stories, again, are meaningless. Two different people wind up with five different stories. On the other hand, take a realist, a person who paints something we would recognize, like a house, maybe more than one story, but there would be agreement on the basic principles to describe this house, like a door, windows, for example.

So that is what I am talking about with respect to Primitives: getting the business process architectures so that they are described in a way that the meaning of this architecture, the business process that they described, is absolutely clear to the most number of people.

How did you get into this?

We were building a business enterprise architecture when the whole team changed because the contract [that the work was being performed under] was won by different people. It was a fair-and-square open competition. The company that had been doing this for five years didn’t win. The new company came in and, all of a sudden, their people had different ideas for how the architecture should be built. They wanted to rebuild it their way.

Their way might have been a good way, but we had already invested hundreds of millions of dollars in another way, and it seemed to be a wiser course of business action to get these new people to learn the old way. That is when I began thinking about why this is so hard. What if we had reduced the number of elements of our periodic table into some finite number that we can all agree with? Like what’s a box? What is an arrow? What is a joint? What is a decision?

I started to talk to the engineers that know this kind of stuff when I was giving talks. I set up some search for a solution like resistors and capacitors electrical engineers would use or like pumps and pipes a plumbing diagram might have on it. I talked about these concepts and [said] I don’t know what these things are going to be called; I suppose they are just Primitives. They are the smallest symbol we can use.

There is nothing smaller we can think of that can describe our business practices. But for all practical purposes, the Primitives are all that we need to build a model and these are business process models. So when we made that decision that we could describe Primitives, we started looking at [whether] they exist already. My answer was, hopefully, “Yes.”

Did they exist somewhere?

We didn’t have to reinvent them. Someone proposed Business Process Modeling Notation. I discovered there are several groups around the world who did extensive studies on BPMN and its underlying science, and they didn’t agree with one another. So we said stick with BPMN but look at the kind of models we build, and let’s limit the use of BPMN to those that we decided were necessary.

For example, we use helium in balloons, even though hydrogen is slightly better, but it has one problem: It explodes. So we throw away that hydrogen element and focus on helium. That is what we have done here with Primitives, we’ve thrown away those that are explosive and don’t work. We use only the ones that do work for us.

Most   Popular