Arguing with Mendeleev

@JohnZachman insists that his classification scheme is fixed—it is not negotiable. Comparing his Zachman Framework with the periodic table originally developed by Dmitri Mendeleev, he says, "You can't argue with Mendeleev that he forgot a column in the periodic table".

Well, actually, you can. If you look at the Wikipedia article on the Periodic Table, you can see the difference between Mendeleev's original version and the modern version. Chemists nowadays use a periodic table with 18 columns. As Wikipedia states, "Mendeleev's periodic table has since been expanded and refined with the discovery or synthesis of further new elements and the development of new theoretical models to explain chemical behavior."

That's what makes chemistry a true science - the fact that the periodic table is open to this kind of revision in the light of experimental discovery and improved theory. If the same isn't true for the Zachman Framework, then it can hardly claim to be a proper science.

Some observers have noted that early versions of the Zachman Framework had fewer columns, and see this as a sign that the number of columns may be variable and open to discovery. They also interpret the word "extending" in Zachman's 1992 paper (with John Sowa) as an acknowledgement that the framework has evolved. But the Zachmanites reject this: they say that the six columns have always existed, it was just that the early presentations didn't mention them all. "Humanity for the last 7,000 years has been able to work with what, how, who, where, when, and why." (This sounds like a Just-So-Story - "How the Enterprise Architect Got His Toolset".) Questions that require more than one word in the English language (such as How Much and For Whom) can be discounted. (Graeme Simsion made this point in 2004, and this may have been what prompted Scott Ambler to add a cost column to his extended framework.)
 
Mr Zachman has a degree in chemistry, so he ought to understand what makes the periodic table different from his own framework. However, some of his followers are less cautious in their claims. I found an article by one Sunil Dutt Jha, whose "proof" of the scientific nature of EA seemed to rely on two key facts (1) that Mendeleev transformed alchemy into chemistry by creating the periodic table, and (2) that the Zachman framework looks a bit like the periodic table, therefore (3) EA must be a science too.


An earlier version of this comment was posted on Linked-In Is it true to say that “Enterprise Architecture” is a scientific basis for creating, maintaining and running an Enterprise?

---

Scott Ambler, Enterprise Agile: Extending the Zachman Framework (undated)

Philip Boxer, Modelling Structure-Determining Processes (19 December 2006)

Sunil Dutt Jha, Biggest myth – “Enterprise Architecture is a discipline aimed at creating models” (January 2013)

Graeme Simsion, What's wrong with the Zachman framework? (TDAN, January 2005)

John Sowa and John Zachman, Extending and formalizing the framework for information systems architecture (IBM Systems Journal Vol 31 No 3, 1992)

Ivo Velitchkov, Frameworks and Rigour (3 March 2013)

Alan Wall, Pattern Recognition and the Periodic Table (March 2013)

John P. Zachman, The Zachman Framework Evolution (2009-2011)

Erecting the Framework (Feb 2004) - John Zachman discussing his Zachman Framework for Enterprise Architecture in an interview with Dan Ruby



Related posts and presentations

For Whom (November 2006), The Kipling-Zachman lens (June 2009), Deconstructing the Grammar of Business (June 2009), Satiable curtiosity (September 2009), Evolving the Enterprise Architecture Body of Knowledge (October 2012), Enterprise Architecture as Science (August 2013), What is a Framework (February 2019)

eBook: Towards Next Generation Enterprise Architecture

Updated 04 May 2019

From AS-IS to TO-BE

Architects produce many types of models. One useful distinction is between AS-IS models (which describe the current situation) and TO-BE models (which describe some projected future situation). If we can compare an AS-IS model with a TO-BE model, we can identify and quantify the differences (known as Gap Analysis) and work out a route from AS-IS to TO-BE (known as Roadmap). See my post on Value of Models (Sept 2010).

If we wish to compare AS-IS with TO-BE, it is a good idea for them to be similar in as many ways as possible. For example, same viewpoint, same scope, same level of granularity, same terminology and notation.

But despite all that, they differ in meaning. We might be tempted to say that the AS-IS model describes something real, while the TO-BE model describes something imaginary. This would be why we have to apply different validation criteria: for the AS-IS model to be valid, it must correspond to our observations of the actual system (warts and all), whereas the TO-BE model is valid, it merely has to be consistent with other descriptions, such as descriptions of user goals and requirements

