At ‘EA and Systems-Thinking’ conference
For enterprise-architecture and systems-thinking alike, how can we reach towards the opposite of their too-common anti-pattern – all those endless ‘academic’ arguments on LinkedIn? More to the point, how can we bring it out of the abstract, and down into concrete, tangible and practical form that everyday people can use with success in their everyday work?
To me at least, these were the key aims for a brief one-day mini-conference on ‘EA and Systems Thinking’ last week in London, organised by Richard Veryard, Sally Bean and Jiri Ludvik.
We’d hoped to Tweet the conference itself on the hashtag #EASTmeeting, but unfortunately there was no wi-fi available in the conference-space. Hence, no Tweets – apologies! As possible compensation, though, what follows here are various assorted bits-and-pieces from my notes of the day: I hope you find them useful?
The day started off with an intro by Richard Veryard and Sally Bean. One of the themes here was that, for any kind of whole-of-systems approach, we need to link up with the people who make whole-of-context decisions. But as Richard illustrated with an example of trying to address core issues in the UK National Health Service, getting to the people who actually make those decisions is really hard, if not all-but-impossible. (Myself, I’m beginning to wonder if there is anyone who makes such decisions – and the absence of which is probably a key reason why things are in such a mess…)
Looking at EA (enterprise-architecture) and ST (systems-thinking), we use the term ‘we’ to describe the respective practitioners – yet who is ‘We’? 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. Part of it is that neither EA nor systems-thinking represent an explicit profession in their own right as yet: more just a variously-blurry set of clusters of disciplines and practices, perhaps more characteristic of a shared-enterprise than anything else.
One of the few things that is evident – all too evident, often – is a strange passion for spurious certainties, ardent assertions of absolute ‘truths’ where, almost by definition, it’s probable no such ‘truths’ are to be had. Over in systems-thinking, there are endless fights between hard-systems theorists and soft-systems theorists, VSMers versus value-streamers, the Seddonites against just about everyone else; here in EA, of course, there are the TOGAFites, DODAFites and FEAFites, those who insist that it’s always and only about IT, and those who equally-vehemently insist that it isn”t. One of themes that almost all systems-thinking practitioners preach is that we need to create systems and structures that can tolerate high levels of ambiguity, uncertainty and difference – but we’re often oddly abysmal at doing so ourselves. Oops…
On the human side of EA and systems-thinking, Sally Bean commented on a cross-over to the kind of space more usually occupied by knowledge-management. To me, that’s definitely true; and there’s also a similar cross-over with futures and strategy. None of that should be surprising, given that we purport to cover the whole context-space: yet perhaps those other disciplines might provide us with useful examples and allies?
At this point Steve Brewis of British Telecom took over, with a presentation on how he’d applied systems-thinking techniques – particularly Viable System Model – in building tools to help manage the huge complexities of the telecom’s physical, technical and human networks, and to tackle complex issues such as the ways in which changing energy-prices affect the choices and viability of the whole network.
Some quick themes:
- naming alone is not enough, we need meaning – a shift from taxonomy to ontology
- value is a systemic construct – it’s not intrinsic, it arises from the overall network itself
- chunking makes things more ‘manageable’, but destroys connections that create value
And a ‘capability and capacity maturity-model’:
- Capability
- Connected to business-commitment [? – can’t read my own scrawl there…]
- Balance
- Conscious / awareness (essential for feedback-loops)
- Conscience – ‘right things for right reasons’
Steve introduced a key concept of ferality, ‘going feral’, “an auto-catalytic phenomenon that is self-perpetuating’ – such as trying to ‘control’ by putting more managers in… Key causes of ferality include:
- ignorance
- specialisation
- partitioning
- too much emphasis on (local) difference
- no account taken of agile behaviour or agile needs
- does not consider / acknowledge / respect system-wide decisions or business-rules
Specialisation, for example, creates spurious (local) ‘efficiency’, without awareness of impacts on (global) effectiveness. Often there’s no sense of awareness of who (if anyone) is responsible for coordination (in other words, for absorbing coordination-complexity).
Steve argued that business-rules bring the system alive, by providing the motivating ‘Why’, rather than the more usual demotivating ‘Why you should not’. (I’m not sure I agree with Steve on this: in my experience, I’ve more often seen the presence – rather than absence – of predefined ‘business-rules’ to be the root-cause of problems, rather than their solution. Rather than fixed ‘business-rules’ [SCAN: Simple], we often need more fluid, contextually-adaptable principles [SCAN: Not-known].)
Peer-to-peer conversation is crucial (in effect, providing VSM’s system-2 coordination and system-3* audit services). Also “We understand services through the eyes of the customer”: this is very different from a factory context – Taylorism doesn’t work for services.
Steve demonstrated a live simulation ‘dashboard’ he’d developed for managers and others at BT, showing the whole business-context somewhat in VSM terms. (I’ll have to admit that the maths and IT-systems-knowledge involved in this was way out of my league…) “It’s always useful to compare against the same time last year”, he said, “to see how we’re performing to seasonal demand”. (I have my doubts here: doesn’t this assume linearity of demand from year to year? What about the realities of variety-weather? Is there a risk here that this could become a kind of VSM-lite, mis-applied to prop up the myth of ‘control’ for managers?)
The purpose of the mathematical model, he said, is to enable to business to respond to customer demand. “Service – non-predictable, high-variety – is different from a factory -where variety can be ‘controlled’. VSM gives us ‘centralised decentralisation’.” (It’s ‘more understandable’, yes – but at the cost of loss of visibility of real complexity?)
And finally, a couple of replies to questions, first on his own relationship with EA in the organisation: “EA in BT are focussed solely on IT – I’m not. The IT-people have co-opted EA…”. And also “Ontologies are dynamic, not static” – they change over time, in response to business context and business need.
After a useful small-group discussion – the conference-schedule allowed plenty of time for these, which was good – next up was John Holland, on why EA is broken, and how ST can help.
I didn’t take anything like enough notes here – sorry! But the core, I’d guess, was really just a catalogue of the various ways in which mainstream ‘EA’ is broken: it’s literally static, in the sense of ‘state-oriented’; it takes too long; it doesn’t match up with reality; and so on, and so on, and so on. Painfully familiar for anyone who’s been around in ‘the trade’ for any length of time and whose work touches anything outside of IT, of course, but often far from obvious for anyone else. His real question – or challenge to the group, rather – was “How can we use ST to do stuff better?” – or better than the limiting mess of IT-centric ‘EA’, anyway.
Quite a lot of discussion ensued in our various small-groups. Sally Bean‘s group focussed on the centrality of requirements in TOGAF, pointing to Steven Spewak’s work: “there is no such thing as requirements”. “We’re moving away from requirements – moving towards success-stories or outcomes – because it identifies [future] value.” Someone else commented that although functional-specification requirements are limited, or worse, there are other kinds of ‘requirements’ that are useful, such as:
- outcome-requirements
- “a day in the life of…” requirements
- “we’d like to explore this…” R&D-requirements
Another comment from one of the other groups was that “the TOGAFites are not the whole of EA, just as the Seddonites are not the whole of ST”.
And a final comment in that section – from Steve Brewis, I think? – was that the key business-benefit of combining EA and ST was to improve ‘decidability and manageability’. Not sure I’d fully agree – especially around ‘manageability’, which risks taking us back to Taylorist territory all over again – but yes, important themes, at the least.
Next Richard Veryard, with more on links between EA and ST, and the overall complexities of the business-context. Usefully, Richard also described a key challenge illustrated by ‘the Warning of the Doorknob’: the tendency for systems-thinkers to get caught in ever-extending escalation towards ‘big-picture’ – the inverse of the analysts’ tendency toward ever-finer-detail regression and decomposition. In other words, exactly as we need to be careful to constrain ourselves to Just Enough Detail, we need Just Enough Big-Picture too.
The common challenge for both EA and ST, Richard suggested, is to create interoperability between all the different viewpoints and (time)scales. And in that I would definitely concur.
Which lead us to the final main session, by Patrick Hoverstadt and Lucy Loh, presenting a kind of comparison between the worldviews, tools and techniques of EA and ST, and how we could bring them closer together – based on a study that they’d conducted for and with the original EAST group.
It was a good session, and in its way a good study, but I’d have to admit that that I found myself bouncing back and forth between mildly-grudging agreement and near-apoplectic fury. The reason for the former was that whilst Patrick definitely knows his stuff – see his book The Fractal Organization – he tends to focus on VSM almost to the exclusion of everything else; and the reason for the latter was that, all the way through, his effective definition of ‘EA’ was little more than TOGAF-style IT-centrism – which made the whole analysis seem way too much like a crude ‘strawman argument‘ against all forms of EA. (I know there were several others there who felt that way, too.) Just as one illustration here, Patrick listed VSM as a technique used solely in systems-thinking and not in EA, whereas I’ve been using it as a core theme in much of my EA work for many years now – for example, it’s a key component in service-modelling with Enterprise Canvas. Part of my over-reaction to this is probably the usual ‘curse of knowledge’, of course: I’d have to admit that my own EA practice is quite a long way out on the bell-curve, and it’s true that many existing ‘EA’-practitioners would be comfortable enough with the more myopic subset of ‘real-EA’ that Patrick described. The whole point of the conference, though, was to find ways to break EA out of that IT-centric box: yet here was Patrick firmly pushing us back into it again – and the fact rankled. A lot. Which kinda distracted. Oh well.
(Perhaps the simplest way to summarise it is that, to use James Lapalme’s ‘Three Schools of Enterprise Architecture‘, Patrick and Lucy’s study was based firmly on ‘first school’ – ‘Enterprise-Wide IT-Platform’ – whereas it’s probable that most if not all of the EA practitioners at the conference would have been ‘third school’ – ‘Enterprise-In-Environment’. Hence the clash of perspectives: Patrick and Lucy were describing a view of EA that the practitioners there had, through much hard work, largely left behind – and did not want to be dragged back to it again!)
One useful part of their study, though, was the use of an ‘organisational model’ (which I would probably term more as a capability-model) to act as a conceptual ‘spine’ against which all the other disparate models can connect.
Also, importantly – and I agree with them on this – neither the mainstream ‘EA’ toolset, nor the various ‘ST’ toolsets are complete enough on their own: we need to merge them together to create a true whole-of-enterprise toolkit.
And Patrick (or maybe someone else – I didn’t note it down) ended with the rhetorical question “Is the ‘architecture’ metaphor still helpful here?” To which the general consensus was ‘Probably not’ – but as yet we don’t have a clear alternative with which to replace it. Which is a very real problem we still all face at present. Hmm…
Overall, a good day: well worth doing, at any rate. (There’s some real hope that it’ll happen again in the relatively near future – perhaps in other cities elsewhere.)
The only catch, for me, is that it still doesn’t satisfy what to me is the driving need, for both EA and ST: to bring it down from the airy abstractions, and reframe it in more tangible and practical form. But it’s enough of a start for now, I guess: one step at a time, one step at a time…
Over to you for comments, perhaps?
Thanks for this report, Tom.
Do people sometimes suffer from the need to put others into boxes? Is this a form of identity by exclusion (we are who we are ‘cos we’re not the other people)?
Like you (but differently) I use VSM as an EA tool. We’re not the only ones in our space to use it – or other ideas from outside the traditional EA space. But we appear to be a small minority. Is this because the overwhelming majority of EA practitioners see EA, at least implicitly, as an IT focused activity? Or is it because the minority are not organized? And sometimes too busy disagreeing with each other about the one true gospel?
Is it all the fault of TOGAF? Or of the people making money out of TOGAF? Or the people who have a vested interest in keeping EA anchored in IT? Interesting topic for a post on the Open Group site. Must do that sometime.
Anyway, it sounds like a conference I would have wanted to attend despite its frustrations.
Great summary, thanks Tom.
The Warning of the Doorknob comes from a paper by Eberhard, The doorknob story has been quoted by several people, including Ed Yourdon, and can easily be found on the internet, but the rest of Eberhard’s paper is also worth reading if you can get hold of it.
My slides from the day are here.
http://www.slideshare.net/RichardVeryard/perspectives-on-enterprise-architecture-and-systems-thinking
On Stuart’s comment about putting people into boxes.
Although the labels in my presentation were not intended as rigorous classification, Nick Gall (@ironick) of Gartner interpreted them as such. He tweeted “You label Gartner’s #hybridthinking as baroque?! Ouch, that hurts. 🙂 Couldn’t you have gone with Organic?”
http://twitter.com/ironick/status/346734889065934849
In my presentation, I had listed Hybrid Thinking and Complexity next to Baroque merely because I saw a loose association, and I had to cluster things somehow. The Baroque is fascinating, and there may well be some deep links between panarchy (which Nick rates) and Leibniz, but I haven’t explored this in detail.
In my presentation, I also refer to the EA tendency to follow Confucius (“What is necessary is to call things by their right names”), and contrasted this with the Daoist principle (“If you can define something, you haven’t understood it properly”.) Just in case this isn’t clear, I am not on the side of the Confucians.
At the risk of taking us off topic, I note Richard Veryard’s reference to:
“the EA tendency to follow Confucius (“What is necessary is to call things by their right names”), and contrasted this with the Daoist principle (“If you can define something, you haven’t understood it properly”.)”
I have of late been tilting at the windmill of what I see as the EA community’s widespread predisposition to name things in arbitrary if not misleading ways, so I have to wonder who Richard’s been hanging out with.
That said, though, I’m convinced that getting the names “right” (I’d settle for “suggestive of what they denote”) is only the first step in a long journey.
I don’t see how this is necessarily at odds with the idea that “If you can define something, you haven’t understood it properly”. Of course, this must be a deep thought because it is so appealingly Eastern in flavor.
I think we too often fail to distinguish between “definition” and “conceptualization”, but regardless, I am reluctant to completely abandon the idea of some boundary, however porous, that serves to at least loosely delimit the concept that a “suggestive name” denotes. Again, how else are we to communicate meaningfully, absent such conventions?
Suggestive names for loosely delimited concepts do not for me imply any certainty either way about “proper understanding”, however one might define (oops, there’s that naughty word again, perhaps I should say “understand”) “proper”, but they do seem to me to be helpful in moving toward such understanding.
len.
@Tom
Thanks for the write-up. I’d just like to correct a couple of minor things.
Firstly the intro was by Jiri and Richard – I was doing the facilitating.
Secondly, there wasn’t actually a group discussion about centrality of requirements in TOGAF. I made an observation individually as a response to John’s talk, to make a point similar to yours that there are multiple perspectives on EA. One of the key things about EA that Spewak emphasised in his book (which is data-centric and otherwise very out-of-date) is that the high-level architecture of IT systems should be driven by a model of the business rather than a laundry list of requirements which tend to be arbitrary and driven by pet needs of individuals. The model needs to identify those things that are relatively stable and fundamental. So I’ve always been uncomfortable with the way that the core TOGAF diagram seems to be centred on requirements rather than models and principles. Interestingly a similar point is made in one of the very first books that I read about systems thinking (by Michael Balle) to illustrate the need for models that more effectively explore patterns of causality when solving problems. “When faced with a problem, our natural reaction is to make a laundry list…. Laundry list logic will lead to laundry list solutions.”
Sally
Sally Bean notes:
“So I’ve always been uncomfortable with the way that the core TOGAF diagram seems to be centred on requirements rather than models and principles.”
This is a perfect example of the point I have been flogging the past year or so that we need to be careful about the words we choose, because people have a tendency to key off their connotations rather than focus solely on their denotation.
First, let me be clear that I do not think that this is “bad”, and that people should resist this tendency, only that it is unavoidable, and we must take account of it.
I have spent enough time with the major TOGAF contributors that I am pretty sure that they did not intend that the “requirements” in the center of the “crop circle” be interpreted this way, i.e, as a “laundry list”. Unfortunately, there’s not much in the TOGAF specification that makes this clear.
My interpretation, and it is just that, my interpretation, I cannot pretend to speak for the TOGAF community, and I am not speaking for The Open Group or its membership, is that the word was chosen to convey a sense of specificity to the particular “work package” at hand (see for example the definition in section 3.68 of the TOGAF 9 specification), while “principles” would have been more suggestive of the timeless (or at least much more slowly changing) context that applies to all such work packages.
I agree that I would have preferred a more explicit notion of contextual principles and “work package specific” principles that are derived by inheritance and refinement from the contextual principles, and which are in turn used to vet more specific requirements (i.e., criteria that can be used to ascertain if the architecture does indeed specify a solution which is fit for purpose). My sense is that it is this latter concept of requirements that the “requirements” in the center of the ADM diagram represents, but the connection to some contextual means to “systematize” them is left unstated.
len.
Len,
I agree with you about choice of words being very important – and your point about denotations and connotations was one of the main take-aways that I got from your talk at EAC last week.
I’ve always recognised that phenomenon, but I’d never had good words to describe it before.
Sally
Len talks about a widespread predisposition to name things in arbitrary if not misleading ways. I recognize this phenomenon, and I agree we should be careful about the use of language, and to be wary of constructing a discourse that sends people down the wrong track. Putting the word “Requirement” at the centre of the TOGAF story seems to be an example where a well-intentioned choice of language has led to an unintended and perhaps unfortunate interpretation.
However, many people seem to think that the solution to this is to impose their own notions on everyone else. Thus we have endless debates on Linked-In and elsewhere about the True definition of this or that concept – what is the Correct definition of Capability or Process, and what is the Correct definition of Enterprise Architecture (or Systems Thinking, for that matter). This is what I mean by following Confucius. Each contributor to these Confucian debates is convinced that his own definitions are sound and that everyone else is arbitrary or wrong.
Obviously we can’t communicate without some common language, and we must always be alert to possible misunderstandings and differences of meaning. But I don’t think Len’s justifiable desire to be careful about the words we choose necessitates (as many EAs seem to believe) a Quixotic project to reduce all concepts to standardized terms before we can start talking in earnest.
“Obviously we can’t communicate without some common language” is very true. Although I would say it slightly different: “we need a simple, for everybody comprehensible, journey map if we want to sketch a vision”.
In my ebook in progress (download link can be found in my Twitter profile) I say this about vision:
I believe Scott McCloud when he is talking about three types of vision his TED Talk.
This is what Scott McCloud says:
A sketched journey map is a very simple medium for showing the three combined visions plus the, by the map maker(s) discovered patterns in one single image.
I have come to appreciate the value of EA as being about raising enterprise self-awareness. This requires us to recognise that an enterprise is the composite of individuals and their self-awareness and enterprise-awareness.
For me, the art of EA is about increasing the degree of alignment in mental models held by the members of the enterprise.
Said in this way, it becomes important to recognise that we each bring understandings built around language which expresses concepts we hold in our minds, with each having miniscule through to gigantic differences in our appreciation of the concepts were are dealing with.
So, my approach in EA is to attempt to appreciate how others see the enterprise, what it is that they are meaning in their use of words and language, and to facilitate a process where these perspectives are sufficiently aligned (as opposed to identical) such that the enterprise enjoys greater success.