Tom Graves / Tetradian

(This series of posts explores a concept of ‘context-space’ which in part draws on a categorisation immortalised in a certain well-known diagram. It must be emphasised that this is not about ’That Welsh Framework‘ (aka twf) which that diagram illustrates: for details on twf, please contact this company. I apologise for these absurd aliases, but regrettably their necessity has been forced upon us by others.)

We seem to be iterating steadily towards a full description of what I’ve termed context-space mapping (as a more permanent name than the temporary label ‘tinc‘). For example, there’s been some very useful discussion on the previous post, especially by enterprise-architects Paul Jansen and Sally Bean. Paul Jansen followed this up with another Tweet:

@tetradian May the ‘chaotic approach’ be the key to #tinc? http://bit.ly/amJa1o

In fact this leads to what is probably the fundamental difference between twf and context-space mapping (aka tinc): the role of the Chaotic domain. This particularly applies in terms of the respective views of repeatability within the context.

In the hope of preventing yet more repercussions, I won’t say anything about twf’s approach at this point, other than to express my opinion that, in the terms of context-space mapping, its focus is primarily on the Complex domain, which in turn leads to an emphasis on contexts that are ‘partly-repeatable’ in highly complex ‘unordered’ ways.

Context-space mapping, however, needs to cover all repeatability-types. As twf’s proponent indicates, the Simple domain of presumed-repeatability is covered by Taylorism et al.; the Complicated domain of analysed-repeatability by hard-Systems Thinking and the like; and the Complex by twf and so on. But there’s so far been little or nothing to cover the Chaotic domain of ‘barely-repeatable’ events and processes. So in practice it’s likely that that’s where whole-of-scope techniques such as context-space mapping will have the most impact.

The central theme in the Chaotic domain of practice is low- to zero-repeatability: some part(s) of the practice cannot be repeated, either because the conditions have changed – including the awareness and experience of the person doing the work. Conventional ’scientific-analysis’ approaches (Complicated-domain) rely on repeatability, so they’re actually not all that much use in the Chaotic components of any real-world task – in fact will often be misleading because they provide an illusion of predictability. In a way, the same is true of many Complex-domain techniques: they give us a much more reliable picture of an overall uncertain context, but we can’t reliably apply that in reverse to tell us what to do for a specific ‘market-of-one’, such as a specific medical diagnosis.

Ability to engage appropriately in the Chaotic-domain in this sense is almost a definition of skill. It’s also a key component of almost all knowledge-work – which is why this concern is coming much more to the fore, as knowledge-work becomes an increasingly important part of the overall economy.

At the business-process level, one of the key figures is Sigurd Rinde, whose concept of ‘barely-repeatable processes’ is the focus for his Thingamy business-process-execution software. The whole point of Thingamy is that the processes themselves are made up as they go along, by the people doing the work, expressing and applying their expertise. Underneath this, however, is a consistent Simple structure that records every decision, every artefact, every transfer of responsibility – which makes it possible to create any required reports from the process, including conventional statistical analysis. The result is nicely summarised on Sig’s other website, 30megs.com – so-called from his tag-line “Here’s 30 Megs. Now go run Germany”, which in principle is entirely feasible with this kind of decision-support/decision-tracking software. Sig is not alone in this, of course – for example, Stafford Beer developed something similar that in effect ran the entire economy of Chile for a while, way back in the early 1970s – but Thingamy is probably the best example of a software package available today that is designed for true Chaotic-domain processes.

Context-space mapping is part of what needs to happen before we settle on any technique or tool such as Thingamy. It’s about mapping the options available to us, and the decisions that we make within ’solution-space’, as part of an overall process of sensemaking in order to arrive at appropriate actions for the context. One of the key points in this is an awareness that we are part of the context, part of the ’solution’: in the classic Chaotic-domain sense, there is a boundary, and there is no boundary, always in the same moment.

We always start from ‘reality’ – that which in twf is termed the ‘disorder’ domain. (Everything does in fact take place within that domain: any purported subdivisions – such as Simple, Chaotic and suchlike – are sensemaking-abstractions that we place onto that domain, but are not actually ‘real’ as such.) From there, we would move into some kind of recursive OODA loop (Observe/Orient/Decide/Act), where sensemaking itself forms one or more of the earliest iterations. In those terms, context-space mapping would typically proceed as follows:

