EA/ST Meeting Report October 2014

Perspectives on Enterprise Architecture and Systems Thinking

Unfortunately, I missed this month's EA/ST group meeting on Tuesday 21st October. But the presentations by @KlausØstergaard, @kvistgaard, @PhilipHellyer and @tetradian are now available.

• Klaus Østergaard, Value in Utilizing Systemic Thinking in the Field of Enterprise Architecture and Vice Versa (DropBox link)

• Ivo Velitchkov, Language & Metalanguage for Enterprise Architecture http://www.slideshare.net/kvistgaard/language-and-metalanguage-for-enterprise-architecture

• Philip Hellyer, Navigating Barriers (DropBox link)

• Tom Graves, Bridging Enterprise Architecture and Systems Thinking: http://www.slideshare.net/tetradian/bridging-enterprisearchitecture-and-systemsthinking

---

Language and Meta-language for Enterprise Architecture from Ivo Velitchkov

Bridging enterprise-architecture and systems-thinking from Tetradian Consulting

Schism and doubt

On Friday 14th June, there was a public meeting of the EAST group, entitled Perspectives on Enterprise Architecture and Systems Thinking, kindly hosted by BT in its offices near St Paul's. Tom Graves has posted a detailed write-up on his blog At ‘EA and Systems-Thinking’ conference.

