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).

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

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.