• Observe: What is ‘the context’ here?
• Orient: How do I make sense of what I’m seeing?
  1. What parts of the context appear to be unique (Chaotic), unordered or ‘wicked-problem’ (Complex), complicated but repeatable (Complicated) or universal (Simple)? Using that categorisation, map out the ‘problem-space’.
  2. Given that categorisation, what cross-maps would be useful for sensemaking?
     Note: There are an infinite number of cross-maps that could be used: some examples shown in this series include:
     • here: repeatability and action-tactics; domains and tetradian asset-dimensions; time versus focus; Jungian domains
     • here: twf tactics and types of practice; timescale versus ‘bindedness’; development of embodied ‘best-practice’
     • here: repeatability and ‘truth’; marketing versus sales; the ‘plan / do / check / act’ cycle
     • here: ISO-9000 quality-model; skill-levels; automated versus manual processes; asset-types; data, information, knowledge, wisdom
     • here: cause/effect relationships; decision-mode, timescale and level of abstraction
     • here: nature of boundaries between domains
     • here: phases of matter
  3. Using the categorisations from the cross-maps, what available tools and techniques are ’situated’ in what regions of the maps’ ’solution-space’? What can we learn from this?
• Decide: Given what I have learned from sensemaking, what should be my ‘action-plan’?
  1. Select from the available tools/techniques.
  2. Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
• Act:  What am I doing as I am doing, and what do I see as I am doing?
  1. Enact the desired action.
  2. Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, further sensemaking, decision and action.
• Repeat as appropriate.

(Some people might suggest that this kind of OODA-loop fits more within a twf-style Complex-domain mode than Chaotic-domain. True, there are important similarities, such as the shared focus on ‘unorder’ versus the Complicated/Simple notion of ‘order’. But the key distinction is that this acts on a single, individual, specific context rather than a Complex-domain collective – and is often also much closer to real-time than most Complex-domain decision-making.)

The above is a start towards how we would use context-space mapping, anyway. I’ll leave it there for now: any constructive comments, ideas and suggestions would be most welcome, as usual – over to you?

Previous posts in this series:

• Complexity, chaos and enterprise-architecture
• More on chaos and Cynefin
• Alternatives to the ‘Cynefin’ term, please?
• Solution-space: beyond Cynefin?
• On meta-methodology
• Using ‘Cynefin-like’ cross-maps
• More ‘Cynefin-like’ cross-maps
• And more ‘Cynefin-like’ cross-maps
• More on meta-methodology
• ‘tinc’ – a Temporary Inconvenience
• Context-space mapping and enterprise-architecture

Related:

• ‘Two Cryptic conversations‘

The previous posts on ‘chaos and Cynefin’ were intended to contribute to an ongoing debate about how to use concepts from the published Cynefin framework and the like, and particularly to underpin a systematic exploration of what many Cynefin aficionados would describe as the ‘Chaotic domain’. It’s evident that there’s a real perceived need there, because overall I’ve so far had several hundred reads, several dozen re-Tweets (particularly via knowledge-management thought-leader David Gurteen and management-consultant Paul Jansen, for which many thanks), and a lot of constructive comments and feedback – all of which have been very helpful.

Unfortunately, as can be seen from his comments to those posts, one person who was definitely not happy about such ideas was the originator of Cynefin, Dave Snowden. So there’s evidently a major problem for us there.

What is clear is that, whether Dave likes it or not, a substantial community already uses Cynefin concepts and Cynefin terminology to describe a kind of meta-methodological ’solution-space’ within which various methods, methodologies and tactics can be situated, and their respective appropriateness for specific contexts can be assessed. What’s also clear is that, as far as Dave is concerned, we are no longer permitted to use the term ‘Cynefin’ for this ‘framework-that-occupies-much-the-same-conceptual-space-as-Cynefin’: we do need to find an alternative term for this.

In short, to describe that ’solution-space’, it seems we now need to move beyond Cynefin.

To do that, we need to identify:

• the role and purpose of this ‘not-Cynefin framework’
• how it draws from the published Cynefin framework and/or common usages of that framework
• how it extends and/or differs from the published Cynefin framework
• summarise how this framework would be used in practice