What is the purpose of dialogue between EA and ST? Putting aside the debate about what the labels "Enterprise Architecture" and "Systems Thinking" might mean, there is certainly a thought that the two (or more) communities can learn from each other. There are strengths and weaknesses on both sides - so we may be able to produce a critique of EA from an ST perspective, or a critique of ST from an EA perspective. For example, in his presentation, John Holland asserted that "EA is broken - How ST can help". (See Tom's blog for summary.)

This kind of material often arouses a certain kind of resistance. "He's not talking about me, he must be talking about someone else." Where are the EAs to whom such a criticism as John's might apply? Surely the fact that we are going to these meetings, or reading these blogs, or participating in these Linked-In discussions, puts us into the most sophisticated and reflective quartile? 

One of the fundamental questions underlying discussion of EA and ST is imagining some kind of landscape with more or less distinct zones: EA over here, ST over there, this or that school of EA, this or that school of ST, good EA versus bad EA, authentic ST versus fake ST, mainstream versus next practice.

I have written several pieces on the relationship between Enterprise Architecture (EA) and Systems Thinking (ST), on this blog and elsewhere, but such pieces are always open to challenge by those who disagree about the correct use of the labels.

• "That's not what real Enterprise Architects do."
• "That's not really Systems Thinking."

So it sometimes seems that we cannot even start talking about EA and ST, and about the relationship (if any) between them, until we can agree what these terms mean. The desire to name things properly is an ancient one, and can be found in the Analects of Confucius. (See my post on the Wisdom of Confucius). But the prevailing desire to impose one's own definitions leads to endless and mostly unproductive debate on Linked-In and elsewhere. For this meeting, we hoped for a more productive energy, and I like to think we largely succeeded.

Some of the speakers fell into a dialectic mode of presentation - on the one hand EA, on the other hand ST. This can be useful as a starting point, but if the distinction between EA and ST is taken too seriously it may drive a wedge between practitioners. As Tom commented, "there don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really." For my part, instead of trying to avoid making any distinctions whatsoever, I put up a few slides with some provocative and playful distinctions, flagged with "possibly" and "tongue-in-cheek". But I haven't always been consistent about this, and (as someone pointed out to me) I probably need to be more careful when making a rhetorical contrast between "mainstream" and "next practice".

The EA/ST landscape may include Confucian and dialectic modes, but it should also include Daoist and dialogic modes. (For a brief explanation of the difference between dialectic and dialogic, see Wikipedia: Dialogic.) Robust debate between dogmatic EA and dogmatic ST may lead to schism, but even that is preferable to bland and empty speech. If we want to have a serious discussion about the strengths and weaknesses of current practice, then we must be prepared for robust critique, and we should not have to worry about over-sensitive practitioners taking everything personally.

One possible aspiration is to build a bridge between two communities, or perhaps even one single community. In their presentation, Patrick Hoverstadt and Lucy Loh presented some recent work of the EAST working group, showing how the concepts and techniques of EA and ST could be combined to address business challenges. This work is ongoing.

If we take the view that community building depend on affiliation (finding common beliefs and values), then any schism and doubt may seem to undermine this agenda. However, there is a more robust path to community building, based on alliance (accepting and overcoming difference for the sake of collaboration). For an eloquent defence of what she calls Deep Disagreement, see Margaret Heffernan's TED Talk Dare to Disagree.

Perhaps some people will think me perverse, but I look forward to plenty more friendly disagreement between EA and ST in future.

Perspectives on Enterprise Architecture and Systems Thinking from Richard Veryard

 

See also Towards Next Practice EA (May 2013), EA/ST Meeting Report (October 2014).

Some of this material is included in my (still unfinished) eBook Towards Next Practice Enterprise Architecture, available from LeanPub.

Towards Next Practice EA

A few weeks ago, @Cybersal and I met with @snowded to talk about enterprise architecture. He showed us a graph of the Complex Space, whose two dimensions were Evidence and Consensus. Dave has since posted a version of this graph on his blog.

Source: Dave Snowden, Cognitive Edge April 2013
Used with permission

At present, I believe there are two main clusters of Enterprise Architecture practice:

Mainstream EA. This is where TOGAF and Zachman and all the other popular frameworks sit. These frameworks are largely based on a 1980s view of enterprise and IT, contain apparently inflexible classification schemes, and are strongly aligned to the commercial interests of the large software companies and system integrators (IBM, Cap-Gemini, and the rest). These frameworks sit in the top left corner of Snowden's chart, with a high level of consensus and a very weak evidence-base.

If we look at Mainstream EA in terms of Boisot's I-Space, I would suggest these frameworks appear as premature codifications of ungrounded abstractions. The attempted diffusion of these codified abstractions is then ineffectual, because these ungrounded categories lack any relevance to real business challenges. From time to time, practitioners may well be able to do some useful work, and they may even be persuaded that their success is a consequence of using these frameworks. But it is also possible that these occasional successes are despite the framework and not because of it.

Next Practice EA, with a smaller but growing number of practitioners and researchers proposing radical alternatives to Mainstream EA. This community includes some well-placed industry analysts (such as Nick Gall of Gartner) as well as a significant number of independent consultants. Many of these alternatives involve hybrids of EA with some other discipline, such as Systems Thinking or Design Thinking. However, the evidence base for these hybrids is if anything even weaker than for Mainstream EA frameworks, and there is no consensus whatsoever. Few if any of these hybrids have been tested in full, and sometimes they appear to consist of little more than a bricolage of ill-assorted concepts and techniques, which I call Methodological Syncretism.

What would it take for Next Practice EA to develop either sufficient evidence or sufficient consensus to represent a serious challenge to Mainstream EA? It seems to me that the answer lies at the Concrete, Undiffused, Uncodified corner of the I-Space cube. What I have found highly frustrating in many discussions with both enterprise architects and systems thinkers is an apparent belief in the absolute virtues of abstraction. So instead of discussing concrete business problems, we find ourselves discussing generic categories of business problem. Many of the discussants either don't appreciate the difference between "Cost Saving" and "Cost Saving at Smartchester College", or they think that discussing the general category is more intellectually respectable than discussing a specific case.

There is of course a reason why discussing specific cases is treated with disdain in some quarters, which has to do with the way cases are used in some business schools, notably Harvard Business School. There are two ways to explore a specific case. In the Harvard approach, as I understand it, students are presented with cases which they need to "solve", using a light sprinkling of theoretical concepts. You use the theory if it works; if it doesn't, you ignore it. This approach isn't designed to produce a deeper understanding either of the cases or the underlying theory. The alternative (which I prefer) is a much more reflective and reflexive approach, where you use the case as an instrument to understand and test and refine the underlying theory. The aim is to end up with a rich and specific narrative that is both empirically and theoretically grounded. Only when we have a sufficient number of these narratives do we begin, with great caution, to generalize from them. But that's a lot harder and more time-consuming than putting together a blog or presentation full of post-modern cleverness. (Okay, I can be as guilty of this as anyone else.)

---

This is an extract from my draft eBook Towards Next Practice Enterprise Architecture, available from LeanPub.

These and related issues were discussed at a public meeting Perspectives on Enterprise Architecture and Systems Thinking, in Central London, June 14th 2013. For my own presentation slides, subsequent notes and links to reports by other participants, see Schism and Doubt (July 2013).

Why information architecture needs systems thinking

If a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory. If a revolution destroys a government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves ... There’s so much talk about the system. And so little understanding.

Source: Robert Pirsig, Zen and the Art of Motorcycle Maintenance, 1974

We who labor at the crossroads of structure and behavior have learned the hard way that content management is far messier than garbage collection and “the system always kicks back.”

Source: Peter Morville, Editorial: The System of Information Architecture (Journal of Information Architecture. Vol. 3, No. 2., 2012) 

Churchman’s interest in computing reaches extensively beyond the metaphor of inquiring systems. He addresses many issues with the state of MIS research of his time, including the tendency of IS researchers to focus on “safe” issues such as “structure of files, retrieval techniques, automatic abstracting, and the like” (Churchman 1968, p.111). He indicates that the majority of such research is not consistent with the systems approach as it focuses on transactions rather than the true goals or benefit of the system. Churchman is also quite visionary as he predicts the ubiquitous role of computers in everyday life. With the ability to “find facts” readily, Churchman predicted that information systems will actually work to reinforce a user’s Weltanschauung (world-view), as the user would screen information based on his Weltanschauung. In order to expand use MIS to expand the user’s view to one that is more holistic, Churchman envisioned a “deadly enemy” proposal for the design of an information system. The main role of this deadly enemy is for the system to propose information results based on assumptions that are opposite of the user’s information request, thereby revealing to the user his fundamental assumptions and at the same time questioning them (Churchman 1968, p. 122-123).

Source: Nicholas Berente, C West Churchman: Champion of the Systems Approach quoting Churchman, C.W. (1968) The Systems Approach, Dell Publishing Co.

See also Kristo Ivanov, The systems approach to design, and inquiring information systems (2001)

Enterprise as a ... System

Notwithstanding the earnest way some people use the phrase "enterprise-as-a-system", I don't see any great significance in regarding an enterprise or organization as a system.

Indeed, given the very broad way people commonly use the word "system", it is difficult to think of anyway to regard an enterprise other than as some kind of system. A machine or complicated technological assembly is a system; a human activity or social unit is a system; an abstract legal or procedural process is a system. All of the chapters in Gareth Morgan's book Images of Organization represent organizations as different kinds of system. And even if we don't regard an enterprise as quite the same as an organization, what could an enterprise possibly be, from anyone's perspective, other than some kind of system?

And many popular architecture frameworks claim to regard an enterprise as a system. For example

• TOGAF considers the enterprise as a system (TOGAF9, Chapter 2) 
• Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems. (TOGAF9 Chapter 6)

Elsewhere in TOGAF however, as well as in ArchiMate, we can find reference to systems OR organizations, which suggests that they do not regard the enterprise as a system.

• Archimate Chapter 3
• TOGAF Chapter 3

Some people claim to regard the enterprise as a system, and then offer a layered schema with System Layer near the bottom. This represents a shift in the use of the word "system".


However, when people use the phrase "enterprise-as-a-system", they may well have a particular kind of system in mind. Here are some examples.


Enterprise as a sociotechnical system

• Fred Emery, Characteristics of Sociotechnical Systems (1972)
• Edin Mustajbegovic, Idealised design for changing socio-technical systems (December 2012)
• Linked-In discussion (Jan 2013 onwards)

Enterprise as a socio-cultural—techno-economic system

• James Lapalme, Three Schools of Enterprise Architecture (2011)

Enterprise as a human activity system

• Stevens Institute of Technology
• Product Introduction Process Simulation in the Extended Enterprise (PIPSEE) (1997-2001)  

Enterprise as a self-organizing system

• Egon Noe and Hugo Fjelsted Alrøe, Farm Enterprises as Self-Organizing Systems (International Journal of Sociology of Agriculture and Food 2004) 

Enterprise as an open or closed system

• Fred Emery and Eric Trist, SocioTechnical Systems (1960)

Clearly it is the adjective that helps to make this phrase meaningful.


See also
 
Alan Hakimi, Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System (Feb 2013) - reposted on zentrasys

Linked-In Discussion Enterprises *NOT AS* Systems (April 2013 onwards)

System Theory for Architects

There is a growing interest among enterprise architects in systems theory or thinking. (In this context, the words "theory" and "thinking" seem to be for all intents and purposes interchangeable.) There are several possible reasons for this interest.

1. The idea that systems thinking provides some theoretical underpinning for enterprise architecture and/or systems architecture.

2. The idea that systems thinking is somehow complementary to enterprise architecture, and that there is some kind of synergy available from putting together concepts, techniques and practices from the two disciplines.

3. The idea that systems thinking and enterprise architecture are essentially doing the same things (modelling, abstraction, joined-up thinking, big picture, enterprise-as-system, etc etc)

4. The idea that systems thinking and enterprise architecture are rivals for our affections, and their respective champions are trying to show that one is more conceptually coherent, more broadly based, more solidly grounded, and even perhaps more useful, than the other. 


Both Enterprise Architecture (EA) and Systems Thinking (ST) have some espoused theory - in other words, things that both practitioners and researchers believe to be true. There are many different schools of EA and ST, and each school has a different set of beliefs, as well as a different set of concepts. Indeed, different schools may have widely different notions of what an enterprise or system actually is.

But EA and ST are not just random collections of theory but practices, offering a range of practical tools and techniques. These practices are instrumental, by which I mean that they are used by practitioners in order to perform some function, as a means to some defined set of ends, delivering something of value for some stakeholders. There is considerable debate in both the EA community and in the ST community as to what these ends are, and for whom. For example, some may think that the primary task of EA or ST is to describe and specify stuff, or to deliver understanding and insight. Others may think that the primary task is to plan and manage some kinds of change.

Practitioners may explain what they do, and why they think it works, but we shouldn't always take these explanations at face value. Espoused theory may not reflect theory-in-use. Thus although an EA practitioner and an ST practitioner may use different concepts to explain what they do. and may appeal to different authorities, what they actually do in real situations might possibly turn out to be pretty similar. The real test of similarity or difference between EA and ST would be observing what they actually do, and comparing the concrete conclusions and recommendations they produce, rather than listening to their various reasons and rationalizations.

Besides conceptual differences, practitioners may adopt a range of different stances towards the problem space. The classic EA stance is a visionary one - formulating an optimistic vision or blueprint of some desired future state. Whereas the classic ST stance may be a more realistic one - identifying the difficulties and risks in some elaborate plan. We can map these two positions to the opposite poles identified in Albert Hirschman's book The Rhetoric of Reason.

On the one hand, an optimistic and progressive stance (EA-as-visionary)

• Urgent action is necessary to avoid imminent danger ("The Imminent Danger")
• All reforms work together and reinforce each other, rather than being competing ("The Synergy Illusion")
• History Is on Our Side 

On the other hand, a more conservative or reactionary stance (ST-as-realist)

• Any purposive action to improve some feature of the political, social, or economic order only serves to exacerbate the condition one wishes to remedy. ("perversity thesis")
• Attempts at social transformation will be unavailing, that they will simply fail to "make a dent." ("futility thesis")
• The cost of the proposed change or reform is too high as it endangers some previous, precious accomplishment. ("jeopardy thesis") 

From a conservative or reactionary stance, the optimistic stance of the EA-as-visionary seems naive and possibly dangerous. However, the reactionary stance is also problematic, and Hirschman regarded the standard reactionary objections to all proposals for change as stupefying, mechanical, hyperbolic, and often wrong. See Cass R. Sunstein, An Original Thinker of Our Time (New York Review, May 2013).

We may observe that EAs with a strong appreciation of systems thinking often adopt an EA-as-realist position. Meanwhile, these are not the only possible stances for EA or ST. A number of other possible stances were identified in a workshop at EAC2009. At the time, these were called archetypes, as in my post EA Archetypes (June 2009).

And there are undoubtedly different ST stances as well. A common stance within ST is the Critical Diagnostic: here's why this can never work. Applies both to AS-IS (explaining the dysfunctional behaviour of existing systems) and TO-BE (pointing out the flaws in proposed interventions). This is perhaps fairly close to the EA-as-Realist stance. Another common stance within ST is the Critical Doctrine: here's why so-and-so's approach doesn't count as true Systems Thinking. Applied by nearly everyone against the Seddonites, and by the Checklanders against nearly everyone.

Undoubtedly the ability of EA and ST to work together depends (among other things) on the stances involved.


Meanwhile, those offering a conceptual unification between EA and ST either have a much harder challenge (if they wish to account for the detailed differences in outcomes between EA and ST practice) or a trivially easy challenge (if they confine themselves to asserting broad generalities and abstract principles).

---

See my previous post How to combine Enterprise Architecture with Systems Thinking (Jan 2011)


Updated 14 May 2013

Special Powers of the Architect - Abstraction

Does the Enterprise Architect have special powers?

---

One idea is that the intrinsic essence of an enterprise architect is to think about abstraction. (By the way, abstraction seems to be a category that can only be defined polythetically; it appears to have many characteristic features, but we seem to be unable to work out any defining features.)

Suppose that the use of an enterprise architect (if any) is to solve practical business problems. For this purpose, enterprise architects are interchangeable with systems thinkers, just as Jaffa Cakes are interchangeable with Fig Rolls. For a large tea party or enterprise transformation programme, we might have a plate containing Jaffa Cakes and Fig Rolls and various other cakes and biscuits.

But presumably that's not the only thing that an enterprise architect is good for.

So one theory-practice question is this. What are the essential things that an enterprise architect brings to solving practical problems? If it is abstraction, what special powers (if any) does this give to the practising enterprise architect? And what are the essential things that a systems thinker brings to solving practical problems?

Abstraction is associated with a number of myths and pitfalls

• The myth that radical structural and behavioural change can and should be driven by a few simple and powerful ideas. On the misuse of general principles (Jan 2012)

• Valuing abstraction and adaptability above everything else. Avoiding thinking about mundane technology when building pure business models. IT Innovation at Small Bakery (April 2009)

• The relationship between the general and the specific is poorly supported by the prevailing tools and methods, which often reduce the question to simplistic abstraction hierarchies. TOGAF 9 - Enterprise Continuum (Feb 2009).  Instead of generalizing everything as much as possible, architects need to reason explicitly about system structure and dynamics - cohesion and coupling, composition and decomposition, change and emergence. They need to understand granularity and stratification as active choices, rather than text-book patterns. Architecture and Abstraction (May 2004)

• Mainstream EA frameworks typically appear as premature codifications of ungrounded abstractions. The attempted diffusion of these codified abstractions is then ineffectual, because these ungrounded categories lack any relevance to real business challenges. ... So instead of discussing concrete business problems, we find ourselves discussing generic categories of business problem. Towards Next Practice EA (May 2013) 

See also

• Special Powers of the Architect - Getting The Big Picture (Dec 2010)
• Special Powers of the Architect - Judgment (January 2012)

Updated 26 October 2016

Co-Production of Strategy and Execution

#antifragile In my post Structure Follows Strategy?, I discussed the reciprocal relationship between strategy and structure, and discussed my friend Patrick Hoverstadt's mission to connect enterprise architects with the strategy processes in an enterprise.

My thoughts about strategy are influenced by Mintzberg, who sees strategy formulation as an emergent process of trial and error that takes place during implementation. A company may start with a broad-brush deliberate strategy, but this strategy often overlooks some significant issues and risks.

These weaknesses need to be addressed as part of the execution of the strategy. Thus a more complete and correct strategy emerges out of the execution process.

Senior management sometimes take a long time to recognize and acknowledge the fact that the defacto (emergent) strategy is now better than the original (deliberate) strategy. And in some companies the original strategy is so bad, and the senior management so pig-headed, that there is little chance of a more sensible strategy emerging.

In order to see strategy and execution as co-evolving, we need to link both strategy and execution to outcomes. If the outcomes turn out unsatisfactory, it is surely a subjective judgement whether this is blamed on weak strategy or weak execution. And if the overall outcomes turn out to be satisfactory then we may suppose that any weakness in strategy was compensated by excellent execution, and any weakness in execution was compensated by brilliant strategy.

This of course depends on our notion of excellence. Some people might think that perfect execution means doing exactly what it says in the strategy, no more or less. Alternatively, we might define excellence in terms of achieving the best possible outcomes, thus excellent execution may need to depart from the official strategy if that's what it takes.

Which brings me to Nassim Nicholas Taleb's notion of antifragility. If fragility means that something is harmed when bad things happen, antifragility means that something becomes better or stronger when bad things happen.

So let me try to apply this notion to the current discussion. A fragile strategy is one that would fail if there are any deviations in execution. A robust strategy is one that would be unaffected by the quality of the execution. And an antifragile strategy is one that would grow better with deviations in execution.

 

---

Partly based on my contributions to a Linked-In discussion I wonder what the EA team is doing? (One person has deleted his contributions, so the discussion as a whole no longer makes much sense.) See also Fragile Strategy or Fragile Execution? via Storify.

Carole Cadwalladr, Nassim Taleb: my rules for life (The Observer, 24 Nov 2012)

John Crace, Antifragile by Nassim Nicholas Taleb – digested read (The Guardian, 2 Dec 2012)

David Runciman, Antifragile: How to Live in a World We Don't Understand by Nassim Nicholas Taleb – review (The Guardian, 21 Nov 2012)

Co-Production of Data and Knowledge

Following Russell Ackoff, systems thinkers like to equate wisdom with systems thinking. As Nikhil Sharma points out,

"the choice between Information and Knowledge is based on what the particular profession believes to be manageable".

When this is described as a hierarchy, this is essentially a status ranking. Wisdom (which is what I happen to have) is clearly superior to mere knowledge (which is what the rest of you might have, if you're lucky).

---

Here's an analogy for the so-called hierarchy of Data, Information, Knowledge and Wisdom (DIKW).

• Data = Flour
• Information = Bread
• Knowledge = A Recipe for Bread-and-Butter Pudding
• Wisdom = Only Eating A Small Portion

Note that Information isn't made solely from Data, Knowledge isn't made solely from Information, and Wisdom isn't made solely from Knowledge. See also my post on the Wisdom of the Tomato.

---

That's enough analogies. Let me now explain what I think is wrong with this so-called hierarchy.

Firstly, the term hierarchy seems to imply that there are three similar relationships.

• between Data and Information
• between Information and Knowledge
• and between Knowledge and Wisdom

 as well as implying some logical or chronological sequence

• Data before Information
• Information before Knowledge
• Knowledge before Wisdom

while the pyramid shape implies some quantitative relationships

• Much more data than information
• Much more information than knowledge
• Tiny amounts of wisdom

But my objection to DIKW is not just that it isn't a valid hierarchy or pyramid, but it isn't even a valid schema. It encourages people to regard Data-Information-Knowledge-Wisdom as a fairly rigid classification scheme, and to enter into debates as to whether something counts as information or knowledge. For example, people often argue that something only counts as knowledge if it is in someone's head. I regard these debates as unhelpful and unproductive.

A number of writers attack the hierarchical DIKW schema, and propose alternative ways of configuring the four elements. For example, Dave Snowden correctly notes that knowledge is the means by which we create information out of data. Meanwhile Tom Graves suggests we regard DIKW not as layers but as distinct dimensions in a concept-space.

But merely rearranging DIKW fails to address the most fundamental difficulty of DIKW, which is a naive epistemology that has been discredited since the Enlightenment. You don't simply build knowledge out of data. Knowledge develops through Judgement (Kant), Circular Epistemology and Dialectic (Hegel), Assimilation and Accommodation (Piaget), Conjecture and Refutation (Popper), Proof and Refutation (Lakatos), Languaging and Orientation (Maturana), and/or Mind (Bateson).

These thinkers share two things: firstly the rejection of the Aristotelian idea of one-way traffic from data to knowledge, and secondly an insistence that data must be framed by knowledge. Thus we may validate knowledge by appealing to empirical evidence (data), but we only pick up data in the first place in accordance with our preconceptions and observation practices (knowledge). Meanwhile John Durham Peters suggests that knowledge is not the gathering but the throwing away of information. Marvellous Clouds, p 318

Among other things, this explains why organizations struggle to accommodate (and respond effectively to) weak signals, and why they persistently fail to connect the dots.

And if architects and engineers persist in trying to build information systems and knowledge management systems according to the DIKW schema, they will continue to fall short of supporting organizational intelligence properly.

---

For a longer and more thorough critique, see Ivo Velitchkov, Do We Still Worship The Knowledge Pyramid (May 2017)

Many other critiques are available ...

Gene Bellinger, Durval Castro and Anthony Mills, Data, Information, Knowledge, and Wisdom (Systems Thinking Wiki, 2004)

Tom Graves, Rethinking the DIKW Hierarchy (Nov 2012)

Patrick Lambe, From Data With Love (Feb 2010)

Nikhil Sharma, The Origins of the DIKW Hierarchy (23 Feb 2005)

Kathy Sierras, Moving up the wisdom hierarchy (23 April 2006)

Dave Snowden, Sense-making and Path-finding (March 2007)

Gordon Vala-Webb, The DIKW Pyramid Must Die (KM World, Oct 2012) - as reported by V Mary Abraham

David Weinberger, The Problem with the Data-Information-Knowledge-Wisdom Hierarchy (HBR, 2 February 2020)

DIKW Model (KM4dev Wiki)


Related posts: Connecting the Dots (January 2010), Too Much Information (April 2010), Seeing is not observing (November 2012), Big Data and Organizational Intelligence (November 2018), An Alternative to the DIKW Pyramid (February 2020)

---

Updated 8 December 2012
More links added 01 March 2020
Also merging in some material originally written in May 2006.

Perspective in Depth

As the systems thinking pioneer Gregory Bateson pointed out, there is an important difference between seeing with one eye and seeing with two. With monocular vision even the much prized Big Picture can be merely a flat and featureless panorama. Binocular vision affords a sense of depth and contour, and enhances the view.

When I wrote recently about the "What the Business Wants" viewpoint, Nick Gall challenged me to state whether I was referring to nominal purpose or defacto purpose (POSIWID). My answer was that the "What the Business Wants" viewpoint gave us a vantage point from which we could view both nominal purposes and defacto purposes at the same time, and appreciate the rich dependencies and contradictions between them.

So what happens when I apply the same thinking to the other five viewpoints? Each viewpoint has a monocular version (simple, linear) and a binocular version (rich, multi-dimensional). Here are a few key differences.

		Flat	Rounded	Links
Strategic View	What the Business Wants	Nominal purpose Nominal strategy	Defacto purpose Emergent strategy	Enterprise POSIWID
Capability View	How the Business Does	Operational capability Hard dependencies Top-down leadership	Sociotechnical capability and competency Soft dependencies Edge leadership
Activity View	What the Business Does	Linear synchronous process (value chain)	Asynchronous collaboration (value network)	Changing Conceptions of Business Process
Knowledge View	What the Business Knows	Formal information systems	Informal information systems Sensemaking Appreciative systems
Management View	How the Business Thinks	Goal-directed behaviour Management by objectives Single loop learning First order cybernetics (VSM)	Second-order cybernetics (Bateson/Maturana) Double-loop and deutero learning	Organizations as Brains
Organization View	What the Business Is	Enterprise	Business-as-a-Platform Ecosystem

But how should I label the two columns? Should I succumb to the temptation to label the first column "traditional"? Any suggestions?

Structure Follows Strategy?

#entarch In his talk to the BCS Enterprise Architecture Group this week, Patrick Hoverstadt suggested that traditional enterprise architecture obeyed Alfred Chandler's principle: Structure Follows Strategy. In other words, first the leadership defines a strategy, and then enterprise architecture helps to create a structure (of sociotechnical systems) to support the strategy.

Chandler's principle was published in 1962, and is generally regarded nowadays as much too simplistic. In 1980, Hall and Saias published a paper asserting the converse principle Strategy Follows Structure! (pdf), and most modern writers now follow Henry Mintzberg in regarding the relationship between strategy and structure as reciprocal.

What are the implications of this for enterprise architecture? Patrick offered us a simple syllogism: if enterprise architects determine structure, and if structure determines strategy, then enterprise architects are (consciously or unconsciously) determining strategy. In particular, the strategies that are available to the enterprise are limited by the information systems that the enterprise uses (a) to understand what is going on both internally and externally, and (b) to anticipate future developments. In many situations, the information isn't readily accessible in the form that managers would need to mobilize a strategic response to the complexity of the demand ecosystem.

Of course it isn't as simple as this. The defacto structure (including its information systems) is hardly ever as directed by enterprise architecture, but is created by countless acts of improvisation by managers and workers just trying to get things done. (The late Claudio Ciborra wrote brilliantly about this.) People somehow get most of the information they need, not thanks to the formal information systems but despite them. Thus the emergent structures are a lot more powerful and rich than the official structures that enterprise architects and others are mandated to produce. Patrick cites the example of a wallpaper factory where productivity was markedly reduced after smoking was banned; a plausible explanation for this was that smoking had provided a pretext for informal communication between groups.

Meanwhile, Minztberg drew our attention to a potential gulf between the official strategy and the defacto emergent strategy. (I have always especially liked his example of the Canadian Film Board, published in HBR July-Aug 1987.)

Nevertheless, Patrick's mission (which I endorse) is to connect enterprise architects with the strategy processes in an enterprise. He is a strong advocate of Stafford Beer's Viable Systems Model (VSM). Using his approach, which he encourages enterprise architects to adopt, VSM provides a unique lens for viewing the structure of enterprise, and for recognizing some common structural errors, which he calls pathological; I encourage enterprise architects to read his book on The Fractal Organization.


Related post: Co-Production of Strategy and Execution (December 2012)

Enterprise POSIWID

#bizarch #entarch #POSIWID As anyone knows who has attempted serious business and organizational transformation, an enterprise can be as stubborn as a teenager. Complex systems have strong feedback loops that maintain and restore the status quo against the most forceful and ingenious interventions.

One way of thinking about this challenge is to identify two distinct sets of purposes. On the one hand, there are the official intentions and plans of the leadership, which define what the purpose of the enterprise is supposed to be. We may call this the nominal purpose of the enterprise. Many enterprise architecture frameworks regard the nominal purposes as paramout, and are dedicated to realizing them. But on the other hand, the observed behaviour of the enterprise can best be explained in terms of an entirely different set of purposes, which repeatedly frustrate the official intentions and plans of the leadership. (See for example my post [Why New Systems Don't Work].) These are sometimes called defacto purpose; alternatively we can call it POSIWID, which stands for Stafford Beer's maxim that the Purpose Of a System Is What It Does. Large organizations and ecosystems are subject to inertia, and expensive initiatives often fall disappointingly short of expectations - this is the POSIWID effect at work. And of course there may be multiple conflicting defacto purposes [POSIWID should be plural].

POSIWID may also mean that there are covert purposes at work. Sometimes a corporate bureaucracy appears to be designed to make life difficult for employees and customers, as Tom Graves observes in relation to United's complaint resolution system [February 2010]; even if such a design is not consciously planned, it may be sustained by the short-term benefits it confers (such as cost-saving or corporate convenience).

Within enterprise architecture itself, we can perhaps distinguish between nominal purpose and defacto. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA [July 2008].
 
When TOGAF 9 introduced (but failed to explain) the term "Holistic Enterprise Change", I suggested it might mean something like this. When you make changes to the business as well as changes to the systems, you may get more than you bargained for. Conversely, when you make changes to the technical systems without making changes to the human systems, you may get less than you bargained for [February 2009].

By the way, Patrick Hoverstadt may well touch on some of these issues in his talk to the BCS Enterprise Architecture group in London next Thursday.

---

Tom Graves, Economics as enterprise architecture (March 2010)

POSIWID blog

How to combine Enterprise Architecture with Systems Thinking

#entarch #systemsthinking A great discussion yesterday between some systems thinkers from SCiO and some enterprise architects. This post is not a record of the meeting, but contains some of my thoughts following the meeting.

Does it make sense to combine EA and ST to create something we might call EAST?
Let me address this question in terms of the five perspectives outlined in my previous posts.

EAST as instrument	Use ST to improve EA. Use EA to improve ST. Or create a composite instrument using elements of EA and ST.
EAST as discourse	Either find the intersection between EA and ST - common concepts and principles. Or find the union between EA and ST - complementary concepts and principles.
EAST as community	Encourage EA people to become part of the ST community, or vice versa. And/or facilitate collaboration between EA people and ST people.
EAST as knowledge	Use ST to investigate and critique EA. Use EA to investigate and critique ST.
EAST as trade or service	Use EA as a platform for introducing ST into organizations. Use ST as a platform for introducing EA into organizations (perhaps at a different level).

All of these combinations are theoretically possible. It is possible to take any two or more disciplines and create an arbitrary hybrid, as long as you have pretty weak standards of coherence and usefulness. Weak coherence may be an essential step for early innovation, but shouldn't be an excuse for intellectual laziness. Gartner is currently pushing a specific hybrid, based on combining EA with design thinking together with some ecological ideas (panarchy), but I haven't seen any practical results yet. See my post on Hybrid Thinking and my note on Methodological Syncretism.

The practical question is how any such possible combinations can be grounded in practical work, rather than being merely abstract combinations of ideas and slideware. So the next task for the EAST group is to find some practical business problems to work on together.

Architecture and Logic

Jörgen Dahlberg suggests that "Enterprise Architects fail because of their reliance on logic as their single means of persuasion".

At a SCiO meeting in Manchester in 2010, Patrick Hoverstadt led an interesting discussion about logical levels, showing (among other things) how serious negotiation of critical issues often mixed logical levels. Sometimes you can "win" an argument by shifting to a higher logical level; but sometimes shifting to a lower logical level is the "winning" tactic.

There are several important points here. Firstly, "winning" doesn't necessarily mean winning. If you dig your heels in, you can win a local victory in a particular discussion, but you may damage your own longer-term interests. (Winning the battle but losing the war.) Secondly, shifting logical levels always has some emotional as well as logical content - it relieves some feelings as well as producing other feelings - for example, feelings of anger and frustration, especially in people who sense what is happening without being able to rationalize it.

@CarlChilley didn't find this surprising. "Decrease S/N ratio by changing the game and enter the emotional minefield that results." But what kind of people are going to win this kind of game? Presumably we need some form of emotional intelligence to successfully traverse an emotional minefield.

Just before writing this post, I happened to find my copy of Paul Watzlawick's book Ultrasolutions at the bottom of a box of old books. Watzlawick worked with Bateson on logical levels of communication, and includes some great examples of mixed logical levels in his book, including some heated exchanges between a fictional husband and wife.

Enterprise architects are typically adept at going up to a higher logical level (for example HOW - WHAT - WHY) regardless of whether this is appropriate in a particular context, and may not understand why this doesn't always automatically win the argument. Furthermore, if they lack emotional intelligence, they may fail to appreciate the emotional consequences of this tactic on the people they are hoping to influence.

So in what sense are enterprise architects good at logic?