Business Semantics

Business Semantics

by Ken Orr, Fellow, Cutter Business Technology Council

For the most part, today’s information systems are not much more

intelligent now than they were 30 or even 20 years ago. Many

leading systems thinkers believe that the next big breakthrough will

come in getting software to recognize concepts at a higher level — to

deal with the meaning of things and not just their form. Classically,

the field of semantics deals with the study of meaning. This Executive

Report discusses business semantics categories and their importance

in shaping next-generation information systems.

Business Intelligence

Vol. 5, No. 7

http://www.cutter.com

About Cutter ConsortiumCutter Consortium is a truly unique IT advisory firm, comprising a group of morethan 100 internationally recognized experts who have come together to offercontent, consulting, and training to our clients. These experts are committed todelivering top-level, critical, and objective advice. They have done, and are doing,groundbreaking work in organizations worldwide, helping companies deal withissues in the core areas of software development and agile project management,enterprise architecture, business technology trends and strategies, enterprise riskmanagement, metrics, and sourcing.

Cutter offers a different value proposition than other IT research firms: We give youAccess to the Experts. You get practitioners’ points of view, derived from hands-onexperience with the same critical issues you are facing, not the perspective of a desk-bound analyst who can only make predictions and observations on what’shappening in the marketplace. With Cutter Consortium, you get the best practicesand lessons learned from the world’s leading experts; experts who are implementingthese techniques at companies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats includingcontent via online advisory services and journals, mentoring, workshops, training,and consulting. And by customizing our information products and training/consulting services, you get the solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for allenterprises, or all departments within one enterprise, or even all projects within adepartment. Cutter believes that the complexity of the business technology issuesconfronting corporations today demands multiple detailed perspectives from which acompany can view its opportunities and risks in order to make the right strategic andtactical decisions. The simplistic pronouncements other analyst firms make do nottake into account the unique situation of each organization. This is another reason topresent the several sides to each issue: to enable clients to determine the course ofaction that best fits their unique situation.

For more information, contact Cutter Consortium at +1 781 648 8700 [email protected].

Cutter Business Technology Council

Access to the

Experts

Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Lou Mazzucchelli Ed YourdonRob Austin


mailto:[email protected]

Semantics is the branch oflinguistics that studies mean-ing in language. One can dis-tinguish between the study ofthe meanings of words (lexi-cal semantics) and the studyof how the meaning of largerconstituents comes about(structural semantics).

Semantic role — whichis also called deep case,semantic relation, or thematicrole — is a description ofthe relationship that a con-stituent plays with respect tothe verb in the sentence. Thesubject of an active sentenceis often the agent or experi-encer. Other roles can beinstrumental, benefactive,or patient-based, such asthe following: Peter (experi-encer) died. The cat (agent)chased the dog (patient).

Sometimes it is hard to breakthrough the complexity of

language to get at reality. Even themost fundamental sciences areoften portrayed in mathematicalcomplexities that mask their trueobjective. The study of intelli-gence, for example, has becomea jumble of conflicting directions,down to the emergence of artifi-cial intelligence, which as far aswe can tell has almost nothing todo with real intelligence and agreat deal to do with mathematicsor symbolic logic.

So too with the idea of semantics.Semantics is, or ought to be, thestudy of meaning in language.Recently, however, semantics hasbecome yet another field ofabstraction delimited by mathe-matical expressions and conjec-ture. But real semantics shouldnot just be a mathematical repre-sentation; rather, it is about

classes of words and phrases(categories) that signify something— something in the real worldthat relates to other things in thereal world.

This Executive Report focuses onbusiness semantics, which is thestudy of meaning in businessesand, particularly, the study ofmeaning in business systems. Thisreport is the result of more thantwo decades of research andpractical application. Businesssemantics outline interactions thatlie at the base of most, if not all,information systems. If under-stood in the right context, thesemodels make it possible for busi-ness analysts, systems architects,requirements engineers, and sys-tems designers both to under-stand and to model the real worldwith a much higher degree of

by Ken Orr, Fellow, Cutter Business Technology Council

Business Semantics

BUSINESS INTELLIGENCEADVISORY SERVICEExecutive Report, Vol. 5, No. 7


VOL. 5, NO. 7 www.cutter.com

22 BUSINESS INTELLIGENCE ADVISORY SERVICE

The Business Intelligence Advisory Service Executive Report is published by Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA. Client Services: Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America, +1 800 888 1816; E-mail: [email protected]; Web site: www.cutter.com. Group Publisher: Chris Generali, E-mail: [email protected]. ManagingEditor: Cindy Swain, E-mail: [email protected]. Production Editor: Linda M. Dias, E-mail: [email protected]. ISSN: 1540-7403. ©2005 by CutterConsortium. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against the law.Reprints make an excellent training tool. For information about reprints and/or back issues, call +1 781 648 8700 or e-mail [email protected].

fidelity. Moreover, these modelsbring new insight into why certainorganizational, data, and proc-essing strategies reappear in everygeneration of systems whetherthey are manual or automated.

When I proposed this topic asthe subject of a Cutter ConsortiumExecutive Report, the editors wereconcerned that the informationmight overlap with recent similarlytitled recent work. I then reviewedseveral recent articles with thephrase “business semantics” inthe title. Fortunately — or unfortu-nately — I found little overlap. Thesubject of this report is, I think,closer to the original meaning ofthe word “semantics”: that is, thestudy of meaning. This report dis-cusses the meaning of things asapplied specifically to the businesssystems environment.

BUSINESS SEMANTICS AND THE REAL WORLD

Although business semantics isnot an oft-heard phrase, it is noless important because of its lackof use. It would be ideal if theterms of expression that weinclude under the heading of busi-ness semantics were all carefullyexpounded from the outset, butthat’s not the case. The terms andphrases used in this report are thedirect result of doing tasks andthen stepping back and trying tounderstand (1) what we have

done, (2) where and why we havebeen successful, and (3) the kindsof patterns present among themost successful examples. It’simportant to use definitions care-fully because their meaning canbe misconstrued.

From all our experience, we’velearned that words matter. Theright definitions can make all thedifference. We’re convinced, forexample, that the success ofenterprise architecture is in largepart derived from having the rightterms, diagrams, and sequence ofsteps. If you want to be success-ful, all these pieces have to fittogether. The more you use theright definitions, the easier it is tosee semantics come to life.

All business systems are about thereal world. That’s not to say, ofcourse, that technology doesn’tplay a major role. It is just that, inthe end, business systems areabout the business and the busi-ness environment. We talk hereabout actors, messages, subject/objects, and events because theyare most evident and significantwhen dealing with large-scalesystems. Moreover, they are whatmust be modeled correctly if youare to come up with the rightsystems architecture. The businesssemantics categories and con-cepts discussed here, then, aretaken not only from IT literature

but from business, economics,and systems feedback researchas well.

The Beginning of Semantics

Plato’s student Aristotleshifted the emphasis of phi-losophy from the nature ofknowledge to the less con-troversial, but more practicalproblem of representingknowledge. His monumentallife’s work resulted in anencyclopedic compilation ofthe knowledge of his day.But before he could compilethat knowledge, Aristotle hadto invent the words for repre-senting it. He established theinitial terminology anddefined the scope of logic,physics, metaphysics, biol-ogy, psychology, linguistics,politics, ethics, rhetoric, andeconomics.

— John Sowa,Knowledge Representation

When someone asks me forreferences on database design,systems modeling, or businesssemantics, I frequently recom-mend the Organon, Aristotle’s col-lected works on logic. This isn’t atrick; Aristotle really is the place tostart. Even after nearly 2,500 years,Aristotle’s writings on categories,propositions, syllogisms, and rea-soning have never really beenequaled, nor has the scope ofhis intellect. Countless fundamen-tal 21st-century words such as



mailto:[email protected]

“category,” “metaphor,” and“hypothesis” all come directlyfrom Aristotle — even the modernmeaning of “meta” is an intellec-tual inheritance that is directlytraceable to the philosopher.1

Aristotle’s work has been so influ-ential on our thinking and ourlanguage that it is difficult toframe a thorough discussionabout the meaning of things in thereal world and how to representthem in language without talkingabout his ideas.

In the Organon, Aristotle beginshis discussion about words andsentences (i.e., propositions) bydiscussing “categories.”2 ForAristotle, there were fundamentalcategories:

Substance

Quantity

Quality

Time

Place

Action

Passion

These categories allowed one totalk not just about sentences butalso about how to reason withsentences (propositions) throughsyllogisms. If you read modernbooks on semantics, you findmore formal, mathematicaldiscussions on meaning andreasoning, but they are all basedon Aristotle’s foundations. So,following Aristotle, we begin our

discussion of business semanticswith categories as well.

BUSINESS SEMANTICSCATEGORIES

Over the years, I have bouncedback and forth between describ-ing meaning and things in pictures(drawings) and describing themin words (text). I now recognizethat each method of descriptionhas its strengths and weaknesses.Pictures tap into the visual part ofour mind and allow us to repre-sent certain kinds of complexitythat are extremely difficult to rep-resent simply in words. But evenin drawings, the words includedare almost always vital. Text, onthe other hand, allows us to talkabout concepts in much greaterdepth and, in many cases, throughstories that are extremely difficultto put into pictures. Text allowsthe mind to draw its own pictures.

Like Aristotle’s Organon, businesssemantics is based on fundamen-tal categories or predicates. Themost important core categoriesare the following:

Actors

Messages

Subjects or objects

Locations

Events

From these, we can achieve yetanother set of more abstract,derived categories:

Business exchanges

Business processes

Business roles

Business process activities and decisions

User interfaces/formulas/decision rules

Business relationships

Business rules

Each of these derived categoriesis a configuration of the actors,messages, and so forth of thecore categories. In the followingsections, we describe both thecore categories and the derivedcategories.

We discovered the major corecategories (actors, messages,subjects/objects, locations, andevents) not theoretically but byanalyzing why a set of rathersimple drawings we now callcontext diagrams were soeffective in helping people tounderstand business systemsenvironments.3 Figure 1 showsa simple context diagram.