Once we’ve done that, we can perhaps start looking for an appropriate alternative term to describe it.

This is again going to be long, so I’ll stop here for a moment with a ‘Read more…’ link.

Read more…

Apologies: this is going to be another long one, and probably more technical than most people want to see (especially at Christmas? ). But I do promise that it’ll be useful to you if you’re interested in methodology of any kind; and I also promise that despite the problems that arose from the last couple of posts here, it won’t be an angry rant.

The point I’m trying to address here is this: what methodologies do we need to use to assess the validity of methodologies? As with the previous posts, this is still very much a work-in-progress: there’ll necessarily be a certain amount of ‘feeling my way’, and almost certainly a few mis-steps along the way. So please do allow me some room and leeway as you read this; and also, to get the best out of this for yourself and your own work-context, please do expect to have to do some in-depth thinking and cross-correlation of your own.

What I’m trying to tackle here are some of the most complex and paradoxical problems in the methodology of methodology itself: none of this is ‘kiddies’-level’ stuff, and you’ll need a solid background in theory and practice of methodology before you can make much sense of it. So please don’t assume automatically that I’m ‘wrong’, or that I’m some kind of religious nut, because you’ll miss the whole point of this if you do. This does also need to be a collective development, so as before, constructive comments and criticism would be most welcome!

Read on, anyway.

Read more…

It started, as these things so often do, with a Tweet on Twitter.

(This has turned out to be an enormously long post – I’d better put a ‘Read more…’ link in here before continuing.)

Read more…

Spent part of last weekend at the annual conference of the British Society of Dowsers – the folks who do water-divining (‘water-witching’ in the US) and similar skills. I’ve worked with them at various times over the past thirty or more years, and as writer I’m probably best known in that field, with some half-dozen books to my name on various aspects of the subject. But although I do know how to do it, and have done some useful work with it in my time, I wouldn’t describe myself as much of a dowser these days: more a theorist or methodologist, really. My real interest there is that it’s one of the best test-cases for identifying the processes by which people learn judgement and awareness – the key components that are common to every skill.

Being an ‘alternative’ field, dowsing does suffer from more than its fair share of kooks and flakey ‘New Age’ types, but at present there’s a much stronger emphasis on practicality, professionalism and discipline – hence my book on Disciplines of Dowsing that I co-authored last year with archaeographer Liz Poraj-Wilczynska, and a set of related articles (see summary [PDF]) that we wrote for the society’s journal, which was the reason why I was at the conference. An interesting bunch.

So for me it was no surprise to find some innovative ideas there – some of which were definitely relevant to other fields, including business-architecture and enterprise-architecture.

One which bridged the gap between dowsing and technical world was a lovely Google Earth ‘mashup’ by Hugo Jenks, linking traditional dowsing techniques to current GIS (geographical information systems) with a purpose-built embedded-controller and an ingenious software hack. One of the standard dowsing techniques uses a single horizontal rod with a vertical handle as a mechanical amplifier to highlight small hand-movements. Hugo had made up a version of this with twin sensors to record the deviation either side of straight-ahead (the dowsing ’signal’); he then fed this in real-time into a laptop which also had a GPS card to record position. A button on the dowsing-rod handle could also be used to trigger a GPS ‘waypoint’ marker to record specific key points of interest. With this array, he was then able to map the signal – again in real-time, if required – onto Google Earth, as a direct trace of response. A simple grey-scale indicated response-intensity, using a mid-grey as neutral, with white and black as the two extremes. The demonstrator video showed a clear mapping of below-surface structures on an archaeological site. Given the increasing use of dowsing in archaeology as a rapid non-destructive survey technique, this looks to be a really useful addendum to that toolkit – especially as this approach enables us to do away with the cumbersome stick-and-string survey-grid typical of many site-surveys, and also allows arbitrary granularity of search. Interesting.

Somewhat earlier I’d had a lengthy conversation with an engineer (whose name I forgot to record, much to my chagrin) about Stafford Beer’s Viable System Model – one of the cornerstones of systems-theory in organisations, that I reworked into a whole-of-enterprise ‘viable services model’ for my book The Service-Oriented Enterprise. This guy had done his Masters degree with Raul Espejo – Stafford Beer’s right-hand man on the Cybersyn whole-of-nation information-system in Chile in the 1970s – so was able to tell me a lot more about that ground-breaking work on organisational complexity.