A model may start life as a TO-BE model - describing some desired future system. At some point in the history of this model, the system it describes becomes operational, and the model now becomes an AS-IS model. In which case, we might want to regard "TO-BE" and "AS-IS" as roles or phases in the life of a model, rather than permanent characteristics of a given model.

(If for some reason we wanted to create an exact replica of an existing system, then the AS-IS model might become a TO-BE model.)

The TO-BE model describes an imaginary system, and at some moment in time, the imaginary system turns into a real system: so we might call this the moment of realisation. It might make sense to regard "realisation" as an event in the life history of a model, when the model turns from a TO-BE model into an AS-IS model. It may also be an event in the life history of a system, as it goes from "imaginary" or "planned" to "real" and "operational".

Of course it's not always as simple as this. On many projects the first release of the system only implements part of the architecture. So we could have a model where half of it has been realised (now AS-IS) and half not (remaining TO-BE).

But there are two rival notions of realization to be found in the popular architecture frameworks, which seem to be mutually incompatible.

• Sometimes realization seems to be an association between two different artefacts - for example, the system being a realization of the model.

• And sometimes realization seems to be a quality that may be possessed by different artefacts to different degrees.- for example the physical data model might be "more realised" than the logical data model. The architecture frameworks are commonly presented using diagrams with a vertical arrow showing that realization increases progressively from top to bottom. (To make matters even more confusing, Zachman labels this arrow "reification".) The reverse arrow is called "idealization".

Each of these notions of realization seems to imply a different notion of reality. I am particularly sceptical of the notion of reality implied by the third notion of realization, apparently dividing some universe of discourse into "real" and "not-so-real" and "completely unreal".

Some people in software development worlds might regard what happens inside a computer as "real" and what happens outside the computer as "ideal". Meanwhile, business people are more likely to regard what happens in the business as "real" and what happens inside the computer as "abstract". If the job of EA is to bridge between these and other worlds, then EA needs to regard both of these notions of "reality" as equally legitimate, coming from equal and opposite viewpoints. For this reason, I regard any architecture framework with a one-sided (typically IT-centric) notion of reality as deeply suspect.

 

For more on reification, see my post Deconstructing the Grammar of Business (June 2009). See also The Topography of Enterprise Architecture (September 2011)

Note also Simondon's concept of concretization, which seems to involve a form of technical refinement akin to naturalization. "It can only be said that technical objects tend toward concretization, whereas natural objects such as living beings are concrete from the start." Gilbert Simondon, On the Mode of Existence of Technical Objects (1958). See also Bernard Stiegler, Technics and Time 1 (1994, English translation Stanford 1998).

Evolving the Enterprise Architecture Body of Knowledge

#entarch #EABOK There is a considerable "body of knowledge" in the enterprise architecture world. Among other things, this includes

• Founding documents that everyone references, such as Zachman's 1987 paper for the IBM Systems Journal, and the MIT book on Enterprise Architecture as Strategy.

• Various summaries and guides to the body of knowledge. Mitre produced a guide to the (evolving) EA body of knowledge around 2004 (known as EABOK), and there is a bunch of people currently trying to produce a new version of the EABOK. The BCS has published a Reference Model for Enterprise and Solution Architecture, which it uses as the basis for its architecture certification.

• Some standards, such as ISO/IEC 42010 and RM/ODP.

• Various frameworks that package this knowledge into some kind of semi-formal structure, such as TOGAF and DODAF/MODAF, as well as the Zachman framework. The Federal EA framework is incorporated into US law via the Clinger-Cohen Act.

• Various tools that encapsulate portions of this knowledge.

• Some attempts to formalize and ground this knowledge. There is some interesting work in the defence community to produce an EA ontology (MODEM) to replace the existing MODAF/DODAF metamodel. Meanwhile, there is a growing academic literature, much of it from the Netherlands for some reason.

• Huge amounts of commentary and proposed additions/revision by individual authors and bloggers. There is also a considerable admixture of insight and obfuscation from the large consultancies and analyst firms.

The body of knowledge as a whole can be understood as a set of definitions ("this is what we shall call a business function"), assertions and observations ("loosely coupled structures are more flexible"), instructions/injunctions ("always agree your principles before planning your systems"), and examples (mostly artificial or anecdotal), together with a bunch of rather spurious or irrelevant claims ("this is a mathematically proven technique", "this classification was invented by the ancient Greeks", "this is what everybody means by 'complexity' "). The body of knowledge also relies significantly on some terms that usually remain undefined, such as "alignment".

This body of knowledge as a whole has been subject to a number of criticisms.

• It is incomplete, inconsistent, imprecise, muddled, simplistic.

