Tag Archives: language

What are Words Worth?

By Stuart Boardman, KPN

“Words are stupid, words are fun 

Words can put you on the run.”*

Many years ago I learned, at my own cost, how easily words can be re- and/or misinterpreted. The story itself is not important. What matters is that a bunch of us were trying to achieve something we thought was worthwhile, thought we’d achieved it but got conned by someone more cunning with words than we were. The result was pretty much completely the opposite result to what we intended.

I’ve spent a lot of time since then trying to find ways of tying down meanings so that, if someone disagreed with me, it would at least be clear to everyone what we were disagreeing about.. That basically involved looking for a very precise choice of words and offering a definition of what I was using them for. Nothing very original there. It’s the same motivation which leads us to create a glossary or taxonomy.

Which brings me to the problem I want to address: Definitions can actually get in the way of the discussion. In the professional world, inhabited by pretty much anyone likely to be reading this, we tend to borrow words from natural language to describe very specific concepts: concepts which we have made specific. Sometimes we borrow these words from other disciplines, which may themselves have specialized out of natural language. Sometimes the usage is often a form of metaphor or analogy, but with familiarization that fact becomes forgotten and it becomes just another word we take for granted.

Recently I had a (friendly) public debate with Tom Graves about the meaning of the word entropy, which we used separately from each other to characterize related but different phenomena affecting enterprises. We both used it as an analogy or parallel and we based our analogies on different definitions of the terms within the world where it originated, physics. These definitions are not contradictory in physics but are pretty divergent when used as analogy or metaphor. Tom and I are friends, so the discussion didn’t become rancorous, but we have yet to achieve a satisfactory resolution – at least not on an agreeable definition.

Also recently, I have witnessed a debate in the Enterprise Architecture community (on LinkedIn) about the meaning of the words business and enterprise. These are words common in natural language whereas here they were being used in the context of our specific discipline. In that context it was a relevant and perhaps even important discussion. The meaning you associate with them, unless you believe they are semantically identical, has a significant impact on your view of Enterprise Architecture (EA).

Unfortunately, the debate rather quickly developed into a heated discussion about who had the correct definition of each of these words. All kinds of “experts” from the worlds of economics and management science were quoted along with various dictionaries, which only served to prove that almost any position could be justified. The net result was that the substantial discussion got lost in definition wars. And that’s a pity because there were some important differences in perspective, which could have been useful to explore and from which everyone could have learned something – even if we all stuck to our own definitions of the words.

We may not be doing anything obscure with these words in EA, but we’re still giving them a very specific context, which may not be identical to what the man on the number 9 bus (or a professor in a business school) thinks of. If even then we are able to give them different, reasonable definitions, it’s clear that we should be seeking to focus on the underlying discussion, as intended/defined by the person who started the discussion. Otherwise we’ll never get beyond a meta-discussion.

So how can we get away from the meta-discussions? To come back to Tom and me and entropy, the discussion about the definition of the word was useful to the extent that it helped me understand what he was getting at. (Beyond that it was of no value at all in the context of the substantive discussion, which is why we parked it.) Later on, Tom observed that the important thing in a discussion about terms is the process of discussion itself. Interestingly my partner made the identical point last night and she comes from an entirely different discipline as a healthcare professional: What’s useful in such a discussion is not the statement we make but the story we tell. A statement is static. A story is dynamic. So then, instead of saying “my definition of entropy is X. What’s yours?” we say, “I use the word entropy to refer to the following phenomena/behaviors. What things are you trying to capture?” We’ve pushed that definition out of the way. Later on we may come back to it, if we think at that point it would be useful to tie the term down.

Another recent discussion on Ruth Malan’s Requisite Variety site reminded me of the importance of visuals – sketching something. In fact I’m seeing an increasing number of people talking about visual thinking You don’t have to be a great artist to sketch something out, which is a good thing because I can’t draw to save my life. You just need to realize that in your head you are very often visualizing something and not necessarily a physical object. I think that’s particularly true when we use analogy or metaphor. And how often do we talk of seeing something in our “mind’s eye”? Let’s get that vision out there, show what we think is going on and how things affect each other. Take a look at that discussion on Ruth’s site and check out the links provided by Peter Bakker.

Of course definitions have their uses and are important if a group of people developing standards need to agree on how terms will be used. The group also wants other people to understand what they’re trying to say. They hope that, even if they know another reasonable definition, they’ll accept this one for the purposes of the discussion. But sometimes people are sufficiently uncomfortable with your definition – with your use of the word – that it becomes a barrier to the discussion. That’s what happened in the enterprise/business argument I mentioned before.