Context diagrams show only twokinds (or categories) of thingsexplicitly: actors and messages.When we first started usingthem, the idea was to representpeople, organizations, or systemscommunicating with otherpeople, organizations, or systemswith a minimum of other informa-tion. Actors are shown in context

©2005 CUTTER CONSORTIUM VOL. 5, NO. 6

EXECUTIVE REPORT 33

(Text continues on page 5.)



Pur

ch

as

e r

eq

ue

st

P.O

.

P.O.

Re

ce

ipt

no

tice

Pro

du

ct

pri

ce

s

Sa

les

Esti

mati

ng

Jo

b r

eq

ue

st

Pro

po

sa

l

Ord

er

Co

mp

lain

ts

De

live

ry d

ate

e

stim

ate

Pro

du

cti

on

Sch

ed

ulin

g

Pro

du

cti

on

Billin

g

A/R

& S

ale

s

Acco

un

tin

g

Re

ce

ivin

g

Pu

rch

asin

g

Pa

yro

ll

A/P

Ma

na

ge

me

nt

P/L

G/L

Syste

m

Pa

yro

ll c

he

cks

Fo

reca

st

Ord

er

Pro

du

cti

on

sch

ed

ule

Inve

nto

ry

sta

tus

Pro

du

cti

on

sch

ed

ule

Tim

e c

ard

s

Ma

teri

al

co

sts

Inve

nto

ry C

on

tro

l

Co

st

Acco

un

tin

g

Em

plo

ye

e

Ve

nd

or

Ve

nd

or

pa

ym

en

t

Pa

yro

ll j

ou

rna

l e

ntr

y (

j/e

)

Cu

st

inv j

/e

Pu

rch

asin

g j

/e

Ma

teri

al

j/e

G/L

re

po

rt

Ma

na

ge

me

nt

rep

ort

s

Ve

nd

or

sh

ipm

en

t

Inve

nto

ry s

tatu

s

Tim

e c

ard

s

Cu

sto

me

r p

aym

en

t j/

e

Invo

ice

Jo

b s

pe

cs

Customer shipment

Invoice

Cu

sto

me

r

Cu

sto

me

r p

aym

en

t

Cre

dit

s

Pro

du

cti

on

re

po

rt

Pro

du

cti

on

re

po

rt

P.O

.

Ve

nd

or

invo

ice

Figure 1 — A business (systems) context diagram.


diagrams by ovals, rectangles, orcircles. For us, messages arealways depicted with one-wayarrows.4 For each message in thisenvironment, there is a senderand a receiver. Naturally, thesender is at the beginning of thearrow; the receiver is at the end.5

Actors and messages have names.In the case of actors, these namesrepresent “individuals,” “organiza-tions,” or “systems”6; in the caseof messages, the names representthe particular “communication”that transpires between the twoactors.

Events and subjects/objects canbe discovered by analyzing con-text diagrams. Figure 2 shows alegend for reading, or analyzing,context diagrams and picking outthe actors, messages, subjects(objects), and events.

Core Categories

In this section, we examine ingreater detail each of the fiveindividual core categories intro-duced above.

Actors

In business semantics, actors —the entities that make things hap-pen — are especially important.This shouldn’t be at all surprisingsince, in natural language, ani-mate things (especially humanbeings) play an extraordinarilyimportant role. In everyday lifeand language, we are absorbedwith people. Phrases such as,

“The salesman said …” or “Theguard looked …” or “He intended…” comprise the bulk of our con-versation. This personalization ofmeaning in speech carries overinto our business and technologi-cal lives as well. When we refer toa large organization, we often usea phrase that begins with “they,”“we,” or even “it.” This propensityto anthropomorphize applies to allsorts of activities. For centuries,the law focused solely on “individ-uals” and “lords,” for example.Only over time did such collectiveabstractions such as “citizens,”“the crown,” and finally “corpora-tions” take shape as “legal per-sons” separate from individuals.

Today when we talk to usersabout business processes, peopleare still fundamental players. Inour everyday parlance, we switcheasily between “customer” and“Tom Smith” or between “vendor”and “Bill Jones.” If we are dis-cussing an organization, we mayrefer to Microsoft or to Bill Gates,who personifies Microsoft to theoutside world.

Individuals, organizations, andeven systems “do things”: that is,they act, which is, after all, whatmakes them actors. But they canalso be acted upon. In thisrespect, as we will see, they takeon the role of subjects or objectsof a conversation. Subjects orobjects don’t appear explicitly inthe context diagram, but they arethere implicitly.

Things that are acted upon aresubjects or objects (the appropri-ate word would be “passives,” butthat sounds awkward in modernEnglish). Most things that arepassive are inanimate (for exam-ple, products, services, parcelsof land, and so on), but someare individuals or classes of indi-viduals (possibly organizations orsystems as well) that are viewedas subjects or objects (for exam-ple, prisoners, wards of the state,etc.). We discuss subjects/objectsmore completely below.

In the business world, there aremajor subclasses of actors thatare particularly important: cus-tomers, vendors, employees,


EXECUTIVE REPORT 55

CCCCCCCC

Actors

Messages

Subjects

Events

Figure 2 — A legend for reading context diagrams.

(Text continued from page 3.)

managers, stockholders, and soon. In most enterprises, even pub-lic ones, customers are by far themost important subclass of actors,but vendors, employees, and thelike are a close second. In sportsfranchises and movies, for exam-ple, players or performers are thesingle greatest asset of the enter-prise. As it turns out, definingwhat we really mean by customer,vendor, and the like is one of themost difficult tasks in businesssystems.

Messages

In our everyday speech, messagesare also exceedingly important.We talk about sending a letter oran order to a person or an organi-zation; we talk about receiving an e-mail, a shipping notice, or con-firmation from a person or anorganization. Messages are alsoreferred to as transactions in awide variety of systems contexts.As we will see, messages — espe-cially structured ones — play afundamental role in almost all sys-tems: they are principal artifactsthat crop up in every generation ofbusiness systems.

Like actors, messages have a longhistory in both natural languageand business systems. Messagesdate back to the beginning ofrecorded history. As discussedhere, messages are always sentfrom an actor to another actorand are always about something.Over time, verbal or symbolicmessages (a handshake, forinstance) became artifacts, were

written down, and then finallybecame the basis for businessinteractions and ultimately busi-ness contracts.

The first documented businessesmessages were actually claybottles or containers called bulla,which contained tokens (alsomade of clay) that represented areal thing (cattle, sheep, etc.).These messages were discoveredin Mesopotamia and date back tothe 8th century BCE. These claybottles and tokens predate theearliest written script by thou-sands of years7 and were usedwhen transporting flocks from onelocation to another, representing akind of bill of lading. A bottle saidsomething like, “By this bottle, Isignify that I am sending you 24cattle.” When the receiver got thecattle, he broke open the bullaand counted the tokens that wereencased inside to check whetherhe had received what the senderintended (I don’t know how theyhandled cattle that died or thathad calves on the way).

But the clay bottles had a singulardrawback: you couldn’t see insidethem to count the number of cat-tle in the herd until you brokeopen the bottle. Over time, thisproblem was solved by pressingthe tokens onto the outside of thebottle while it was still wet, mak-ing an impression of each of thetokens that was placed inside.8

Finally, people discovered thatthey could dispense with thetokens inside the bottle entirelyand just send a tablet with the

impressions.9 Many students ofancient writing believe thatwritten language in the MiddleEast actually began with theintroduction of these basicaccounting messages and onlylater expanded to capture the fullrange of human experience; in astrange way, accounting may havebeen the mother of literature.

So the business message itself isa simple concept, but simple as itis, the business message hasserved as the fundamental basisof commerce since the beginningof civilization. These messageshave been used to convey infor-mation and possessions (such ascattle, goats, or bottles of wine).They formed the basis for theearliest accounting systems.Indeed, almost all the earliestexamples of written script dealtwith primitive or not-so-primitiveaccounting systems. Messageshave been used to report the mostmundane matters, but manypeople believe that they are thebasis of all civilized communities.

In business systems, the mostfundamental messages are com-munications such as orders, ship-ments, bills, and payments.10 Ofthese four fundamental messages,perhaps the most important is thebill — in the sense of an invoice— since it is the formal expressionof charges and of the change ofownership.11 But business systemsand the law involve many kinds ofbills: bills of exchange, bills of lad-ing, bills of materials, bills of par-ticulars, and so on. All these kinds




of bills are some kind of list.Indeed, lists of things represent alarge class of messages that areimportant in business systems andfor which there is a very commontemplate that shows up in all sortsof data models.

Business systems involve two pri-mary kinds of messages: externaland internal. External messagesare usually the most important inbusiness systems because theyrepresent the contracts betweenthe enterprise and its customers,vendors, or employees, or theyrepresent required outputs thatmust be produced for the systemto function.

Internal messages representcommunication between internalactors. Internal messages oftenrepresent key information trans-formations. For example, shippingnotices are external orderstransformed with added informa-tion about customer location,transportation information, andproduct information.

Messages are just information thatrepresents the communicationsbetween two actors. Businessmessages may take any numberof physical forms, including thefollowing:

Documents/forms

Letters

Packages

Electronic signals

Coded sequences

Voice or other kinds ofdocumented (or implied)communications

DNA or messenger RNA

The Package (Document) Metaphorfor Business Messages

Since everyone is familiar withpackages and letters, it’s a particu-larly useful metaphor for under-standing what we mean bybusiness messages. In fact, thewhole range of business seman-tics categories fits well with theidea of a package or letter: thesenders and receivers are actors,12

the package or letter itself is themessage, and the contents of thepackage or envelope (the letter)are the subject(s). Finally, the actof sending and receiving the pack-age or letter is a message-relatedevent (see Figure 3).

Notice how the package resem-bles the clay bottles that theancient Sumerians used 9,000years ago. On the outside it has

markings, on the inside it hasthings. Now, if I develop a docu-ment that represents the informa-tion about the package — itssource, destination, contents, andpickup and delivery times — Ihave what we might call a papershipping notice. It is not a stretchto see the shipping notice con-verted to electronic form, trans-mitted across the world, andused as a key electronic datainterchange.