• It is impractical, fails to deliver value, not fit for purpose (however that purpose may be understood).

• It carries a hidden ideological agenda (which conveniently suits the commercial interests of the large software and IT services companies).

• It lacks a proper base of empirical evidence - much of the knowledge is received wisdom and rehashed fragments from other sources.

• It relies on "subject matter experts", who often have no experience or training in knowledge research and are merely trading their own preconceptions.

In response to these perceived flaws in the collective body of knowledge, many EA practitioners espouse a personal body of knowledge, which is smaller and hopefully more consistent than the conventional/collective body of knowledge. This personal body of knowledge is often presented explicitly as an alternative to the conventional body of knowledge, for example rants against TOGAF or Zachman. However, personal bodies of knowledge are not immune from the same criticisms, and often suffer from methodological syncretism.



How has the collective body of knowledge been developed and validated? Typically a combination of the following

• This is what everybody knows.
• This is what every good architect knows.
• Here's an interesting new idea, so let's bung it in somewhere.
• Our customers like it, so it must be right.
• This bit of TOGAF is obviously rubbish, so let's chuck it away and put something else in its place.

Imre Lakatos said that a research programme can be progressive or degenerative. A progressive research programme is one that enhances the explanatory or predictive power of a body of knowledge. (For example, the development of new medical knowledge is progressive if and only if it clearly contributes to more effective healthcare.) A degenerative research programme is one that merely adjusts the body of knowledge to explain away inconvenient results. (Hubert Dreyfus has argued that AI was a degenerative research programme, because it ran into unexpected problems it could not solve.) I have frequently observed that much of EA looks more like mediaeval scholasticism (taxonomy for the sake of taxonomy) than modern science.

I know that some of the readers of this blog aspire to push forward the EA body of knowledge in various ways, including the next version of TOGAF and the replacement EABOK - so my challenge to you guys is this: How are you making sure that your work is progressive and evidence-based?


Further discussion in comments below ...

---

Related posts

Methodological Syncretism (December 2010), Arguing with Mendeleev (March 2013), From Information Architecture to Evidence-Based Practice (April 2013), Towards Next Practice EA (May 2013), Enterprise Architecture as Science (August 2013), What is a Framework (February 2019)

eBook: Towards Next Generation Enterprise Architecture


Links added 2 February 2019

The Topography of Enterprise Architecture

A lot of the terminology of enterprise architecture depends on some basic categories and distinctions, which help to define the dimensions for various schemas and frameworks.

• Top-down / Bottom-up
• Ideal / Real
• Abstract / Concrete
• Espoused / In-Use

But the meaning of these terms depends on your perspective. See for example my previous post What Does "Top-Down" Mean?

One popular categorical distinction is between “ideal” and “real”, with a progressive series of intermediate states. This category implies a process known as “realization” moving from the “ideal” towards the “real” (for which the Zachmanites prefer the mediaeval word “reification”), and a contrary process known as “idealization” moving from the “real” towards the “ideal”.