Finally, an excellent conversation with an architect (Elizabeth Phillips or Catharine Fortlage, I think?) about physical architecture supporting organisational architecture, and the need to link the organisational silos or ‘tribes’:

Design the floor-plan to be like a wandering path through the jungle; each tribe has its own patch, its own personal space, yet there are shared ‘watering-holes’ – neutral spaces owned by everyone and no-one – where anyone from any tribe may meet any other.

This reminded me of some work we did a few years ago with state-police in Australia, where our brief from the executive was to create a metaphoric ‘totem pole’ to “unify the tribes” within the police-force itself. That conversation pointed me to the burolandschaft (literally ‘office-landscape’) movement of the 1950s; then to a really useful 1993 article – “A Vision of the New Workplace” – on the impact of management-theories such as Business Process Reengineering on office-design; and thence to ‘Origins of the Office’, another useful resource on working environments, office paradigms and interplay between management-theory and workspace, embedded in a website by architects Caruso St John for the Arts Council of Britain.

The moral of this story? Innovation and ideas can arise from anywhere, and the most useful ones often arise from unexpected places. As Louis Pasteur once put it, “in the field of research, chance favours the prepared mind”; if we only allow ideas to come from the expected places, we’re limiting our chances!

After the sour taste of the McAfee farrago, it’s been a real pleasure to come across some solid fact and solid sense on ‘Enterprise 2.0′, from renowned usability expert Jakob Nielsen. (Thanks to Oscar Berg and others for the link.)

Nielsen’s ‘Alertbox’ post on ‘Social Networking on Intranets‘ summarises his team’s extensive research on how so-called ’social software’ is actually applied within real-world enterprises. Perhaps the most important point that comes out of that research is that McAfee’s definition of ‘Enterprise 2.0′ is either flat-out wrong, or too misleading to be usable in practice. McAfee, and, of course, all the vendors on McAfee’s ’social software’ bandwagon, assert that the tools should be the centre of all attention; but as Nielsen demonstrates, the tools are actually almost peripheral [emphasis as in the original post]:

People instinctively latch onto specifics to illustrate broad concepts. With Web 2.0 ['Enterprise 2.0' in this context], the specifics are the tools. … But in truth, social software isn’t really about the tools. It’s about what the tools let users do and the business problems the tools address.

A uniform finding across all of our case studies is that organizations are successful with social media and collaboration technologies only when the tools are designed to solve an identified business need. … Although picking the tool to support the need sounds obvious, it runs contrary to the technology fetishism that characterizes much talk about the latest Internet fads.

So, rather than saying: “[tool] X is hot on the Web, let’s get it on the intranet,” say: “We need to accomplish Y; can X help us?”

In other words, the focus must always be on the business needs and the human issues – not on the tools. (Hence the importance of business-architecture and a true ‘architecture of the enterprise’, to identify business needs and existing business capabilities.) And Nielsen also warns that:

An old lesson that holds true with social software is that a bunch of stand-alone tools will provide a disconnected user experience, causing employees to waste inordinate amounts of time moving between environments. For more than a decade, we’ve talked about the need for a unified intranet user experience, consistent design, and features organized around humans rather than technology. All still true.

The other key issue is communication within the enterprise, in the broadest sense of both those terms [again, emphasis as in the original]:

Widespread use of internal social media breaks down communication barriers. That sounds good, but it can threaten people accustomed to having a monopoly on information and communication. Ironically, corporate communications departments sometimes resist the move to broader communication. They’re better served, however, in finding ways to increase the value of new media rather than in trying to suppress it.

Corporate communications must adapt to social media’s real-time culture and become much more proactive than in the past. Procedures that required days or weeks for approvals need dramatic streamlining, or the story will run away on its own. Yet again, business and organizational change is what it’s about, not just the “2.0″ tools themselves.

Nielsen’s research also indicates that behind communication – or lack of it – lies corporate culture, hence a few interesting warnings about the dangers of ‘control’:

Before implementing intranet collaboration tools, you must consider company culture. If people are strongly committed to the “knowledge is power” tenet and don’t want to share, then sharing technologies will obviously fail.

It can be unnerving for traditionalist executives to see employees freely discussing company strategies. But loosening control of information on the intranet is a way to control a much bigger risk: that employees will spill the beans on Internet-wide social media. When people have internal media at their disposal, they’ll post their questions and comments there, as opposed to going outside.

And finally, a reminder that, perhaps unlike what happens on the Internet, changes in the corporation must be allowed to take their own time:

When you consider that successful adaptation of Enterprise 2.0 tools requires the organization to change its ways, it becomes clear why these projects don’t happen overnight. Yes, pilot implementations can go live in a matter of days, but the political and cultural changes needed for useful and widespread use take longer.

Although there’s no single answer, across our case studies, 3–5 years seems to be a common timeline for social intranet projects. This is a good time to remind you of the French general: when told that it would take a hundred years for newly planted trees to grow big, he said, “better get started now.”

If you want to know more about how ’social software’ really works in a real-world context, go read the whole post: very strongly recommended.

I’ve just uploaded to the Tetradian Books website the ZIP archive of the Visio stencil and template for the function-model process described in the Service Oriented Enterprise book I published a few days ago. The archive includes:

• Visio 2003 stencil for function-models: shapes for Function/Activity, Business System and Dependency
• Visio 2003 template for the stencil, creating a default base-document
• Word 2003 instructions-document (an edited extract from the Services book)

More detail at http://tetradianbooks.com/2009/01/services-model/ , if you need it.

Share and enjoy?

Diana Stobart Wild’s other question on the LinkedIn business architecture forum was about frameworks:

What is Business Architecture? What does a Business Architecture Framework look like?

I think of Business Architecture as a subset of Enterprise Architecture that describes the business from the Strategy down to the enterprise business models (process, data, business rules, etc.). Business parts of the Zachman Framework? Thoughts? Comments?

My response was as follows:

I’d agree that Business Architecture is a subset of Enterprise Architecture, as long as you don’t fall for the TOGAF-style trap of thinking that enterprise-architecture is only about IT!

Business-architecture proper is the strategy layer (Zachman row-2 and upward, also bridging down into row-3).

The jumbled mess of what’s otherwise called ‘business architecture’ only exists because TOGAF and the other IT-centric ‘EA’ frameworks essentially used the term as a generic dumping-ground for ‘everything not-IT’. Instead, think of the remainder of what TOGAF calls ‘business architecture’ as two distinct layers: the logical or integration layer – the equivalent of TOGAF’s ‘Information Systems Architecture’, Zachman row-3 to row-4 – and the physical or implementation layer – the equivalent of TOGAF’s Technology / Infrastructure Architecture, Zachman row-4 to row-5.

Zachman’s structure of layers still works fairly well for this – the only essential change is an extra ‘row-zero’ for compatibility with the Vision layer of ISO-9000:2000. But it does need some serious rework on the columns: for a start, there’s an entire dimension missing, to handle distinctions between physical assets (things), virtual assets (data etc), relational (what your CRM is all about!), aspirational assets (morale and the like), and abstract (such as the financials that your business people do want in their models!); the same for locations (physical, virtual, relational etc) and so on. Still a month or a so away from finishing my book on this, “Bridging the Silos”, but see the ‘Framework’ chapters in the current draft at http://tetradianbooks.com/2008/04/silos/ .

One point that Zachman did get right, but most of the EA-toolset vendors seem to have forgotten, is the key distinction between primitives and composites. As Zachman says, architecture is about primitives (TOGAF’s ‘Architecture Building Blocks’, or ‘ABBs’), whilst solutions come from composites or patterns (TOGAF’s ‘Solution Building Blocks’, or ‘SBBs’). The Zachman Framework is a taxonomy of primitives – root-level entities, some of them fairly abstract; composites are structured collections of primitives that straddle the columns, making up patterns for re-use.

