DM Review Published in DM Review Online in August 2005.
Printed from

Enterprise Architecture: The Holistic View: The Role of Semantics in Business

by JP Morgenthal

I truly believe that semantics are the future of integration. It is one of the least understood areas of computing, but for those that have harnessed its power, it has yielded great returns and continues to do so. There is power in knowledge. When you understand the terms that your business uses to conduct business and you understand how those terms impact your business, you can see clearly how to support and maintain the processes that use those terms with minimal effort.

In my recent discussion with an OASIS ebSOA Technical Committee researcher, we discovered growing cognizance that capturing semantics is a critical first step before business process modeling can occur. Consequently, I have discussed this same approach to implementing enterprise information integration in my book and articles on the topic. Despite the differences in these problem domains - on one hand we are trying to solve the mapping of business processes across a vertical domain into a service-oriented architecture, while on the other we are trying to solve the problem of automating the creation of information from raw data - they both depend on a common abstraction, which is the creation of functional semantics.

The software industry as a whole seems to be migrating toward semantics like a flock of birds heading South for the winter. Slowly, I am beginning to see the term "semantics" being used in various disciplines, such as the Semantic Web, SOA, business intelligence, information integration and business process management. In all these contexts, the term seems to be used in a consistent manner - to represent the body of words used to describe the business.

Through these semantics we hide or abstract the underlying systems and data from the business processes. This abstraction provides us the agility and flexibility that is touted as a benefit of these technologies. Are these technologies really making our organizations more agile? Or, is the agility coming from the agreement and abstraction being defined by the semantics? Ultimately, I suppose, it is irrelevant which begets which, since it is the end result we are most interested in; but it is important to realize that the goal of BPM does not deliver agility without you first defining some level of abstraction for your data and systems.

Indeed, the rise of XML can be directly attributed to its ability to allow companies to capture semantics in simple manner that doesn't require expensive software or skills to utilize. Still, semantics has not yet cross "the great divisional divide," which is that virtual gap between business and technology that once widely understood grows in interest like a weed in an unkempt bed of grass. This means that the technical community has identified an agent that will greatly enhance the power and capabilities of the business systems, but it cannot get the funding to take advantage of this knowledge.

There is a process to capturing, categorizing and leveraging semantics in your organization, and it takes cooperation of both the business and technology staff. The following describes each of the processes and identifies the roles required.

Capture - In this phase of the process a representative for each business process establishes the vocabulary and their meanings required to support that process. For example, in a supply chain process the representative might capture words, such as buyer, transport or payment method. In addition to these words the representative would explain what these terms mean in relation to the process

Categorization - In this phase, the vocabularies across all processes are organized into a system. This requires cooperation of a knowledge engineering professional and the process representatives. The system can be a simple taxonomic structure that simply relates process to vocabulary, or it can be a more complex ontological structure that captures the relationships of words across processes. Needless to say, the latter is more expensive to create but will provide much greater value in the leverage phase. For example, it would be of great value to the company to understand that the "buyer" exists in procurement, sales, accounting, shipping and inventory processes. In a simple taxonomic structure, buyer will be listed redundantly and there will be no understanding that each of these buyers is the same entity. Thus, the taxonomic structure will most likely lead to a stovepiped use in the leverage phase, whereas the ontological structure illustrates a dependency upon one term that can be shared across many processes.

Leverage - This is phase where the technical staff implements the vocabularies in the form of a dictionary or registry. This dictionary can represent a simple lookup facility or it can become an active part of the infrastructure feeding the business rules and business process engines. With one of my clients, we designed each term in the dictionary to represent a Web service, thus yielding a simple method for using the term to retrieve the data from the underlying data stores. We also leveraged the ontological structure to return dependent items automatically.

I see many organizations putting significant dollars into business process reengineering efforts, which are yielding capture and redesign of business rules and business processes. These efforts are also yielding significant increases in productivity and cost reduction. However, most times, these benefits are not continual and reach saturation very quickly. For continual benefits, these efforts must yield an infrastructure that can be used to quickly drive new business processes, in addition to, redesigning inefficient ones. Starting with the semantics enables this to occur.

Additionally, if you start with capturing the business processes and business rules, you will eventually run across a rule that makes you backtrack and have to redevelop processes and rules you've already developed. In most cases, the semantic capture process follows the 80/20 rule in that 20 percent of your most heavily used processes will contain 80 percent of your vocabulary. Once these terms are mapped into an ontology you will be able to quickly identify the dependencies, which will lead to less redevelopment of your processes and rules downstream. Moreover, the rules and processes can be developed more quickly and by less technical staff if they have a palette of business terms to work with rather than a set of software functions.

Why should you undertake this effort? It will ultimately lead to greater agility and flexibility in your systems and lower costs of development. How? First you're starting with the needs of the business, which has become a key driver for systems development in the 21st century.

Want to attend an educational seminar that will provide you with a deep understanding of today's best practices in integration? The Leaders in Integration seminar is being presented October 11-12 at the Ritz-Carlton, Tysons Corner, VA. Hosted by JP Morgenthal of Avorcor and Beth Gold-Bernstein of ebizQ, this event will focus on EII, SOA and EAI from the development, deployment and management perspectives Visit for more information and to register. Seating is limited.

JP Morgenthal is managing partner for Avorcor, an IT consultancy that focuses on integration and legacy modernization. He is also author of Enterprise Information Integration: A Pragmatic Approach. Questions or comments regarding this article can be directed to JP via e-mail at Do you have and idea for a future Enterprise Architecture column? Send it to JP; and if it is used, you will win a free copy of his book.

Copyright 2007, SourceMedia and DM Review.