(The Zachmanites claim that this distinction derives from some unnamed ancient Greek philosophers, but I have not been able to verify this claim. The earliest sources I can find for this notion are mediaeval Christian and Arabic philosophers such as Ibn Arabi and Ockham, although there may be some hints in Plotinus. What Plato and Aristotle talked about was Form and Matter, and although Form is often translated as Idea, that's not exactly the same.)

But it is interesting to see exactly what people regard as more “real”. For example, many people seem to think that the technology model is more “real” than the business model. In other words, a pattern of magnetic dots on a physical data storage device counts as more “real” than the flesh-and-blood customer that this pattern of dots represents. Such a technologically based notion of “reality” may be useful for some purposes, but it is inescapably a technological perspective. And no EA framework that uncritically adopts a technologically based notion of “reality” can claim to be free of a technological bias.

 

 

Stanford Encyclopedia of Philosophy: Form vs Matter  

For more on reification, see my post Deconstructing the Grammar of Business (June 2009)

Updated May 2024 to insert reference to Plotinus

The Sage Kings of Antiquity

The ancient Chinese philosopher Mozi (Mo Tzu) identified three criteria for judging a theory

1. Origin - reference to the sage kings of antiquity
2. Validity - reference to the evidence (the eyes and ears of the people)
3. Applicability - whether it brings benefit to the enterprise and the people

Mozi called this his three-prong method.

Enterprise architecture frameworks can and should be judged against the second and third of Mozi's criteria, and I should certainly like to see more effort and rigour in presenting the evidence to support a wide range of so-called principles and methods.


But what about Mozi's first criterion? Much of the current thinking and practice of enterprise architects can be traced back to a bunch of methodology gurus from the 1980s. A complete list would be impossible, but it would include people like Tom de Marco, Clive Finkelstein, Michael Jackson, James Martin and Ed Yourdon, and with John Zachman just gettting in at the end of the decade. (I think Zachman has more in common with these methodology gurus than with the OO/Patterns gurus - Booch, Jacobson, Rumbaugh, Wirfs-Brock et al - who followed them.)

The term enterprise architecture wasn't used in the 1980s, and appears to have been coined by Steven Spewak in the early 1990s. In those days, people generally talked about Business Systems Planning (BSP) and Information Systems Planning (ISP), and a lot of the early thinking came out of IBM (where both James Martin and John Zachman had worked). Information Systems Planning was the top level of the Information Engineering pyramid, produced by Finkelstein, Martin and others.

Why should 21st century enterprise architects care what the sage kings of methodological antiquity thought about enterprise systems? Firstly because the sage kings have given us a huge legacy of principles and practices, much of which are still in use today. Secondly because some of the assumptions made by the sage kings may now look obsolescent, not just because of technology change but because of emerging ideas of complex systems organization and management, and we need to critically review and refresh our principles and practices to ensure we are not still bound by these assumptions. And thirdly because there may be some principles and practices that have fallen into disuse and deserve to be revived.

Given that the empirical evidence for enterprise architecture is fairly weak, anecdotal and inconclusive, we are still more dependent than we might like on the authority of experts - whether this be semi-anonymous committees (such as TOGAF) or famous consultants (such as Zachman). And are the experts consciously or unconsciously recycling the wisdom of the sage kings?

So how much difference is there between today's enterprise architecture frameworks and the structured enterprise methodologies of the 1980s, such as information engineering? And how confident are we that we have kept the good bits and discarded the bad bits?


Declaration: I worked for James Martin Associates from 1986 onwards.

---

Mo Tzu: Basic Writings. Translated by Burton Watson (New York: Columbia University Press, 1963)

Nikos Salingaros​, What Ancient Chinese Philosopher Mo-Tzu Can Teach Designers Today (Metropolis, 20 June 2016)

Internet Encyclopedia of Philosophy: Mozi
Stanford Encyclopedia of Philosophy: Mohism
Wikipedia: Mozi

Links added 19 February 2020

Special Powers of the Architect - Getting The Big Picture

Does the Enterprise Architect have special powers?

---

Some people think that what uniquely characterizes enterprise architects is that they are the ones who get the big picture.

If this is true, it is because EAs have differently wired brains to the rest of humanity, or because their position and practices give them a different perspective on the enterprise? For a summary of a Twitter debate on this topic, see my blogpost Getting the Big Picture.

The next question is what this implies for the relationship between EAs and the rest of the enterprise. If EAs have these special powers of perception, do other people find this threatening? And how much of the Big Picture can be communicated? For a summary of a Twitter debate on this topic, see my blogpost Selling the Big Picture.

When I raised this question on the Enterprise Architecture Network group on Linked-In, Graham Berrisford thought this was a bit tautologous. Enterprise Architecture is the big picture, therefore Enterprise Architects are the ones who have the big picture.

But it is only a tautology if that's how you define enterprise architecture and if you only recognize one kind of big picture. Stock market analysts and venture capitalists might have an entirely different big picture.

To the extent that enterprise architects have a single set of lenses for viewing the enterprise (e.g. Zachman), their claim to have THE big picture is disputable. (Hence my interest in lenscraft - the use of multiple lenses providing alternative perspectives.)

Tuomo Stauffer suggested that the big picture comes from the board. In which case EA's job is not to get the big picture but to codify it.

But my question wasn't just whether the association between enterprise architecture and big-picturehood was true, but also what this association would imply (a) for the recruitment and development of EA skills and (b) for the (possibly threatening) relationship between EAs and the rest of the management world.

See also

• Special Powers of the Architect - Judgment (January 2012)
• Special Powers of the Architect - Abstraction (Feb 2013)
• Demanding Change - Big Picture

Is Enterprise Architecture a Science? Part 2

@RSessions was in London this week, so I sat down with him to continue our previous discussion Is Enterprise Architecture a Science?

The first question to address is - which enterprise architecture are we talking about? I think we both agree that there are some activities within the EA world that look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

For example, in his post What's Right with the Zachman Framework, Grant Czerepak states that "the architectural metaphor conceals what the six perspectives are actually about: Entities, Relationships, Attributes, Constraints, Definitions and Manipulations". And referring to the Kipling-Zachman lens, Grant claims that "the interrogatives have a foundation that goes back over three thousand years across every human culture". In a separate post, he says It's not Aristotle's fault, it's your fault. See my post Arguing with Mendeleev (March 2013).

Lots of EA frameworks are essentially abstract classification schemes that start from an abstract ontological argument ("obviously all businesses are made of objects" or "obviously all processes are made up of nouns and verbs") and make assertions that are not amenable to empirical verification.

Roger's SIP methodology is at least based on an empirically testable (and quantified) hypothesis. That a system of systems with such-and-such measurable structural qualities (in terms of Roger's definition of complexity) will have such-and-such predictable costs. So this provides the basis for a scientifically-grounded engineering practice. I think SIP methodology has a reasonable claim to be scientifically grounded: it can be evaluated not just on whether its prescriptions are practical, cost-effective and useful, but also whether its predictions are true. (Incidentally, I think it would be interesting to compare SIP with Christopher Alexander's early book Notes on the Synthesis of Form. This contains detailed and mathematically grounded work on architectural complexity: although the software gurus who developed structured methods in the 1970s were aware of Alexander's book, they left out most of the difficult detail.)