Composites are usable to the extent that they’re architecturally ‘complete’ – i.e. straddle all of the columns – but are re-usable to the extent that they’re incomplete: for example, a BPMN process-model says nothing about ‘Where’ or ‘Why’, so can be re-used in different locations and (in principle) for different purposes. At the mid-layer of the framework, you need to be able to describe a process in abstract terms, to identify KPIs and CSFs and so on; you’d define different SLAs as you go down towards different implementations – manual, machine, IT, etc, but they should all use the same KPIs etc. This is important because if you’re not able to anchor the detail-layer composites into their component sub-composites, all the way down to their root-primitives, you won’t be able to see options for redesign, such as for disaster-recovery or process-reengineering. Think of the classic IT-centric blunder of assuming that every problem must always have an IT-based solution… your only way to avoid that trap is to use a non-IT-centric framework that covers the true whole-of-enterprise space.

Over the past few years I’ve done quite a bit of work on a ’service oriented enterprise’ framework, based on the classic Stafford Beer ‘Viable System Model’ – see the Wikipedia summary at http://en.wikipedia.org/wiki/Viable_System_Model . We extended this at Australia Post and elsewhere to include support for quality-systems, security-management and so on. Again, there’s still some way to go, and the book is probably at least six months away, but there’s a summary in my article on the service-oriented enterprise in the current itSMF “IT Service Management Global Best Practices” book (see http://www.vanharen.net ) and in my presentation to the TOGAF Glasgow conference back in April (see PDF at http://www.tetradian.com/download/togaf_ea-soe_apr08_FV.pdf ).

Been following a ‘business architecture’ thread on LinkedIn, and came across a couple of discussion-questions by Diana Stobart Wild, who seems to be an enterprise architect somewhere in the north-east US. Thought it might be useful repeating here what I wrote there, as it’s all fairly generic but does summarise my current approach to business-architecture.

Her first question was on business-architecture tools:

Which tools are in the Business Architect’s toolkit?

to which I replied as follows:

If you come from an IT-centric architecture background, the first need is to realise that the standard EA view of business-architecture is a mess – it’s essentially a random grab-bag of ‘everything not-IT’. So you need first need to sort it into the business equivalents of TOGAF or FEAF’s three layers, such as:

• strategy and policy (real meaning of TOGAF’s ‘Business Architecture’ – Zachman row-3 and above)
• tactics and system design (equivalent of ‘Information-systems Architecture’ – Zachman row-3 to row-4)
• process implementation (equivalent of ‘Technology Architecture’ – Zachman row-4 to row-5 [and, in past tense, row-6])

For the strategy layer, one obvious tool is BRG / OMG’s Business Motivation Model [PDF]. It has some flaws – particularly its dangerous mishandling of ‘Vision’ – but it’s a good starting-point. Several EA toolsets implement the BMM, though sometimes under different names: for example, IBM/Telelogic System Architect calls it the ‘Enterprise Direction’ model.

For the middle systems-layer, to be honest, I don’t know: we’ve been doing a lot towards modelling that space – see my book “Real Enterprise Architecture: beyond IT to the whole enterprise”, at http://tetradianbooks.com/2008/04/real-ea/ and the current draft of “Bridging the Silos: enterprise-architecture for IT-architects”, at http://tetradianbooks.com/2008/04/silos/ – but there’s still a fair way to go yet. Troux’s ‘Metis Enterprise Architecture Framework’ covers [covered? it may not still exist...] a lot of the space, but as usual ends up being too IT-centric for real business-architecture use. Even so, Troux is probably the best bet at present: in my experience, to be blunt, most of the other well-known EA toolsets are so obsessively IT-centric that for business-architecture they often seem more of a hindrance than a help.

At the process level, there are plenty of tools and models available, many of which are not inherently IT-centric, such as all the IDEF and TQM and Six Sigma toolkits. Some IT-centric tools can be re-used in a non-IT-centric way, too: you can use BPMN for implementation-layer business-architecture modelling, for example, once you realise that the Process entity doesn’t care how it’s implemented unless you really need to translate across to BPEL; and the ‘Data Object’ entity doesn’t need to be data, but can actually be any type of asset – physical, virtual, relational or whatever.

Another tool I’ve found invaluable for understanding complexity in business-architecture, and the boundaries between what can and can’t be handled by IT, is Cynefin – see the Wikipedia summary at http://en.wikipedia.org/wiki/Cynefin , also Snowden, D & Boone, M “A Leader’s Framework for Decision Making” Harvard Business Review November 2007.