Let’s think about the term enterprise again. TOGAF™ has a clear definition of enterprise, which I happily use in discussions with people who know TOGAF. There are, however, people who for perfectly good reasons have a problem with a government or non-profit organization being called an enterprise or who believe the term only applies to organizations above a certain size and complexity. There are also people for whom an enterprise is necessarily identical to an organization. I personally tend to a much more generous definition. What am I going to do when I’m talking to those whose definition of an enterprise is different from mine? Should I try to convince them my definition is right or should I say “OK, fine, we’ll use your definition but let’s talk about all those other things I wanted to include and try to understand how they affect our organization.”

I need to draw pictures. A picture doesn’t force anyone to agree on a definition. It provides a canvas (there we go, another common visual metaphor) on which to place the elements of the discussion. This picture, courtesy of Tom Graves, provides an example of such a canvas. You don’t have to agree on a definition to understand what is being said. And there’s an accompanying story. Then we can investigate what it was I was trying to say and whether we can agree about the what, how and why of mechanisms in play. That doesn’t mean they’re going to agree but at least we’ll be arguing about the actual substance and there’s a fair chance we’ll all learn from the process. The label we pin on it is then a secondary consideration.

“Words in papers, words in books

Words on tv, words for crooks

Words of comfort, words of peace

Words to make the fighting cease

Words to tell you what to do

Words are working hard for you

Eat your words but don’t go hungry

Words have always nearly hung me.”*

*From Wordy Rappinghood by Tom Tom Club (1981)

Stuart Boardman is a Senior Business Consultant with KPN where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity. 

11 Comments

Filed under Enterprise Architecture

Different Words Meant Different Things, Part 3

By Leonard Fehskens, The Open Group

In the second part of this series, I examined the effect of our definition of enterprise on how we think about EA.

To close, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.

The current cohort of EAs who have grown accustomed to a misnamed and narrowly focused discipline will eventually retire.  They will be replaced, over time, by EAs who learn the discipline in academic programs rather than by making it up on the job.  They will chuckle in amusement at a “body of knowledge” that is like that of medicine before germ theory, geology before plate tectonics, or astronomy before heliocentrism.  These programs are being created now, and academics are not interested in teaching a discipline with an irrational and inconsistent vocabulary.  They don’t want to have to explain to their students that it is for “historical reasons” that “enterprise means the IT part of a business.”

The focus of an academic program on Enterprise Architecture will necessarily reflect the prevailing concept of enterprise.  The commonly used model of Enterprise Architecture being about people, process and technology provides a useful context for considering this influence.

An IT-centric concept of Enterprise Architecture, like the one currently espoused by most of the community, will emphasize the role of information technology in supporting the needs of the business.  It will include just enough about business and people to enable practitioners to address the goal of “aligning IT with the business.”

A concept of Enterprise Architecture based on the idea of enterprise as business will emphasize business, especially business processes, as they are the primary locus of technological support.  It will include just enough about information technology and people to enable practitioners to address the goal of making IT a strategic asset for businesses.

A concept of Enterprise Architecture based on the idea of enterprise as human endeavor will emphasize the role of people, and be built around the sociology and psychology of individuals, groups and organizations, especially leadership and management as means to achieving organizational goals.  It will devote some attention to business as a particular kind of enterprise, but will look at other forms of enterprise and their unique concerns as well.  Finally, it will consider technology in its most general sense as the means of instantiating the infrastructure necessary to realize an enterprise.  There will be a lot of harumphing about how the conventional wisdom is correct by definition because it is what is practiced by the majority of practitioners, but there is a noisy and insistent contingent that will continue to point out that the world is not flat and the sun does not go around the earth.  Only time will tell, but however you measure it, over 90% of most organizations is “not-IT”, and the IT-centric perspective is simply so imbalanced that it can’t ultimately prevail.

Adopting a broader concept of enterprise consistent with its meaning in common English usage does not in any way invalidate any of the current applications or interpretations of Enterprise Architecture.  It simply allows the application of architectural thinking to other kinds of purposeful human activity besides commercial business organizations to be subsumed under the rubric “Enterprise Architecture”.  All entities that are enterprises by these more restrictive definitions clearly fit unchanged into this more inclusive definition of enterprise.

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

12 Comments

Filed under Business Architecture, Enterprise Architecture

Different Words Mean Different Things, Part 2

By Leonard Fehskens, The Open Group

In the first part of this series, I proposed distinct meanings of enterprise, business, organization and corporation.