I think there is a further step before EA could ever dream of becoming a fully empirical science, and this would involve large-scale collection and analysis of empirical data, so that there would be a closed loop between theory and practice, connecting structure and value. In order to achieve this, we should need the active participation of some of the more powerful players in the EA game - the large consultancies and above all the key government agencies that govern IT expenditure. (You know who you are.) At the moment, there is little sign that these organizations are seriously interested in any game-changing innovation. (Roger and I should be delighted to talk to representatives of these organizations, please contact us.)

Deconstructing The Grammar of Business

@JohnIMM (John Owens) trots out a familiar piece of advice about data modelling today.

"Want to know what data entities your business needs? Start with the nouns in the business function names."

Starting with the nouns is a very old procedure. I can remember sitting through courses where the first exercise was to underline the nouns in a textual description of some business process. So when I started teaching data modelling, I decided to make this procedure more interesting. I took an extract from George Orwell's essay on Hop-Picking, and got the students to underline the nouns. Then we worked out what these nouns actually signified. For example, some of them were numbers and units of measure, some of them were instances, and some of them were reifications. (I'll explain shortly what I mean by reification.) Only a minority of the nouns in this passage passed muster as data entities. Another feature of the extract was that it used a lot of relatively unfamiliar terms - few of us had experience measuring things in bushels, for example - and I was able to show how this analytical technique provided a way of getting into the unfamiliar terminology of a new business area. I included this example in my first book, Pragmatic Data Analysis, published in 1984 and long out of print.

One problem with using this procedure in a training class is that it gives a false impression of what modelling is all about. Modelling is not about translating a clear written description into a clear diagrammatic structure; in the real world you don't have George Orwell doing your observation and writing up your interview notes for you.

Now let me come on to the problem of reification. The Zachman camp has started to use this word (in my view incorrectly) as an synonym of realisation - in other words, the translation and transformation of Ideas into Reality. (They claim this notion can be traced back to the ancient Greeks, but they do not provide any references to support this claim. As far as I am aware, this is a mediaeval notion; it can for example be found in the work of the Arab philosopher ibn Arabi, who talks about entification in apparently this sense.) However, modern philosophers of language use the word "reification" to refer the elevation of abstract ideas (such as qualities) to Thingness. One of the earliest critics of reification was Ockham, who objected to the mediaeval habit of multiplying abstract ideas and reified universals; his principle of simplicity is now known as Ockham's Razor.

In our time, Quine showed how apparently innocent concepts often contained hidden reification, and my own approach to information modelling has been strongly influenced by Quine. For example, I am wary of taking "customer" as a simple concept, and prefer to deconstruct it into a bundle of bits of intentionality and behaviour and other stuff. (See my post on Customer Orientation.) As for business concepts like "competitor" or "prospect", I generally regard these these as reifications resulting from business intelligence.

Reification tends to obscure the construction processes - tempting us to fall into the fallacy of regarding the reifications as if they directly reflected some real world entities. (See my posts on Responding to Uncertainty 1 and 2.) So I like to talk about ratification as a counterbalance to reification - making the construction process explicit.

