Link: http://weblog.tetradian.com/2013/06/17/at-ea-st-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?