As I noted earlier, you don’t have to agree with the distinctions I am making here.  But words are a finite, “nonrenewable” resource – if you treat these four words as interchangeable synonyms, you will not be able to make these distinctions without finding other words to make them for you.  In particular, you will not be able to distinguish an endeavor from the means of realizing it (similar to confusing an architecture and a blueprint).  You will not be able to distinguish one particular kind of endeavor (for example, a commercial endeavor) from other kinds of endeavors.  You will not be able to distinguish one particular kind of organization from other kinds of organizations.

Treating these four words as synonyms makes these words unavailable to describe larger and more inclusive domains for the application of architectural thinking.  What’s more, it does so needlessly.  This discipline doesn’t need synonyms any more than an organization needs multiple different systems that do the same thing.  Synonyms are redundancies that reduce the expressive power of the language we use to talk about what we do.  We need to be able to make distinctions between things that are important to distinguish from one another, and there are only so many words available to us to do so.

I acknowledge that for most of the community of practicing business and enterprise architects, most if not all of their practice occurs in the context of business-as-commercial-entities.  It is therefore not surprising that many people in the Business and Enterprise Architecture communities would not believe these distinctions are worth making, and be perfectly happy to (if not insistent that we) treat these words as synonyms.  But we have to be careful to avoid the example of the six blind men and the elephant, and being able to explain a predisposition to make these words synonymous doesn’t make it the right thing to do.

There’s even a contingent that insists that enterprise doesn’t just mean a commercial business organization, that it means a specific kind of commercial business organization, one that exceeds some critical threshold with respect to its scale, complexity, sophistication, ambition or consequence.  This is a bit like insisting that the implied “building” in “(building) architecture” means “commercial building”, or more specifically, “skyscraper.”

The problem with this concept of enterprise arises when one tries to specify the objective criteria by which one distinguishes a mere business from the bigger, more complex, more sophisticated, more ambitious or more consequential business that deserves to be called an enterprise.  It is certainly the case that the larger, more complex, more sophisticated, more ambitious and more consequential a commercial business organization is, the more likely architectural thinking will be necessary and beneficial.  But this observation about Enterprise Architecture does not mean that we ought to define enterprise to mean a large, complex, sophisticated, ambitious and consequential commercial business organization.

Why have so many naval vessels been named Enterprise?  Why was the Starship Enterprise from the Star Trek franchise so named, and why was this thought to be an appropriate name for the first space shuttle?  It was not because these vessels embodied some idea of a commercial business organization or because the word connoted a big, complex, sophisticated, ambitious or consequential business.  And surely if the latter had been the reason, there would be many lesser vessels named simply “Business”?

There are two significant consequences to basing Enterprise Architecture (EA) on a concept of enterprise that is limited to a particular kind of organization.  The first has to do with the applicability of the discipline, and the second has to do with how we educate enterprise architects.

If we restrict the definition of enterprise to a specific kind of purposeful activity, whether the criteria we use for this restriction are subjective or objective, we must either argue that architectural thinking is inapplicable to those purposeful activities that do not satisfy these restrictions, or we have to find a word to denote the larger class of purposeful activities to which architectural thinking applies, a class that includes both the restricted concept of enterprise and all other activities to which architectural thinking applies.

If enterprise means the same thing as commercial business organization, what do we call an entity that is not a commercial business organization (e.g., a church, a hospital, a government, or an army)?  Does Enterprise Architecture not apply to such endeavors because they are not created primarily to conduct business transactions?  What do we call organizations that are not businesses?  If we want to talk about an organization that is a business, why can’t we just use the compound “business organization”, which not only does not erase the distinction, it makes clear the relationship between the two?  Similarly, if we want to talk about an enterprise that is a business, as an enterprise, why can’t we just use the compound “business enterprise”?

Similarly, what should we call the architectural discipline that applies to human enterprise in general, and of which any more narrowly defined concept of Enterprise Architecture is necessarily a specialization?

Expanding definitions

The recent surge of interest in “Business Architecture” is, in my opinion, reflective of both the realization by the community that the historically IT-centric focus of Enterprise Architecture is unnecessarily circumscribed, and the lack of a systematic and internally consistent concept of Enterprise Architecture shared throughout that community.

There is a growing faction within the EA community that argues that most of Enterprise Architecture as practiced is actually enterprise IT architecture (EITA), and calling this practice EA is a misuse of the term.  Despite this, the widespread adoption of the egregiously oversimplified model of an enterprise as comprising “the business” and IT, and thus, Enterprise Architecture as comprising “Business Architecture” and “IT Architecture”, has led to the emergence of “Business Architecture” as a distinct if ill-defined concept.