In Figure 4, the business seman-tics shown in the package arenow depicted in the form of anelectronic message — that is, aninvoice.

The nature of the business seman-tics model, then, provides asimple but powerful way toclassify and model both dataand applications from an overallenterprise or business-unit view-point. As we will see, mostbusiness processes can be mod-eled as sequences of messages


EXECUTIVE REPORT 77

JimJim Jones Jones

123 ain

Toledo, OH

Bill Smith

Mason Hall

Lawrence, KS

Boston, MA

2004.05.10

Boston, MA

2004.05.10

Boston, MA

2004.05.10

Jim Jones

123 Main

Toledo, OH

Bill Smith

Mason Hall

Lawrence, KS

To: Actor

From: Actor

Contents: Subject(s)

Box/document: Message

Time stamp: Event

Figure 3 — The package metaphor.

and activities on those messagesthat create other messages.

From a systems semantic stand-point, actors and subjects(objects) are the stable things(i.e., customers, vendors, sales-people, and products) in thereal world that persist overrelatively long periods of time.Epistemologically, they exist inde-pendently of one another (i.e.,the existence of one actor, sub-ject, or object doesn’t dependon that of another actor, subject,or object).13

This makes actors and subjects(or objects) important in anyenterprise architecture or majorsystems design; but from a busi-ness systems standpoint, mes-sages are the glue that connect, orrelate, the major business seman-tics categories to one another.Figure 5, for example, graphicallyrepresents the information contextof business communication: actor1 (a customer) sends a message(an order) to actor 2 (an orderentry). (Note that an actor can bean individual, an organizationalunit, or a system.) This message isabout — that is, it refers to — a set

of subjects/objects (products). Atthe beginning, as featured on theleft side of the diagram, there is asending event (send order), and atthe end, on the right side, there isa receiving event (receive order).

In my context diagrams, messagesare the links connecting theactors, but they are also muchmore. Messages are the DNA ofbusiness systems: they contain thecommon structure of information(data structure, attributes, andlinks) that are the keys to data-base design. And as we saidpreviously, sequences (or threads)of messages provide the structureof our most important businessprocesses (see Figures 6a and6b). In fact, if you have a com-prehensive set of messages in abusiness context diagram, youalso have an enormous amountof the key structural informationrequired to understand yourbusiness processes.

None of this is accidental; it is inthe nature of the problem spaceand of business systems. In thesame sense that human anatomyis the basis of medicine, businesssemantics is the anatomy of busi-ness systems. Each generation ofsystems designers learns for itselfthe anatomy of systems. Thosedesigners who are capable oflooking at systems as a whole findthe same major pieces (actorsand subjects) and the sameconnectors (messages). And ifthey look a bit more closely, theybegin to see the events as well.Database designers perhaps see



Actor

(from)

Actor

(to)

Subjects

(products)

Message

(invoice)

Figure 4 — The document metaphor.

“Send order”

Customer

Product

Order Order

entry

“Receive order”

Figure 5 — The message as the key business semantics connection.


the structure of large systemsbetter than any other groupbecause they are fundamentallycharged with identifying thepieces and the relationshipswithin entire systems andbusiness areas.

So just like actors and subjects(objects), messages are importantin the domain of business seman-tics. From a data architectureand an application architecturestandpoint, messages — espe-cially major business transactions— provide the clearest and bestguide for making architecturalgroupings. By the time we’vecompleted our definitions, therole of business messages (i.e.,transactions) will be clear.

Subjects (or Objects)14

We have already introducedsubjects (or objects) duringour discussions of actors and

messages. As we’ve seen, a set ofcommon actors and messagesdefines a discussion or businessprocess. From a purely informa-tional standpoint, we could callthis a communication context orconversation. Typically a businesssystems conversation is aboutsomething. We call that some-thing a “subject” or “object.”15

The following is a list of sub-classes of subject:

Products

Services

Parcels of land

Jobs

Subjects (or objects) are relativelyeasy to identify once one under-stands that they almost alwaysexist as the basis of a businesssystems context. It is obviouslyeasier to pick them out whendealing with a physical subject

or object. It is more difficult whenworking with abstract kinds ofobjects. For example, if wewere looking to understand andimprove our firm’s employment/time reporting/payroll process,we might have trouble identifyingthe subject of the business con-versation. With experience inbusiness semantics, however,one comes to recognize that thesubject is the job or position thatthe employee holds.

Obviously, subjects or objects thatare individuals are essentiallyidentical to actors except for theirintent. While actors cause thingsto happen, subjects undergoactions, at least in the context ofthe given business system. Moretypical subjects are passivephysical things, such as products,buildings, ideas, and personalproperty. While actors typicallyhave names, subjects have


EXECUTIVE REPORT 99

Customer

Productsordered

OrderOrderentry

Productsentered

Entered orderCredit

manager

Productsapproved

Approved orderWarehouse

Productsshipped

Shipment

(shipped order)

Customer

Figure 6a — The sequence (or “thread”) of business messages (the enterprise view).

Customer

Productsordered

OrderOrderentry

Productsentered

Entered order Creditmanager

Productsapproved

Approved orderAccounting

Productsbilled

InvoiceCustomer

Payment

Productspaid for

Accounting

Figure 6b — The sequence (or “thread”) of business messages (the customer view).



numbers (IDs). When we explorethe data that is normally associ-ated with actors and subjects, wewill see that by knowing thesemantic category to which some-thing belongs, we also automati-cally know a whole range ofpossible attributes from whichwe can select. This is an impor-tant characteristic providing a richvocabulary with which to designapplications.

Locations

Things happen at specific loca-tions (or places). In an over-whelming number of businesssystems, geography plays a majorrole in operations and manage-ment. Technology and communi-cation have made distance lessand less of a problem. Today, anincreasing number of companiesare becoming first national andthen global players. The locationwhere something happens isnearly always important. Locationinformation is expressed asaddresses and, increasingly, asGPS coordinates. Even as distancebecomes less important, locationbecomes more important becauseit becomes easier to determine. Infact, with the advent of GPS sys-tems and wireless communica-tion, not only are fixed locationsan important category, but tran-sient or real-time locations are aswell. GPS coordinates are fastbecoming one of the commondenominators for integrating allsorts of data visually. Externalinformation based on physicallocation information is also one

of the fastest-growing sets of datapurchased by organizations fromthe outside.

Events, Time, and Change

Events are points in time thatrepresent simply either sendingor receiving a message.16 Eventsare characterized as the following:

Periodic (daily, weekly,monthly, etc.)

Aperiodic (ordering, receiving, etc.)

For the most part, the events thatyou can deduce from a contextdiagram are aperiodic, or random,events. The event occurs whenthe sender chooses to send themessage when the message hap-pens to arrive at the receiver’slocation.17 In real-time systems,aperiodic events are used tosynchronize processes.

The most common periodicevents that are of interest in thebusiness systems context arecalendar events, such as end ofthe day, end of the week, end ofthe month, end of the quarter, andend of the year. Because so muchbusiness reporting is associatedwith the calendar (standardand/or fiscal), periodic events playa big role in most systems envi-ronments. Where aperiodicevents have sources, periodicevents are driven by clocks andcalendars. Significant periodicevents are so common that theyare often embedded in coderather than in data.

Ultimately, business systems dotwo major things: (1) they helpactors (workers, professionals,and managers) within the enter-prise produce goods and services,and (2) they allow actors (man-agers, analysts, and professionals)within the enterprise to trackchanges in their business or thereal world over time. Monthly,quarterly, and annual reports helpmanagers, stockholders, and oth-ers understand the quality of theirproducts, how their products areselling, what their best customersare buying, how many hours theiremployees are working, and soon. These reports or graphs allowmanagers to control businessoperations: to hire new people,eliminate products, embark onnew marketing programs, and soon. While aperiodic events allowus to have real-time control overevents that need immediate cor-rection, periodic events allow usto provide long-term control.

Periodic events are simply mark-ers of time. Students of statisticsand mathematics will recall that ifwe want to track real change asopposed to noise, we need tounderstand the underlying fre-quency (rate of change) of thething we’re studying and sampleaccordingly.18 Much of the long-term information that an enter-prise needs does not reside withinthe enterprise or its internal sys-tems. For example, if we want tounderstand the market share ofour enterprise, we need informa-tion about our sales relative to thesales of our competitors.



EXECUTIVE REPORT 1111

The other major dichotomy withinevents like messages involveswhether the events originatewithin or outside the enterprise:that is, whether they are externalor internal.

External events are by definitionoutside the control of the enter-prise, whereas internal events aremore or less within the control ofthe business itself.19 As a conse-quence, external events, or exter-nally driven events, are typicallymuch more significant than areinternal ones.

As information systems becomemore complex and integrated,events (such as time and change)become increasingly importantas an element of business sem-antics. Capturing, updating,retrieving, and synchronizingevents are at the heart of allcomplex systems. Over time,sophisticated business managersand software engineers havecome up with elegantly simpleways of dealing with events, time,and change now that informationmust be captured and managedalong with the other more tradi-tional categories of data.

Derived Categories

As mentioned, actors, messages,subjects, locations, and events arethe core business semantics cate-gories. With these definitions inplace, it is possible to build a setof derived but equally importantsemantics categories, whichinclude business exchanges, busi-ness processes, business roles,

business process activities anddecisions, user interfaces andformulas, business relationships,and business rules.

Business Exchanges

A business exchange repre-sents a series of businessmessages flowing betweentwo actors that signifies abusiness transaction.

Previously we talked about theoldest form of business message:the clay bottle. Now we’re goingto discuss something even older:the original business transaction(i.e., the business exchange,which is a barter between twoparties).20 The earliest form ofcommerce involved two partiesexchanging something of equalvalue: “I give you a chicken,and you give me some salt,” or“I give you some salt, and you giveme a bolt of wool.” These werethe earliest and most elementaryof all business transactions. Inmany parts of the undevelopedworld, commerce is still carriedout this way. But for the most part,the world of commerce hasbecome more complicated and,at the same time, simpler. In abarter economy, traders have tokeep all sorts of ratios in mind:salt versus chickens, salt versusgoats, salt versus cattle, and soforth. Introducing money makesit easier, which is why it hasbecome the common denomina-tor of commerce. While majorbusiness interactions are stillabout trading something forsomething else, one side of the

