Back to the beginning: Origins of Primitives in IT architecture

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? 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.