It seems to me that many people consider Enterprise Architecture to be so hopelessly tainted by its historic IT-centricity that they view the best course to be allowing Enterprise Architecture to continue to be misused to mean EITA, and letting Business Architecture take its place as what EA “should have meant.”  I note in passing that there are some people who insist that EA “has always meant,” or at least “originally” meant, the architecture of the enterprise as a whole, but was hijacked by the IT community, though no one has been able to provide other than thirty year old recollections to support this assertion.

As I noted at the outset, I think Enterprise Architecture should encompass the application of architectural thinking to human endeavors of all kinds, not just those that are primarily business in nature, including, for example, governmental, military, religious, academic, or medical enterprises.  Yes, these endeavors all have some business aspects, but they are not what we normally call businesses, and calling the discipline “Business Architecture” almost unavoidably encourages us to overlook the architectural needs of such non-business-centric endeavors and focus instead on the needs of one specific kind of endeavor.

We have the words to name these things properly. We simply have to start doing so.

In part 3 of this series, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

2 Comments

Filed under Business Architecture, Enterprise Architecture

Different Words Mean Different Things, Part 1

By Leonard Fehskens, The Open Group

Over on the LinkedIn Enterprise Architecture Network discussion group there is a thread on the relationship between Enterprise Architecture (EA) and Business Architecture that as of late November 2012 had run to over 4100 comments.

Some of the sprawl of this thread is due to the usual lack of discipline in staying on topic.  Some of it is due to the rehashing of well-worn themes as newcomers arrive.  It seems clear to me though, that even when long time contributors try to move the subject forward, a lot of the back and forth that fails to converge is a consequence of the community’s lack of an appropriate and widely shared vocabulary.

In particular, there are four words that many in the Enterprise and Business Architecture communities seem to use interchangeably – enterprise, business, organization and corporation.

Before I tackle this subject, there is some context I should provide.

First, people who know me consider me to be obsessive about the precise use of language, and they’re right.  I think of Enterprise Architecture as more a craft than a science, and as such, the language we use to express it is ordinary language (as opposed to, for example, mathematics).  To me it follows that it is especially important that we use that language carefully.

Second, I’m coming at this from the perspective of creating a profession and its supporting ecosystem.  I believe a profession should be broadly applicable, with specializations within the profession addressing more narrowly focused concerns.

Finally, though much of the discussion about Enterprise Architecture is in English, I acknowledge that for a large fraction of the community English is a second (or third) language.  So, while this post is specifically about English usage, I suspect much of it applies as well to other languages, and I don’t want to imply that the conventions of English usage are the only ones worthy of consideration.

That’s enough by way of preamble.

The EA community may not have agreed upon definitions of many of the words it uses, but as these words are drawn from the vernacular, the rest of the world does.  This conventional usage makes clear distinctions between enterprise, business, organization and corporation.

While it is true that these words all have some sense in which they are roughly synonymous, they have primary definitions that distinguish them from one another.  I think we ought to observe these distinctions because they are useful, especially in that they allow us to sensibly relate the concepts they represent to one another, and they do not needlessly foreclose the broader application of these concepts.

First, I’m going to propose definitions for these words to be used in the context of Enterprise Architecture.  Then I’m going to look at what these definitions imply about the relationships between the things these words denote, and how the current usage obscures or denies these relationships.

It’s very possible, if not likely, that you will not agree with these definitions.  I’ll deal with that later.

Enterprise

The Oxford English Dictionary (Compact Edition, 1971) defines “enterprise” as:

Derived from the French entreprendre, “to take in hand, undertake”.

    1. A design of which the execution is attempted; a piece of work taken in hand, an undertaking; chiefly, and now exclusively, a bold, arduous, or momentous undertaking.
      • b. engagement in such undertaking
    2. Disposition or readiness to engage in undertakings of difficulty, risk, or danger; daring spirit.
    3. The action of taking in hand; management, superintendence. Obsolete.

So, enterprise means “undertaking” or “endeavor,” especially one that is relatively ambitious.  Implicit in this concept of enterprise is the intentional action of one of more people.  It is intentional in the sense that the action is intended to achieve some outcome.  The role of people is important; we do not generally consider machines, regardless of their purpose, to exhibit “enterprise” in this sense.  For me, the essential properties of an enterprise are people and their activity in pursuit of explicit intent.