equation usually involves money. Igive you money, and you give mea car, for example.

But even in the most sophisti-cated, money-denominatedeconomies, the original idea ofbartering is still instantiated incontract law. The key idea incontract law is “consideration,”where each party receives some-thing of value from the other. Evenwhere one party is truly givingsomething to another party, thegiver often receives a nominalamount in return so that the con-tract is valid (that is, both sidesreceive something of value).Indeed, the business exchange issuch a fundamental idea that itcrops up in today’s most sophisti-cated organizational thinking as away to define business processes.

Business Processes

A business process [is a]collection of related, struc-tured activities — a chainof events — that produce aspecific service or productfor a particular customer orcustomers.

— US GovernmentAccountability Office,

“Glossary of IT Investment Terms”

A business process is a sequenceof value-added activities per-formed by identified “roles” thatmaps a set of input messages intoa set of output messages in arepeatable fashion. At the mostfundamental level, businessprocesses are (or ought to be)

detailed maps of businessexchanges. We use a sales orderbusiness process as a principalexample because it representsa complete business exchange.The essential condition for atrue business exchange is thatthe main participants (or actors)must each get something out ofthe exchange. For a businessexchange to be complete in thecase of a sales order, for example,the enterprise and the customermust both get something out ofthe transaction, which they do:the customer gets products, andthe enterprise gets money.

Figure 7 shows a stream of actors,messages, and subjects that makeup a true business process. Thecustomer gets what he wants(the products he ordered), andthe enterprise gets what it wants(the money). If over the long haul,either side fails to get what itwants, of course, the processfails.21 Figures 6a and 6b ultimatelyprovide the basis for developingworkflow diagrams that areincreasingly used in business

systems analysis to documentbusiness processes.

Business process analysis involvesdocumenting what the businessprocess is today (the as-is model)and looking across the wholeprocess to see what activities canbe improved and what can beeliminated, as well as looking at itfrom the standpoint of both par-ties — in the sales order example,the parties are the enterprise (us)and the customer (them).

In large organizations, businessprocesses are too often defined insmall chunks (the order entryprocess or the invoicing process),which may correspond closelywith existing organizational func-tions but frequently don’t repre-sent entire business exchanges.We encourage these organizationsnot to set the scope of their busi-ness processing activities too earlyin their analysis; if they hold off,they will likely be able to viewtheir business process across amuch broader spectrum (i.e.,an entire business exchange).

But we recognize that someorganizations are constrainedand must choose smaller businessprocess activities. As a result, inmy classes and consulting withclients we frequently talk about“BP” — in uppercase letters — toindicate a business process basedon a business exchange, and “bp”— in lowercase letters — to repre-sent business processes builtbased on existing technology andorganizational structure.

Over the past 15 to 20 years, theimportance of business processeshas been increasingly recognized.Driven in part by the work of busi-ness researchers such as MichaelPorter and Geary Rummler, whopopularized the concept of busi-ness value chains and businessprocesses, respectively, organiza-tions came to learn that an enter-prise could be best understoodand measured in terms of its busi-ness processes. The more peopleunderstood the concept, the moreit became clear that businessescreated value only through theirbusiness processes.



Customer

Productsordered

OrderOrderEntry

Productsentered

Entered orderCredit

Manager

Productsapproved

Approved orderWarehouse

Productsshipped

Shipment

(shipped order)

Customer

Productsbilled

Productspaid for

Invoice PaymentAccountsreceivableCustomer

Accountsreceivable

Approvedorder

Figure 7 — A complete business exchange.


During the late 1980s and early1990s, the term “business processreengineering” became an ITbuzzword. Writers and consultantssuch as Michael Hammer, JamesChampy, and Tom Davenportbecame best-selling writers andspeakers if not household names.Business process reengineeringbegan as the idea of creatingwhole new paradigms for doingbusiness (starting with a blanksheet) but was quickly hijackedby management more interestedin downsizing staff or installingexpensive client-server applica-tions or COTS packages.

Over the past few years, businessprocess analysis has more or lessreturned to its original roots ofanalyzing and improving funda-mental business processes. Thishas been aided by the need fororganizations to move beyondtraditional cost cutting and seri-ously rethink their basic business.It has also been aided by theemergence of networks, the

Internet, and workflow manage-ment tools in automating signifi-cant portions of an organization’soperations. Paperless offices areincreasingly a reality, and once all(or most) of an organization’sinformation exists primarily indigital (electronic) form, thereis much greater flexibility inmanipulating that information.

Business Roles

A role [is] a function or part per-formed especially in a particularoperation or process <played amajor role in the negotiations>.

— Merriam-Webster Online Dictionary

From a business semantics stand-point, business processes are afundamental category. Clearlyunderstanding what businessprocesses are is key to developingthe right business solutions. By examining Figure 7, we cansee how business exchanges

are linked with the businesscontext information with whichwe started. It is a very short stepto convert these diagrams tobusiness process (swimlane)diagrams (see Figure 8).

As you can see, the business proc-ess diagram more or less retainsthe same messages that occurredin the business context diagram(see Figure 1) and changes thenames of many of the actors intothose of business roles. There isa subtle difference between rolesand actors. Depending on thecontext, actors typically take ondifferent roles. An individual, forexample, may in the sameday perform the role of mother,employee (at company 1), boardmember (at company 2), and vol-unteer (in a political campaign).

Actors and roles are easy to con-fuse — actors are individuals (e.g., Sam and Mary), organiza-tions (e.g., Royal Dutch/ShellGroup, Microsoft, and Toyota),



Customer

Customer service rep

Credit analyst

Sales approval clerk

Warehouse person

Billing clerk

Enter orderOrder

Check

credit

Allocate

goods

Ship goods

Bill

customer

Accept and

Process

payment

Entered

order

Approved

order

Shipping

notice

Billing

notice

Shipment

invoice

payment

Figure 8 — A business process (swimlane) diagram.

or systems (e.g., A/R, A/P, andERP); roles are “customer,” “man-ager,” “employee,” and so on.Natural languages like English orNorwegian tend to lump actorsand roles together. In Figure 8, the“customer” is both an actor and arole, so there’s no good reason tochange the name. In large organi-zations where there is enoughwork for people to specialize inspecific jobs, actor and rolenames are often the same; butin small organizations where indi-viduals have to wear many hats,the same individual may servemany roles. From a semanticspoint of view, the differencebetween actor and role is vitalto understand, since it can dra-matically simplify businessprocesses and avoid confusion.

In today’s advanced networkenvironments, it is common tohear network administrators talkabout “groups” and “roles,” sincethese are the items by whichsecurity is normally assigned.“Mary Jones,” for example, maybe assigned the role of “creditanalyst” and “sales approvalclerk” at the same time. Shemay also be temporarily assignedthe role of “credit manager” ifher boss is on vacation or anextended leave of absence.Increasingly, organizations aremoving to the concept of singlesign-on and, as a result, want asingle location where all of theroles that an individual has beenofficially assigned can be found toensure that only people with the

right security have access to sensi-tive data. The need for a carefuldefinition of roles becomes evenmore important as top managersincreasingly utilize workflow man-agement tools to electronicallyenable their key businessprocesses.

From a competitive standpoint,business processes are critical.One only has to look at the suc-cess of companies like Dell to seethe impact of having a superiorbusiness process in terms ofbecoming the lowest-cost,most adaptable producer in ahigh-tech market.

Business Process Activitiesand Decisions

[An] activity [is] a namedprocess, function, or task thatoccurs over time and has rec-ognizable results.

— US GovernmentAccountability Office,

“Glossary of IT Investment Terms”

Business process activities repre-sent a unit of work done by agiven role at a given point in abusiness process. Business proc-ess activities can be thought ofas functions that take inputs andproduce outputs. An activity canbe either a primitive activity or asubprocess. Subprocesses aredefined as components of activi-ties that are too complex to bedescribed in a single statementor program. A business processmay require another more

detailed swimlane diagram todescribe its subprocesses indetail. A primitive activity canbe described in terms of a userinterface (a report, screen, etc.)a set of business rules, and a setof data.

In Figure 9, “enter order,” “checkcredit,” and “allocate goods” areall activities. Depending on thebusiness context, all these activi-ties could be primitive, while inother contexts, “enter order”might be a primitive activity, and“check credit” and “allocategoods” might be subprocesses.

The principal characteristic ofan activity within a businessprocess is that it has specificinputs, specific business rules,and specific outputs and can bedone by a specific role underspecific circumstances. In thisregard, activities look and act likewell-behaved modules in a classicmodular design. In recent years,there has been increasing interestin services and service-orientedarchitectures (SOAs). To a highdegree, activities look and act likeservices in this new SOA world.22

Represented in business processdiagrams as diamonds, decisionsallow for explicit definitions ofalternative business flows basedon different conditions. At base,business process diagrams arereally just traditional flowchartswith additions that allow forconcurrent activities andsynchronization.




User Interfaces and Formulas

User interfaces are the ports withwhich users view an informationsystem. User interfaces are theproducts that information systemsprovide and the only externalpoint of contact between usersand the system. Business seman-tics suggests that user interfacesbe closely aligned with useractivities. In user interface design,one of the best ways to define ascreen or report is to ask, “What’sthe best way to present this infor-mation so a user can use theinformation most effectively?”

There are two primary things onan output or a screen: variablesand labels of the variables. If anoutput is difficult to understand,it is probably a bad output. Byand large, business analysts anddevelopers often gloss over theimportance of good user interfacedesign in their rush to capture the

“real” requirements. But useroutputs and inputs are the realrequirements. They are the onlythings that a user actually seesand therefore are of enormousimportance.