Of course, John Owens is right insofar as the grammar of the data model should match the grammar of the process model. And of course for service-oriented modelling, the grammar of the capabilities must match that of the core business services. But what is the grammar of the business itself? Merely going along with the existing nouns and verbs may leave us short of discovering the deep structural patterns. 

 

Update May 2024. The distinction I'm making here between reification and its opposite, which I've called ratification, can be compared to Simondon's distinction between ontology and ontogenesis, so I shall need to write more about that. Meanwhile, I now acknowledge the possibility that some notion of reification might be found among the Neoplatonists but that's several hundred years after Plato himself.

Related posts: Reification and Ratification November 2003), Business Concepts and Business Types (May 2009), Business Rule Concepts (December 2009), The Topography of Enterprise Architecture (September 2011), Conceptual Modelling - Why Theory (November 2011), From AS-IS to TO-BE (October 2012), BankSpeak (May 2015), Mapping out the entire world of objects (July 2020)

The Kipling-Zachman Lens

The Kipling-Zachman lens from Richard Veryard

For Whom

There are several enterprise architecture approaches (TOGAF, DoDAF, MoDAF) based on the work of John Zachman and his Kiplingesque sextet:

"I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who."

These six interrogatives are commonly presented as the columns in a table. There have been some suggestions (strongly resisted by Mr Zachman and his followers) to extend the table.

One of the extensions we’ve been looking at the CBDI Forum is the possibility of introducing a "For Whom" column. Because value (in SOA and the service-oriented business) is not just experienced by “The Enterprise” (regarded as a single centralized pot of costs and benefits) but may be distributed across a federation or ecosystem.

For example, does a service intermediary add value for the service provider, or for the service consumer, or both? Does a change in business policy improve the whole supply chain, or have we merely pushed the problems upstream? Does a security layer mitigate risk for the bank or for its customers? Does a compliance monitoring service protect the interests of the directors or the shareholders?

Some people have told me that this is already implicit in the "Who" column. Or perhaps it is implicit in the "Why column. But I don't believe that many enterprise architects currently interpret the "Who" or "Why" columns in this way.

"For Whom" is important for SOA when we start to look at service networks that span several organizations. One organization may produce a business case for doing some SOA, but this may only be viable if other organizations cooperate. Participation in a network is based on some form of self-interest (each participating organization gets out more than it puts in) and/or some form of governance (the organizations collaborate according to some agreed or imposed regime).

In addition, "For Whom" is important for security engineering. Some organizations focus their security on protecting their own internal systems against a narrow range of direct threats, but seem to pay little attention to a broader range of indirect threats against themselves and their customers. In my view, an organization such as a bank should take a 360-degree view of security, and should try to provide real security for its customers and their assets, as well as for itself.

Finally, "For Whom" is important for ethics. The distinction between "For Whom" and "Who" is similar to the distinction between "Customer" and "Actor" in Soft Systems Methodology (SSM). Some readers may be familiar with the SSM acronym CATWOE, which stands for Customer, Actor, Transformation Process, WorldView, Owner, Environment.

---

Philip Boxer, Modelling Structure-Determining Processes (19 December 2006)

Chris Bruce, Environmental Decision-Making as Central Planning: FOR WHOM is Production to Occur? (Environmental Economios, 19 August 2005)

Wikipedia: CATWOE



Related posts: Arguing with Mendeleev (March 2013), Arguing with Drucker (April 2015), Whom Does The Technology Serve? (May 2019)


Updated 18 August 2019 to emphasize the ethical dimension.

SOA and Enterprise Architecture

The old-style IT practitioner always regarded distribution as a source of complexity, and instinctively preferred non-distributed solutions wherever possible. The Service-Oriented Architecture turns this attitude on its head. The whole point is to distribute functionality across a network of services.

The well-known Zachman framework for Enterprise Architecture has a column for Network, but historically this has generally been regarded as referring to geographical location. Zachman himself calls this column “Where” – the other columns being Data (“What”), Function (“How”), People (“Who”), Time (“When”) and Motivation (“Why”).

But in a fully service-oriented economy, we must abstract away from geographical location. Web Services and related technologies allow the geographical location (and other physical locators) to be completely transparent. Instead, we can now interpret “Where” as referring to locations within an abstract topology or network.

In the service-oriented business we regard the enterprise as a (possibly federated) network of services. It is not geographical distance that matters any more, but abstract notions of distance, including commercial and semantic distance.

Service-Oriented Architecture Frameworks (CBDI Journal, December 2003)