Tag Archives: organizations

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

The Newest from SOA: The SOA Ontology Technical Standard

By Heather Kreger, IBM

The Open Group just announced the availability of The Open Group SOA Ontology Technical Standard.

Ontology?? Sounds very ‘semantic Web,’ doesn’t it? Just smacks of reasoning engines. What on earth do architects using SOA want with reasoning engines?

Actually, Ontologies are misunderstood — an Ontology is simply the definition of a set of concepts and the relationships between them for a particular domain — in this case, the domain is SOA.

They don’t HAVE to be used for reasoning… or semantic Web. And they are more than a simple glossary which defines terms, because they also define relationships between them — something important for SOA, we thought. It’s also important to note that they are more formal than Reference Models, usually by providing representations in OWL (just in case you want to use popular tools for Ontology and reasoners).

What would an architect do with THIS ontology?Image credit: jscreationzs

It can be used simply to read and understand the key concepts of SOA, and more importantly, a set of definitions and UNDERSTANDING of key concepts that you can agree to use with others in your company and between organizations. Making sure you are ‘speaking the same language’ is essential for any architect to be able to communicate effectively with IT, business, and marketing professionals within the enterprise as well as with vendors and suppliers outside the enterprise. This common language can help ensure that you can ask the right questions and interpret the answers you get unambiguously.

It can be used as a basis for the models for the SOA solution as well. In fact, this is happening in the SOA repository standard under development in OASIS, S-RAMP, where they have used the SOA Ontology as the foundational business model for registry/repository integration.

The Ontology can also be augmented with additional related domain-specific ontologies; for example, on Governance or Business Process Management… or even in a vertical industry like retail where ARTS is developing service models. In fact, we, the SOA Ontology project, tried to define the minimum, absolutely core concepts needed for SOA and allow other domain experts to define additional details for Policy, Process, Service Contract, etc.

This Ontology was developed to be consistent with existing and developing SOA standards including OMG’s SOA/ML and BPMN and those in The Open Group SOA Workgroup: SOA Governance Framework, OSIMM, and the SOA Reference Architecture. It seems it would have been good to have developed this standard before now, but the good news is that it is grounded in extensive real-world experience developing, deploying and communicating about SOA solutions over the past five years. The Ontology reflects the lessons learned about what terms NOT to use to avoid confusion, and how to best distinguish among some common and often overused concepts like service composition, process, service contracts, and policy and their roles in SOA.

Have a look at the new SOA Ontology and see if it can help you in your communications for SOA. It’s available to you free at this link: http://www.opengroup.org/bookstore/catalog/c104.htm

Additional Links:

Heather KregerHeather Kreger is IBM’s lead architect for Smarter Planet, Policy, and SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Cloud, SOA, Web services, Management and Java in numerous standards organizations, including W3C, OASIS, DMTF, and Open Group. Heather is currently co-chair for The Open Group’s SOA Work Group and liaison for the Open Group SOA and Cloud Work Groups to ISO/IEC JTC1 SC7 SOA SG and INCITS DAPS38 (US TAG to ISO/IEC JTC 1 SC38). Heather is also the author of numerous articles and specifications, as well as the book Java and JMX, Building Manageable Systems, and most recently was co-editor of Navigating the SOA Open Standards Landscape Around Architecture.

6 Comments

Filed under Cloud/SOA