Business systems capture, store,retrieve, and present informationabout the real world, and that realworld consists of those actors,messages, subjects, locations, andevents that constitute the systemitself over time. Business seman-tics suggests that actors (cus-tomers) and subjects (products)are independent of one another.Coupled with experience, the can-cellation suggests in most salesorder systems that managementis going to want to look at whichcustomer bought which productsin which regions and whichproducts were purchased bywhich classes of customers inwhich region.

Business Relationships

A good deal has been writtenabout customer relationshipmanagement (CRM). The idea ofCRM is to capture and understandmore about customers over time.But much of the CRM literature ishighly one-sided. It focuses toomuch on the enterprise’s knowl-edge of and control over thecustomer and too little on thecustomer’s context and needs.In business semantics, we takea broader view of businessrelationships:

A business relationship com-prises all of a major actor’s busi-ness exchanges (transactions)(e.g., a customer, vendor, businesspartner, employee, etc.) with anenterprise.

This definition of CRM makesmuch more sense than traditionalones,23 because it highlightshow the customer perceives the



Customer

Customer service rep

Credit analyst

Sales approval clerk

Enter order

Check

credit

Allocate

goods

Order

Entered order

Approved

order

Preapproved orderYesPreapproved?

No

Figure 9 — Activities and decisions within a swimlane diagram.

enterprise as well as how theenterprise perceives the customer.Oftentimes, organizations treattheir interactions with their cus-tomers and vendors as thougheach individual message or actionwere separate and unconnectedto the others. So, for example, anauto insurer might not hesitate tocancel a customer’s policy after acouple years of accidents causedby the customer’s teenage daugh-ters. But the customer might see itas the insurance company ignor-ing a 20-year relationship withvery few claims, especially oncethe teenage daughters graduateand go out on their own. This can-cellation might make perfectsense from the standpoint of theinsurance company looking atone- (or two-) year profit-and-lossfigures, but it tends to ignore thelong-term relationship. While theenterprise may think nothing ofcanceling a customer’s policybased on one or two years of badexperiences, customers remem-ber bad experiences for a verylong time.

In my use of the term here,business relationships are at thesame time enormously importantand enormously difficult for mostlarge organizations, which haveseparate systems to handle dif-ferent business messages (ortransactions) for different lines ofbusiness. In many cases, thesedifferent systems identify thesame actor (or customer) differ-ently. Because of this, it is oftendifficult to relate the informationfrom one system to another. This

is the problem that data ware-housing was designed to solve.But even with the best tools, dataquality is still a significant issue.

Large organizations make hugeinvestments in legacy systemsand for this reason are reluctantto replace them or merge theminto one system. However, whenlooked at from the perspectiveof a long-term business relation-ship, the cost of a major integra-tion process may have high payoffwithin a relatively short periodof time.

Business Rules

Business rules are the last andmost difficult element of businesssystems. From a semantics stand-point, a business rule may involvereferences to all the other seman-tics categories. Some businessrules determine eligibility, calcu-late royalty formulas, determinefrequent-flyer miles, and so on.Whereas there are elegantly sim-ple mechanisms for the automaticdesign of normalized databasesand workflow networks, no suchtechnique has yet been devisedfor business rules. Still, businessrules deserve their own semanticscategory because of their overallimportance to business systems.

Indeed, one of the most difficultthings about replacing aginglegacy systems is their embeddedbusiness rules. Complex businessrules often come into beingover long periods of time, and

their documentation is problem-atic, at best.

THE IMPACT OF BUSINESSSEMANTICS ON DATA ANDSYSTEMS ARCHITECTURE

So now that we have a set of busi-ness semantics categories, herecomes the fun part: using thesemantics categories to build“smarter” business, data, andapplication architectures.Business semantics can tell us agreat deal about how businesssystems should be architected.Business semantics provides soft-ware architects and designerswith a set of templates that helpsthem quickly determine the over-all framework of their systems,even their enterprise databasesand applications. During the late1970s, those of us involved inwhat is now called the datastructure design group gainedthis insight.

During this period, I observed thatsystems and databases tended tofall into distinct patterns based onwhat we now call their actors,messages, and subjects. Actorssuch as customers or vendors, forexample, tended to be modeledas tables with unique keys. Thiswas also the case for most sub-jects, such as products. Messages,on the other hand, tended to havea more complex model. As wewill see, messages have twomajor components and are mod-eled via a combination of uniqueand foreign keys. But even thoughtheir nature makes them morecomplex, messages tend to be




modeled more or less the sameway all the time.

Data Modeling and DataArchitecture

A well-designed, normalized data-base for large business systemsoften contains 200 or more datatables. Of these, my experiencehas been that only about 10%(roughly 20 tables) are critical tothe system design. The remainderare largely interface and referencetables. In my experience, if youget the top 10% right, everythingworks well. With insights gainedfrom my business semanticswork, getting the top 10% rightis a manageable task.

Modeling Actors, Subjects, and Messages

The first thing to understand aboutactors (individuals, organizations,and systems) is that in the realworld, they exist independently ofone another. This is what philoso-phers call “ontological” indepen-dence. Customers, for example,are independent of one another. Imay physically inherit genes frommy parents, but after a certainage, I don’t physically depend onthem for my existence.

Things in the real world that areindependent of one another oughtto be modeled as independententities or classes in correspond-ing business systems models. IfFrank Jones and Frank Smith areseparate customers, they need tobe assigned different identificationnumbers and have their attributes

collected and updated indepen-dently as well.

The same holds true for the sub-ject (objects) category. Subjectsare independent things; they areindividual products (such ashammers, wrenches, or screw-drivers), so they should haveunique identification numbers aswell. Historically, only expensiveproducts such as cars and com-puters and television sets havehad truly unique IDs (i.e., serialnumbers). But with the emer-gence of radio frequency identifi-cation (RFID) technology, the dayis coming when nearly every pro-duced product will have its ownunique ID, and our business sys-tems will need to be prepared tomodel billions of unique IDs andcapture a whole range of newinformation about that productincluding, perhaps, current loca-tion and status. The bottom line isthat from a business semantics

standpoint, actors and subjectsare modeled in simple tables withunique IDs (see Figure 10).

The fundamental data model ofmessages (transactions) is only abit more complex than the datamodels for actors and subjects. Ingeneral, there are two parts to amessage: a message header andmessage line item. Figure 11shows a typical message datastructure.

The actor, subject, and messagedata models are the buildingblocks for most major businesssystems (we’ll address event/timeand location information later). Ina sense, actors and subjects rep-resent the nouns of our businesssemantics sentences (proposi-tions), and messages representthe verbs. With them, we canconstruct the basic model fora business communication.



Figure 10 — Actor and subject data models.

Customer Product

Customer No*

Customer Name

Customer Address

Customer City

Customer State

Customer ZIP

Product No*

Product Serial No*

Product Desc

Product UM

Product Price

Modeling Business Communications

Modeling messages is the key toreal-world database design.Messages provide links that pro-vide the structure of the key busi-ness processes, which in turn

provide the structure for ourbusiness systems.

These assertions take some expla-nation. Referring back to the con-text diagram in Figure 1, we can

ask and answer the followingquestions:

Q: How were the actorsconnected?

A: Through messages.

Q: What did the subject (orobject) hang off of?

A: The messages.

Q: How are the actors and sub-jects connected within a datamodel based on solid businesssemantics?

A: Through the messages.

It all makes sense. Business sys-tems are fundamentally modelsof real-world communicationsystems, and in communicationsystems the connection linksoccur through the messages. Inbusiness systems, actors andsubjects are related via messages.Figure 12 shows the structure ofa traditional data model for abusiness communication (in thiscase, an invoice).

After creating hundreds of datamodels with nearly identicalstructures, it occurred to me thatthere had to be a common under-lying pattern. As I reviewed therelationship between these mod-els and the business context andbusiness process models createdfor dozens of projects, it becameclear that a fundamental businesssemantics was being represented.

The basic pattern for businesscommunication has become abusiness semantics template that



Figure 11 — A typical message data model.

Acme Manufacturing

Invoice

Invoice Header

Invoice No*

Invoice Date

Order No

Order Date

Customer No

Customer Name

Invoice Line

Product No*

Product Desc

Quantity Order

Product Price

Extended Price

Figure 12 — The data model of a business communication.

Actor Message Subject

CustomerCustomer No*

Customer ZIPCustomer StateCustomer CityCustomer AddressCustomer Name

Invoice HeaderInvoice No*

Customer NameCustomer NoOrder DateOrder NoInvoice Date

ProductProduct No*

Product PriceProduct UMProduct DescProduct Serial No*

Invoice LineOrder No*

Extended PriceProduct PriceQuantity OrderProduct DescProduct No*


recurs repeatedly in all businesssystems. Here the names of theactors, subjects, and messagescan be thought of as variables ina mathematical sense. And likevariables in mathematical equa-tions, if we substitute one or morevariables consistently in our tem-plate, we get another well-formedmodel. For example, if we substi-tute “vendor” for “customer,”“purchase order” for “order,” and“vendor product” for “product,”we have a common data modelfor a “purchasing” as opposed toa “sales order” business process.

WHAT IS BUSINESS SEMANTICS GOOD FOR?

Many people are afraid of theory.When you use words like “seman-tics” or “ontology” or “taxonomy,”their eyes start to glaze over. Butthey are just words; they onlystump us because we don’t usethem very often. This time, theunusual words and the businesssemantics theory are on our side.Like any good theory, businesssemantics has lots of practicalapplications. For example, youcan use business semantics todevelop a solid enterprise dataarchitecture, to help you designyour core data warehouse, or tocome up with a high-level applica-tion architecture. In fact, you canuse this basic set of ideas to domany things. In this section, we’regoing to discuss the major usesthat result directly from our under-standing of the business seman-tics model.

Enterprise Data Architecture

Templates are great for designingcomplex things. They allow us,for example, to model any<actor><message><sub-ject><actor> relationship, andany business system involvesmany of these relationships sincemessages are the threads fromwhich the foundation of oursystems is created. In the sameway that we used messages tohelp us structure our businessprocesses (see Figures 6a and6b), this communication-basedtemplate can be leveraged tobuild complex data architecturesas well. Figure 13, for example, isa high-level enterprise data archi-tecture for a printing companybased on the repeated use of thisbasic template.