This is a deliberately, very broadly inclusive concept of enterprise.  All of the following are, in my opinion, enterprises:

  • A child’s lemonade stand
  • A club
  • A professional society
  • A committee or working group
  • A town, state or country government
  • An international/multinational coalition
  • A military unit
  • A department or ministry of defense
  • A for-profit, non-profit or not-for-profit corporation
  • A partnership
  • A consortium
  • A church
  • A university or college
  • A hospital

Business

English speakers commonly use the word “business” to mean three things, and are usually able to infer the intended meaning from context.  These three common meanings of business are:

Business-as-commerce: The exchange of goods and services for some form of compensation for the costs and risks of doing so.

Business-as-commercial-entity: An entity whose primary activity is the conduct of some form of business-as-commerce.  In colloquial terms, the primary purpose of such an entity is to “make money”, and if it does not “make money” it will “go out of business.”

Business-as-primary-concern: The primary concern or activity of some entity.

These three different commonly understood meanings of business make it possible for someone to say something like:

“The business of my business is business.”

I.e., “The business-as-primary-concern of my business-as-commercial-entity is business-as-commerce.”

Organization

An “organization” is a structured (i.e., “organized”) group of people and resources, usually acting in concert to achieve some shared purpose.

Corporation

Finally, a “corporation” is an organization structured and operated in a particular way so as to satisfy certain legal constraints and thus benefit from the legal consequences of that conformance.  Strictly speaking, a corporation is a legal entity that has an organization associated with it.  In the case of a “shell” or “dummy” corporation, the associated organization’s people and resources may be minimal.

Observations

Based on these definitions, one can make some observations.

An organization is typically the means by which an enterprise is realized.  Small scale enterprises may be realized by a single individual, which is a trivial case of an organization.

Not all organizations are business-as-commercial-entities.  Organizations that are not businesses will almost certainly conduct some business-as-commerce as an adjunct activity in support of their primary intent.

Not all enterprises have as their intent some form of business-as-commerce. An organization that realizes such an enterprise will not be a business-as-commercial-entity.  While all business-as-commercial-entities realize an enterprise, not all enterprises are realized by business-as-commercial-entities.

Not all organizations are corporations.

Not all business-as-commercial-entities are corporations.

These relationships are depicted below.

 Len diagram

This is a three-part series that discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship.  Part 2 will examine the effect of our definition of enterprise on how we think about EA. 

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

5 Comments

Filed under Business Architecture, Enterprise Architecture

Are you sure that ‘good’ is what you want?

By Garry Doherty, The Open Group

The great English writer GK Chesterton once mused that if a man were to shoot his grandmother at a range of five hundred yards, he would be a good shot, but not necessarily a good man.

http://www.freedigitalphotos.net/images/view_photog.php?photogid=721That, of course, lies at heart of the difficulty with language. Words, simply put, are words; they carry no further attributes unless linked in some way with other language elements. Additionally, words, in isolation, do not usually convey contextual information, and without the appropriate context, misunderstanding is inevitable.

Nang is where it’s at!

Much to the consternation of many of English speakers, our language changes to meet the needs of its users; so, as a middle-aged man, I don’t really need to know what words like hamstered, bokoo or nang* mean (even though I might like to). So, Enterprise Architects too, will evolve their own languages to meet their own, very specific needs.

ArchiMate® is an early attempt to populate the void, the result of a multi-party €4M research and validation project involving the Dutch government, academia and industry. EA is still a fledgling profession and the adoption of languages is not an overnight activity, but interest in ArchiMate is growing and there is a real momentum building.

Heavenly partnership

We all know the importance and nature of stakeholders… they are not usually evil, but we do need to keep them happy, informed and we need their feedback… and at times that can be a real challenge. So what’s that got to do with ArchiMate?

Well, yes, ArchiMate is an open and independent graphical modeling language for enterprise architecture, but that’s only the start of the matter. It’s much more appropriate to see it as a stakeholder management tool. When used in conjunction with an EA framework like TOGAF™, ArchiMate takes on a new dimension and delivers an ability to communicate and collaborate with stakeholders through the creation of clear models, based on viewpoints that have a common foundation in both TOGAF and ArchiMate.

It may be a match made in heaven, but only time will tell!

*Go on, Google it. You know you want to.

Garry DohertyGarry Doherty is an experienced product marketer and product manager with a background in the IT and telecommunications industries. Garry is the TOGAF™ Product Manager and the ArchiMate® Forum Director at The Open Group. Garry is based in the U.K.

4 Comments

Filed under ArchiMate®, Enterprise Architecture