Note that in Figure 13, we haveused the business communicationtemplate seven different times,reflecting the seven major mes-sages that are included withinthis basic market-to-collectionbusiness process. Here the sevenmajor messages (job request,proposal, contract, work order,shipment, invoice, and payment)lead us to an understanding ofthe basic data architecture of alarge part of the organization. Bystarting with a business contextmodel and coming to understandthe basic messages and basicbusiness process flow, we notonly develop a better data modelbut tie it back visually andlogically to the context andbusiness process models that

we developed earlier (Figures 1and 8, respectively).

It always helps to have a soliddiscipline like these businesssemantics templates when tack-ling big (i.e., new/risky) problems.Engineers, for example, alreadyhave a great deal of knowledgeabout buildings and roads beforethey construct a new building ona steep hillside or a new bridgeover a particularly tricky geologi-cal terrain. Like great architects,great business analysts need allthe breaks they can get. LikeFigure 12, Figure 13 is a template,but it is higher level. Good engi-neers and architects take advan-tage of templates or tools likeCAD/CAM to do more and morecomplex things. If we start anew project with a template, thenwe have a distinct advantage.Figure 14 (on page 21) takesFigure 13 further and showsexactly where the major businesscomponents go.

All experienced modelers, espe-cially good ones, use mental tem-plates from previous projects. Inmost cases, the templates comebefore the insight into the under-lying reasons. As I often tell peo-ple, we frequently know whatworks long before we know why.This is certainly true about busi-ness semantics. The key founda-tion ideas behind this kind ofthinking are based on the workof a number of different peoplegoing back more than 30 years.Several of my colleagues and I



worked on data models beforethere was even an agreed-uponrelational database theory.

In the 1970s, my late friend Jean-Dominique Warnier published thebook Logical Construction ofSystems.24 The book provided theearliest enterprise data architec-ture of which I am aware. And ittoo was based on lots of experi-ence as well as theory. When Ivisited Warnier in the late 1970s,he took me to a client whoalready had a real-world enter-prise data architecture in placeand a real, live enterprise dataarchitect on the job (whose

official title was logical dataengineer).

Although I didn’t completelyunderstand Warnier’s enterprisedata architecture model at thetime, it was clear that there wassomething profound about hiswork in modeling both the enter-prise’s data and the enterprise’sapplications. Years later, I came torealize that Warnier was buildingan enterprise data architecturebased on what we now call busi-ness semantics modeling. Notsurprisingly, then, one of the firstplaces that most people use busi-

ness semantics is in modelingtheir enterprise data.

Designing a Core Data Warehouse

A great deal of the theory behindbusiness semantics also emergedas a result of understandinghow to make data warehousingwork. I was introduced to datawarehousing during the late 1980swhen I consulted for IBM. Adevelopment manager took measide and asked me to look at anew concept that was in devel-opment. So I read some articles,talked to some of the researchersworking in this area, and lookedat some early product demos.



Customer

Job request

Job request 1

Proposal

Proposal

item

Contract

Contract

item

Shipment Payment

Product

Invoice

Invoice

item

Work

order

Work

item

Shipment

item

Work

station

Material

Equipment

Payment

item

Employee

Figure 13 — Enterprise data architecture for a printing company.


After I studied the material, I toldthe development manager that Ithought data warehousing wasindeed an exciting concept andthat I suspected many of hisclients had been working onthe problem for quite a while.Moreover, I reckoned that if IBMhad actually come up withsomething truly new and useful,its clients and others would bevery interested.

This territory was so familiarbecause one of my first bigprojects was an early data ware-housing application. That projecthad some bad moments, so I wasacutely aware of how difficult it

is to execute these systems. In thisproject, we had to integrate a lotof data, produce dozens of reportsin different sequences, and sup-port truly ad hoc reporting for anumber of different user groups.On top of all this, we wereattempting these things longbefore many of the necessaryend-user tools were available.

During the past 15 years or so, Ihave worked on more and moredata warehousing and businessintelligence assignments. In theprocess, I developed a frameworkthat I refer to as an enterprise dataflow architecture (EDFA), which isillustrated in Figure 15. I came up

with the architecture becausethere were several competingtheories about how best to dodata warehousing, particularlyregarding the difference betweendata warehouses and data marts.As I explored the problem, Icame to the conclusion that arobust data warehousing strategyneeded to include both a coredata warehouse (CDW) as well asseveral data marts.

The EDFA addressed the datawarehouse versus data martissue by including both, but itemphasized the data warehousecomponent. Indeed, the key ele-ment of the data warehousing



Figure 14 — Mapping business semantics categories to an enterprise data architecture.

Customer

Job request

Job request 1

Proposal

Proposal

item

Contract

Contract

item

Shipment PaymentInvoice

Invoice

item

Work

order

Work

item

Shipment

item

Work

station

Material

Equipment

Payment

item

Employee

Actors

Messages

Subjects

Product

framework is the middle “coreDW layer” in Figure 15. The coredata warehouse is the centralclearinghouse for all informationin the warehouse. All the ele-ments on the right side of theCDW are involved with extracting,cleaning up, and integrating datafor loading into the CDW, while allthe elements on the left side areinvolved in indexing, searching,retrieving, and presenting data,either directly or via data martsor data cubes.

From my standpoint, then, thedesign of the core data ware-house is critical. In addition tothe issue of data warehouses ver-sus data marts, the other majordesign issue concerns whetherthe core data warehouse shouldcontain atomic transaction data oronly summary data. Historically, end-user reporting applicationsrelied heavily on summary data, in

large part because of storage andperformance reasons. But myanalysis indicated that since thecost per byte was plummeting,storage costs were less of a prob-lem. I also concluded that for thesake of flexibility, to answer adhoc queries and because of theneed to relate summary data backto detail transactions, a CDWought to contain both atomic andsummary data and focus on theatomic data (see Figure 16).

As you can see, even the layout ofour CDW leverages our businesssemantics categories. In datawarehousing parlance, there hasbeen a great deal of discussionabout “facts” and “dimensions.”As it turns out, facts are nearlyalways related to messages (trans-actions), while dimensions tend tobe related to either actors or sub-jects (objects). As a result, wehave been able to quickly help

people come up with sound datawarehouse designs based onsound business semantics. Theapproach is (1) to work backwardfrom the most likely outputs orquery sets to the minimal dataneeded to produce those outputsand then (2) to relate that infor-mation to the actors, messages,subjects, and business process ofthe supporting business.25

Even after nearly two decades,data warehousing is still confusingto many end users and even toa fair number of database design-ers and developers. This shouldn’tbe. We find that the use of aconsistent business semanticsnomenclature throughout theprocess helps business users andIT developers do a better job ofcommunicating and understand-ing the nature of their businessand their data. Talking to businessusers about actors, messages, and



Figure 15 — Enterprise data flow architecture.

Internalusers

Externalusers

Internal opsproviders

Externalproviders

Internalnon-opsproviders

Virtual DW

Coarse DW

Central DW

Distributed DW

Direct queries

Virtual queries

Ad hoc queries

Presentation/desktopaccesslayer

Datamartlayer

Data feed/data mining/

indexing layer

Core DW layer

Data stagingand quality

layer

Dataaccesslayer

Operational datalayer

External datalayer

Non-operationaldatalayer

Metadata repository layer

Warehouse management layer

Applications messaging (transport) layer

Internet/intranet layer

1 4 6

8

9

10

3

5 7

2a

2b

2c

11


subjects in the context of datawarehousing takes a bit moretime, but once the concepts takehold, it’s much easier for peopleto see how all their systems anddata relate to the important thingsin their world.

Application Architecture

Form ever follows function.

— Architect Louis Sullivan

Clearly, business semantics helpsin rationalizing our business anddata architectures, but it hassignificant uses in applicationarchitecture as well, especially atthe highest levels. As the outlineof business semantics becameclearer in the late 1980s, we

began to see that these samebasic semantics categories werevisible even in our highest-levelsystems thinking.

If you look at any account (finan-cial) software, for example, youwill invariably find a set of primarycomponents: accounts receivable(A/R), accounts payable (A/P),payroll, and general ledger (G/L);and if you are a manufacturer,there will also be an internal cost transfer component (C/T).Paralleling these accountingprocesses is a matching setof business (operational)components as well: sales, pur-chasing, human resources (HR),executive management, and man-ufacturing (see Table 1).

What is perhaps most surprising ishow constant these functions arefrom a systems, accounting, andeven an organizational standpoint.As far as we can determine, thisframework of business accountingand operations domains wasaround long before computersand hasn’t changed materiallyover time. I believe that’s becausethe designation of these areasarose out of a trial-and-error dis-covery of which accounting/management structures workedbest in the real world and that thisstructure became a fundamentalpart of accounting. Figure 17 por-trays this observation graphically.

The reason that A/R (sales), A/P(purchasing), payroll (HR), and



Figure 16 — Layout of a core data warehouse.

Invoice Line

Customer Product

InvoiceHeader

Actors Objects

Dimensional Data Message (Transactional) Data

Base (Atomic)

Data

Summary/HierarchicalData

Monthly Sales (Current Year)

‡

Summary Messages (Fact Tables)

Region

Territory

ProductFamily

ProductClass

Company Company

cost transfer (manufacturing) —all the italicized elements inFigure 17 — work as major appli-cation areas is that they eachdeal with a group of closelyrelated things: a single majorexternal actor, a major set ofexternal messages (transactions),and a major external subject(object). In a way, each of these

systems is both productive (i.e.,it produces something of value)and canonical (i.e., it is sym-metrical). Clearly, we are not thefirst to stumble on this insight.For example, J.D. Warnier builthis entire systems/data/organiza-tional architecture on the conceptof just four canonical messages(orders, deliveries, bills, and

payments). He believed that justas there was a logical way to builddatabases and applications, therewas also a logical way to organizebusinesses.

If you look at organizations froma bottom-up perspective, the bigpicture is often hard to grasp, butif you view the big picture from atop-down perspective in the rightway, powerful patterns begin tojump out. For decades, IT haspursued reuse; business seman-tics starts with the idea of reusingthe most important categories —the things at the top that are moststable. By leveraging (that is,reusing) the patterns that comefrom business semantics, thewhole world of services takes onnew meaning.

THING 1/THING 2 THEORY:ENTITIES, OBJECTS, ANDBUSINESS SEMANTICS

For at least 2,500 years, thesearch for the right way to thinkand talk about things has been apreoccupation. Philosophers, the-ologians, biologists, psychologists,linguists, and now computer sci-entists have attempted to makesense out of the real world — onemight suppose — since the begin-ning of civilization. If our form ofbusiness semantics is to proveuseful, it is important going for-ward to relate these businesssemantics categories with themost powerful trends in IT thathave come before.

One of the issues we have todeal with is finding the correct



Figure 17 — External actors, messages, subjects, and application architecture.

Management

Reporting

G/L

Internal

Sales

Cost

Transfer

Sales

A/RA/P

Purchasing

Payroll

HR

Departments

(Internal Vendor

and Customer)

Employee

(Internal Vendor)

CustomerVendor

Vendor

Product/

Service

Enterprise

Product/

Service

Internal

Product/

Service

Internal

Service

Inte

rnal

P.O.

Inte

rnal

shipm

ent

Inte

rnal

invo

ice

Cos

t tra

nsfe

r mem

o

Custom

er order

Custom

er shipment

Custom

er invoice

Custom

er payment

P.O

.

Ven

dor sh

ipm

ent

Ven

dor in

voice

Ven

dor pa

ymen

t

Paycheck

Time

sheet

Work

product

Assignment

A/R Sales

A/P Purchasing

Payroll Human resources

Cost transfer Manufacturing

G/L Executive management

Accounting Operations

Table 1 — The Major Accounting/Operations Application Areas


level of abstraction. Too littleabstraction and you get miredin too much detail; too muchabstraction and there’s no com-munication. Some years ago, aclient of mine told me abouthis “thing 1/thing 2 theory.”Everything (for instance, actors,messages, nuclear physics, orDNA) could be reduced tojust one relationship: thing 1does something to thing 2. Bycombining large numbers of theserelationships, he said, you canexplain anything (that is, every-thing). Unfortunately, no one butmy friend could do much with thistheory; it was simply too abstract.

Over the past 20 years, IT hasbeen occupied with its own ver-sions of the thing 1/thing 2 theory.First, it was all about entities. Thisbegan in the late 1970s, whenPeter Chen came up with entity-relationship (ER) diagrams. AsChen maintained, most of theimportant things we want or needto say about the world can bemapped into statements aboutentities and their relationshipswith one another.

In a way, this has turned out to betrue. You will notice, for example,that we’ve been using ER dia-grams to describe our data mod-els here, and they work just fine.ER diagrams are good formedium-sized problem domainswhere you might have a fewdozen entities and relationships.The problem with ER diagramsis that they get big and compli-cated in a hurry, and they end up

containing hundreds of entitiesand hundreds of relationships.After a while, it gets difficult tosee the forest for all the trees,especially on very large projects.Fundamentally, ER diagrams arenetwork diagrams or complexnetwork diagrams.

Over the past few years, the sec-ond version of the thing 1/thing 2theory has been objects. Objects,via class diagrams, have becomeeven more ubiquitous than enti-ties. The 1990s were clearly theobject decade. Object class struc-tures and object class diagramshave become popular for model-ing the real world and program-ming as well. Now object theoryis based heavily on inheritance,mostly single inheritance. Thismeans that an object that issubordinate to another objectinherits all the attributes (andmethods) from the other objectsthat are higher in the hierarchy.Object class structures allow oneto model things top down, forexample, from actors to individu-als to customers. This turns out tobe a good thing for structuringactor and subject categories butnot so good for modeling mes-sages and events. My friend andCutter Consortium SeniorConsultant Arun Majumdar isfond of saying that object data-bases are good at modelingvertical (hierarchical) relation-ships and not so good at modelinghorizontal (network-based) ones.

My own feeling is that neitherentities nor objects ultimately

represent the right basis for busi-ness semantics; they are at leastone level too high. As it turns out,you need to be able to modelboth hierarchical and networkrelationships, but more important,we need to use categories of datathat actually mean something —that is, categories that have someinherent ontological meaning inthe real world. Both entities andobjects are so universal that youcan’t say anything specific aboutthem. On the other hand, whenyou say that something is an actor,you already know quite a lotabout that thing. For one, youknow that it falls into one of threemajor subclasses: individuals,organizations, or systems. Foranother, you know that if it is anindividual, it will have, for exam-ple, a first and last name, a sex, anaddress, height, weight, date ofbirth, and so on. The attributes(descriptors) work across theboard. If you are defining data foran actor/individual, you alreadyknow a great deal about what heor she is like.

The same holds true for subjects.If the subject is an individual, youknow the same things about himthat you do about an actor who isan individual. If the subject is aproduct or a parcel of land, youalso generally know a lot aboutthat kind of thing as well. (You caneven go online and find out whatinformation other people keepfor products or parcels, and it islikely that you will need the sameinformation.)



Obviously, this is true for businessmessages as well. You knowfrom the start that orders or ship-ments or invoices have a basicstructure. They have a header,which contains information aboutthe invoice as a whole, and detailinformation, which has informa-tion for each one of the thingsthe order or shipment or invoice isabout (i.e., messages are aboutsomething).

Natural languages like English orPolish or Bengali take advantageof semantical clues to stringtogether information. In sen-tences, once you’ve mentionedsomeone — say, Aristotle orMadame Curie — you can thensay “he” or “she,” and the listeneror reader can figure out who youmean. With semantics-basedmodeling, we know who ouractors are and what (or who)our subjects are. We also knowwhat the messages are, who theyrelate to, and what subject theyare about; we have introducedmeaning into our systems discus-sion. Semantics-based modelingallows you to build progressivelysmarter systems. Hopefully, oneday our systems will be able tothink beyond the two- or three-year-old level they have beenstuck at for the past 30 or 40 years.

All this is extremely important ifwe are going to create the nextgeneration of truly smart applica-tions and enterprises. Most of thesystems that we design and installtoday are not noticeably more

intelligent than those we designedand installed a decade or eventwo decades ago. Indeed, in manycases they are not even as smart,because a decade or two ago,analysts and designers were, forthe most part, much closer to thebusiness than we are today.

As I said previously, nearly 30years ago, I met a client of J.D.Warnier who already had in placean enterprise data architecture,an enterprise data architect, anda set of integrated, data-basedsystems that ran on that architec-ture. Until relatively recently,through work on integrated enter-prise resource planning (ERP) sys-tems, data warehousing, andenterprise architecture, I hadn’tseen comparable insight at work.

CONCLUSION

Like enterprise architecture,business semantics is a criticallyimportant activity. Currently, thestructure of our business, data,and application architecturesplays — and will increasingly play— an important role in everyaspect of IT and, therefore, inevery aspect of our organizations.The more that these architecturesreflect the real things that makeup our business environment —the actors, messages, subjects,events, business communications,business exchanges, businessprocesses, and business relation-ships — the better chance wehave of surviving inevitablechange.

Technology may have peaked inthe stock market, but it has notpeaked economically. Enterpriseseverywhere have more technol-ogy, which is good technology,than they can possibly use —and there is more on the way. Itwould be nice if the world sloweddown a bit so we could catchour breath, but that isn’t going tohappen.

The rate of technological andbusiness innovation is rising, notfalling. While we were trying tosurvive the bursting Internetbubble, international outsourcinghappened. While the telecommu-nications industry was trying tofigure out how to use the vastfiber-optic infrastructure in whichit had overinvested, Voice over IPhappened. While we were tryingto figure out how to use PDAsand tablet computers, reallysmart cell phones with GPS, built-in digital cameras, andhard disks happened.

Business semantics simply saysthat all of our systems are (orought to be) based on the majorthings (semantics categories) inthe real world, and these thingsare not going away. If we are tostay in business, we must havecustomers, and those customerswill be actors, and those actorswill come in one of three flavors:individuals, organizations, or sys-tems (the last of which are reallythe computers of individuals ororganizations).




And if we are to stay in business,we will need more and morerefined/smart (electronically sup-ported) business processes. Timeand distance mean nothing tocomputers and electronic com-munication, but they still meansomething to people. New tech-nologies will bring new ways ofworking. A good portion of thisreport was written on my backporch using a laptop with alarge, bright screen. Every day Icommunicate with colleagues andclients around the world. The onlyway that I can do so is by usingtechnology as best as I can. Iknow I’m not using the latesttechnology, but even using com-mercially available technology, I’mway ahead of a lot of people, evensome of my clients.

But technology has to includemeaning as well as speed. Oursystems have to become smarterso that people can use them bet-ter. Unlike computers andtelecommunications networks,people need buffers. People needrest and relaxation. People needinformation in the middle ofnowhere, and they need to beable to find privacy and quiet inthe middle of Tokyo or London.And if people are going tobecome totally dependent ontechnology to support their lives,they must have security.

Business semantics is not abuzzword; it is the foundation ofbusiness systems thinking. LikeAristotle 2,500 years ago, we aretrying to build a new science: a

science of business analysis, orga-nization, and systems. In order todo so, we also have to invent thewords for representing it.

First and foremost, semantics isabout meaning, and meaning islargely about (or at least startswith) things in the real world.Business meaning is about indi-viduals, organizations, and sys-tems — how they interact andwhat they interact about. The sys-tems that we build to supportthese individuals, organizations,and systems, along with thepersistent memory that we create(i.e., data, information, andknowledge), are the fundamentalstuff of our information systemsand the framework for our enter-prise architecture.

ENDNOTES

1In classical Greek, the word orprefix “meta” simply means“after.” Aristotle’s writings on thefoundations of philosophy origi-nally had no title. Because thework appeared in Aristotle’scollected writings after hisbook of physics, it was referredto simply as “metaphysics.”Through history, Aristotle’s meta-physics came to be so influentialthat the prefix “meta” eventuallytook on the meaning “higher,”“above,” or “abstract,” as in“metamathematics.”

2The original Greek meaningof category was simply“predicate.”

3At various times, these contextdiagrams have also been called“entity diagrams,” “actor-message diagrams,” and “com-munication diagrams.” They areso simple and natural that theyhave been discovered indepen-dently countless times. I was firstintroduced to them in my workduring the early 1970s; my friendsMorris Nelson and Peter Kitchreinvented the diagrams in thelate 1970s when we better under-stood how useful they reallywere. Later, I discovered individ-uals as different as GearyRummler and Cutter ConsortiumSenior Consultant Verna Alleeusing the same diagrams.

4Other forms of context diagramsuse two-way arrows, but theyfail to show the direction ofcommunication.

5A sender of a message can simul-taneously be a receiver; in otherwords, an actor can send himselfa message. In everyday life,people do this often by sendingthemselves messages orreminders. E-mail and other elec-tronic tools make this task easy.

6While we began with the ideathat actors are people (individu-als), we came to recognize thatin the context of business seman-tics — especially concerningbusiness systems — the term“actor” had to be expanded toinclude all things that canautonomously send and receivemessages.



7The earliest examples ofMesopotamian script date fromapproximately the end of the 4thmillennium BCE, coinciding intime and geographic locationwith the rise of urban centerssuch as Uruk, Nippur, Susa, andUr. These early records are usedalmost exclusively for accountingand record keeping. But thesecuneiform records are reallydescendants of another countingsystem that had been in use for5,000 years. As early as 8000 BCE,clay tokens were in use inMesopotamia for some form ofrecord keeping.

8This replacement of things byphysical tokens and physicaltokens by written symbols fore-tells the same transformation inbusiness systems, where thingswere represented by numbersand letters and ultimately byelectronic strings of ones andzeroes: it was the replacementof atoms with bits and of bitswith meaning.

9The word “cuneiform” comesfrom the word “wedge” in Latin.A cuneiform was any writingthat could be made on a tablewith a wedge.

10Jean-Dominique Warnierbelieved that you could actuallymodel any organization usingjust these four messages in com-bination. He even wrote thebook Logique de conceptiondes organisations based onthis concept.

11As in most semantic areas, it isuseful to look at the etymologyof a term to understand it. In thecase of the term “bill,” we find:“‘written statement,’ c.1340, fromAnglo-L. billa ‘list,’ from M.L.bulla ‘decree, seal, document’ ....Sense of ‘account, invoice’ firstrecorded 1404; that of ‘orderto pay’ (technically bill ofexchange) is from 1579” (fromOnline Etymology Dictionary;www.etymonline.com/index.php?term=bill).

12The notion of location comesinto play with the “address”of actors. Addresses specifylocations, which is how thingsare delivered by the postal ordelivery system. The creation of e-mail has spawned “logicaladdresses” that correspond tovirtual locations as well.

13Persistence is a very importantidea in business semantics. Wetend to give persistent entitiesnames or ID numbers so that wecan refer to them uniquely overtime. This carries over into ourdatabase design. The files thatcontain customer information orvendor information are orga-nized based on customer IDsand vendor IDs and are as inde-pendent of one another as wecan make them.

14Over the years, my colleaguesand I have gone back andforth about what to call these“things.” The reason that I usesubjects (or objects) is in keep-

ing with the fact that sometimesa message refers to a person, inwhich case it could be consid-ered a subject and sometimes itrefers to something passive, inwhich case it could be consid-ered an object. Moreover, whenreferring to a conversation, it isproper, at least in English, to saythe “subject” of the discussion.

15It’s important to note that we’reusing “object” in a much morerestricted sense than those whotalk about object-oriented analy-sis, design, or programming. Inthis business semantics context,we use object in much the sameway as your English teachermight have used the term “directobject” when he or she taughtyou how to diagram sentences.

16In the context of businessprocesses or of workflows,events play an especiallyimportant role, but here wedefine events as somethingassociated with messages.

17In more elaborate discussionsof context diagrams, it is usefulto think of each message beingtransported through a channel.The postal system, for example,can be thought of as a channelfor traditional “snail” mail andthe Internet as a channel for e-mail. In some cases, the busi-ness analyst is interested in thechannel (e.g., when transporttime is critical), but for the mostpart we are not interested in thechannel itself.




18Mathematical analysis tells usthat if the frequency of changeis n, we should not attempt tosample any more often than n x 2 (which is twice the fre-quency of change).

19The exception concerns periodicevents that prompt the genera-tion of externally defined mes-sages. For example, in the US,the W-2 report, which is a state-ment of earnings, must be sentto the Internal Revenue Serviceat the beginning of the year.While this event might appearto be internal, it is actually drivenby external requirements.

20One dictionary defines barteringas a simple form of trade wheregoods or services are exchangedfor a certain amount of othergoods or services (i.e., there isno money involved in the trans-action). Barter trade was com-mon in societies where nomonetary system existed or ineconomies suffering from ahighly unstable currency (aswhen hyperinflation hits) or alack of currency.

21Many organizations, especiallylarge ones, tend to think pri-marily about their side of busi-ness processes. They badgersmall vendors, for example, intogiving them good prices, thenthey take an inordinately longtime to pay. After a while, ven-dors simply won’t do businesswith these companies. Businessprocesses are based on business

exchanges, and businessexchanges are two-way streets.

22In the 1970s, my old friends andCutter Business TechnologyCouncil Fellows Ed Yourdon andTom DeMarco as well as ChrisGane and others promoted“structured analysis and design.”One major idea that came out ofthe movement were two con-cepts that were embodied ingood modules. Structured gurusmaintained that good moduleshad high cohesion and low coupling. In other words, thesemodules did only one or a fewthings and were lightly con-nected to other modules. Withthe advent of SOA, it appears tobe a good time to dust off theseconcepts as we look for designcriteria for services.

23According to AmericanTeleservices Association, forexample, CRM is defined as “Thestrategies, processes, people,and technologies used by com-panies to successfully attract andretain customers for maximumcorporate growth and profit.”

24See Warnier, Jean-Dominique.Logical Construction of Systems.Van Nostrand Reinhold, 1981.

25For further details, see Ken Orr,“Integrating Enterprise DataArchitecture and EnterpriseData Warehousing.” CutterConsortium BusinessIntelligence Advisory ServiceExecutive Report, Vol. 3, No. 2,2003.

ABOUT THE AUTHOR

Ken Orr is a Fellow of theCutter Business TechnologyCouncil and a Senior Consultantwith Cutter Consortium’s AgileSoftware Development andProject Management, BusinessIntelligence, Business-ITStrategies, and EnterpriseArchitecture Practices. He isalso a regular speaker at CutterSummits and symposia. Mr. Orris the founder of and ChiefResearcher at the Ken OrrInstitute, a business-technologyresearch organization. Previously,he was an Affiliate Professor andDirector of the Center for theInnovative Application ofTechnology with the School ofTechnology and InformationManagement at WashingtonUniversity. He is an internationallyrecognized expert on technologytransfer, software engineering,information architecture, anddata warehousing. Mr. Orr hasmore than 30 years’ experiencein analysis, design, project man-agement, technology planning,and management consulting. Heis the author of Structured SystemsDevelopment, StructuredRequirements Definition, and TheOne Minute Methodology. He canbe reached [email protected].



Abou

t the

Pra

ctice Business Intelligence

PracticeThe strategies and technologies of business intelligence and knowledgemanagement are critical issues enterprises must embrace if they are to remaincompetitive in the e-business economy. It’s more important than ever to makethe right strategic decisions the first time.

Cutter Consortium’s Business Intelligence Practice helps companies take all theirenterprise data, augment it if appropriate, and turn it into a powerful strategicweapon that enables them to make better business decisions. The practice is uniquein that it provides clients with the full picture: technology discussions, productreviews, insight into organizational and cultural issues, and strategic advice acrossthe full spectrum of business intelligence. Clients get the background they need tomanage technical issues like data cleansing as well as management issues such ashow to encourage employees to participate in knowledge sharing and knowledgemanagement initiatives. From tactics that will help transform your company to aculture that accepts and embraces the value of information, to surveys of the toolsavailable to implement business intelligence initiatives, the Business IntelligencePractice helps clients leverage data into revenue-generating information.

Through Cutter’s subscription-based service and consulting, mentoring, and training,clients are ensured opinionated analyses of the latest data warehousing, datamining, knowledge management, CRM, and business intelligence strategies andproducts. You’ll discover the benefits of implementing these solutions, as wellas the pitfalls companies must consider when embracing these technologies.

Products and Services Available from the Business Intelligence Practice

• The Business Intelligence Advisory Service• Consulting• Inhouse Workshops• Mentoring• Research Reports

Other Cutter Consortium PracticesCutter Consortium aligns its products and services into the nine practice areasbelow. Each of these practices includes a subscription-based periodical service,plus consulting and training services.

• Agile Software Development and Project Management • Business Intelligence• Business-IT Strategies• Business Technology Trends and Impacts• Enterprise Architecture• IT Management• Measurement and Benchmarking Strategies• Enterprise Risk Management and Governance• Sourcing and Vendor Relationships

Senior ConsultantTeamThe Senior Consultants on Cutter’s BusinessIntelligence team are thought leaders in themany disciplines that make up businessintelligence. Like all Cutter ConsortiumSenior Consultants, each has gained a stellarreputation as a trailblazer in his or her field.They have written groundbreaking papers andbooks, developed methodologies that havebeen implemented by leading organizations,and continue to study the impact thatbusiness intelligence strategies and tactics arehaving on enterprises worldwide. The teamincludes:

• Verna Allee• Stowe Boyd• Ken Collier• Clive Finkelstein• Jonathan Geiger• David Gleason• Curt Hall• André LeClerc• Lisa Loftis• David Loshin• David Marco• Larissa T. Moss• Ken Orr• Raymond Pettit• Thomas C. Redman• Michael Schmitz• Karl M. Wiig


Business Semantics

Documents

Transcript of Business Semantics