Archive

Posts Tagged ‘taxonomy’

More on EA and asset-types [2]

November 6th, 2011 No comments

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the previous post in this series, we looked at the concept of four distinct asset-dimensions: Physical, Virtual, Relational and Aspirational.

The same dimensions carry right the way through the entire architecture. We can see this if we map it as per the ‘service-content checklist’ from Enterprise Canvas, which can also be understood as a much-extended adaptation of a single row from the Zachman taxonomy:

The asset-dimensions are kind of orthogonal to the dimensions represented by the Zachman-style ‘columns’. For this we’ll keep the emphasis on the columns to which these dimensions map directly: Assets, Functions, Locations, ‘action’ and implicit ‘actor’ component of Capabilities, and Events.

[The mapping comes out in a related but somewhat different way in the Decisions/Reasons column and the 'skill-level' component of the Capability column, which I won't go into here.]

On assets themselves, we’ve already covered the fundamentals in that bullet-list from the previous post:

  • physical: physical ‘thing’ – independent, tangible, transferrable, alienable
  • virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
  • relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
  • aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

We need to handle and manage assets in accordance with the respective dimensions: management in terms of storage, security, access, natural-lifecycle, refresh, migration and so on.

It’s all fairly straightforward territory for enterprise-architects; the only real complication is that many entities are or represent composites of dimensions, which means that they need to be handled and managed in accordance with the rules for all of the respective dimensions. A printed book is one simple example:

  • book as physical-asset (object): physical storage, ownership-title, inventory-control, access-control, instance-identification, maintenance, repair, physical disposal etc
  • book as virtual-asset (information): data-storage, copyright, copy-control, access-control, version-control, validity, review, renewal, metadata, indexing, withdrawal, secure-deletion etc

Just to make it even more fun, the combinations of those composites can change, too, in response to events, the CRUD actions in functions, sometimes in different locations, and even through natural deterioration or depreciation within the lifecycle.

[There's a lot more to explore about the detail of this, but I'll do that in another post: for here I want to concentrate on the way the same principles go across the whole architecture.]

Hence, yes, can be a bit mind-bending at times: but taking a dimensions-approach – using the dimensions as ‘lenses’, if you like – really does help.

In the broadest sense, functions act on assets: they describe the activities that apply CRUD-type changes and the like to assets. Hence, again, we have different dimensions of functions – actually the same dimensions – that act on those respective dimensions of the assets.

We have functions that create, use, change and destroy physical objects, or physical attributes of objects.

We have functions that create, read, update and delete information and other virtual-assets or virtual attributes of entities.

We have functions that help people create relational-links with each other; remember existing relational-links; refresh those links, or provide conditions under which a link can sort-of be transferred to another person, such as in a shop, or an escalation at a call-centre; and although relational-links in effect delete themselves as soon as either party drops it, we have functions which can either assist that to happen, or to dissuade it from happening,

And we have functions that help people create aspirational-links – for example, to connect with a brand. We have many, many functions – most advertising, for example – that help people refresh and renew and reconnect with their aspirations in context of a brand or some other aspirational-link ‘target’: in other words, ‘read’ an aspirational-asset, the aspirational-link itself. We have a suite of functions to get people to ‘update’ the aspirational-asset link – for example, to get someone to change loyalty from a competitor’s brand, or to support ‘upsell’ to a more upmarket brand of our own. And for a few special cases, we have functions that aim intentionally to destroy an aspirational-asset – such as when a brand comes to the end of its life, yet we have no replacement, and we don’t want to upset existing customers of that brand.

And, as before, there will be functions that interweave any or all of these dimensions at the same time. But it’s useful to be able to tease all of the threads apart where necessary – not least because a re-implementation of a function in a different form could lose or gain key aspects of dimensions that we might otherwise not realise were there in the previous form.

Thinking of relational-links and aspirational-links as assets, in exactly the same sense as for physical- and virtual-assets, can sometimes be a bit of a mindstretch: but because it allows us to address all asset-types – and what we do to and with all types of assets – in exactly the same overall way, it really does simplify the architecture-frame a lot. And as we’ll see in a moment, it also brings a new clarity and new simplicity to service-oriented architectures, right up to a whole-enterprise scope.

Stop there for now: in the next post we’ll look at how this applies to locations and events.

More on EA and asset-types [1]

November 5th, 2011 No comments

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

[I know I usually write too long, so as a kind of trial-run, I'm splitting up this original long-post into four smaller ones: please let me know if this works better for you? Thanks!]

This one is a sort-of follow-up to the earlier post ‘Charisma, connection and brand‘, which looked at two lesser-understood asset-types, relational and aspirational. It’s also a pick-up on the article pointed to by the following Tweet, with my explanatory comment attached:

  • SAlhir: Brand vs. product: what really drives reputation? http://bit.ly/sLf4hs >actually, she says, it’s neither: it’s delivery on promise that matters most – agree.

I usually define an asset as “anything that the organisation uses and/or is of value to the organisation, and for which it is responsible”. In essence, if we can do some form of a CRUD (Create, Read, Update, Delete) to it, and the organisation ‘owns’ it in a stewardship sense at least, then it’s an organisational asset – and hence relevant to the architecture. So this is deliberately broader than the usual definitions of ‘asset’, to enable the architecture to cover the full range of assets, both tangible and intangible.

Overall, there are four different types, or more precisely, four distinct dimensions of assets:

  • physical: physical ‘thing’ – independent, tangible, transferrable, alienable
  • virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
  • relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
  • aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

So any asset may be or represent not just one of these dimensions – i.e. as an ‘asset-type’ in the same sense – but also a composite of any combination of these dimensions, a combination which may well change over time for the same nominal entity. Hence I often map this in tetradian form, the inner axes of a tetrahedron:

Most business looks only at the physical and/or virtual dimensions, because, being transferrable, that also represents something that can be sold. But it’s the interactions of all of those dimensions that makes it all happen. Consider this in terms of the market-cycle:

Almost by definition, if we’re dealing with business-type Operations, the focus is mainly on saleable, exchangeable physical and/or virtual. Yet even there, whenever real-people are involved, it’s going to imply some aspects of relational and/or aspirational.

In the Tactics space – the start and end of the core sales-process, for example – it’s definitely going to involve relational-links with real-people, and aspirational-links around desires.

Further out, into Strategy, most of the core concerns will revolve around the aspirational-links that underpin reputation and trust.

And if we don’t manage all of those less-tangible dimensions properly, and manage all of the completions properly, the cycle is going to break – yet we probably won’t be able to see or understand why it’s broken. Which means, very quickly, a dead business. Hence this isn’t some trivial ‘academic exercise’: this is absolutely fundamental to all forms of business-architecture and the like. Yet many of the nominal enterprise-architects or business-architects I meet don’t seem to know about any of this: they just point at the financials, for example, and think that that’s the answer to everything. Which I must admit I do find worrying, to say the least…

[Notice that, unlike many conventional models, there isn't a distinct category here for financial-assets. This is not an error, because in this schema we don't treat money any differently from any other asset. A financial-asset is, in effect, a composite of virtual-asset (the information carried by a monetary value, which in itself is usually stable) plus aspirational-asset (the belief in the value of that asset, which can be highly variable), plus also physical-asset if the monetary-value is expressed in the form of cash or some other physical entity.]

The point is that each of these dimensions indicates different requirements for handling: physical cash needs to be handled as a physical-asset, whereas a data-record of the same monetary-value generally doesn’t (other than in terms of its storage or transport within a disk-drive or network, which is a different physical-asset). They’re also worked on in different ways in different functions and by different capabilities, have different event-types, have their own distinct location-schemas and so on – and yet they all interweave with each other in practice in ways that can be mind-bogglingly complex.

Yet architecturally speaking, if we allow ourselves to become confused about what type of asset we’re dealing with, or which dimensions we’re dealing with in each context, we’re going to get into serious trouble. This is especially true if we build a business-model on incorrect assumptions about asset-types – as the media-industries discovered to their cost in the shift, for delivery of music and film and text, from physical/virtual-bundling (a music-manuscript or disk, a cinema-seat, a physical book) to virtual-only (digital data).

So as I understand it, it’s part of the architect’s job to sort it all out, and prevent it from twisting itself into an unmanageable tangle. Hence this post, and others like it.

In the next post, we’ll explore how this same principle of ‘asset-dimensions’ echoes across the entire scope of the architecture.

Helping others make sense of my work

November 2nd, 2011 17 comments

Have been struggling hard for the past few days with a truly brilliant challenge from Bulgarian enterprise-architect Ivo Velitchkov, when he dropped by for a visit near here over the weekend. And I’d have to admit I’m no nearer solving it as yet. Hmm…

His point is this: there’s a huge body of knowledge – or something like that, I guess? – that’s scattered throughout this website, in my books, on the Slideshare account, and various other places too. But there’s so much of it, spread across so many different themes and topics, with ideas developing and changing over the years: so how on earth can anyone make sense of it all? How does it all tie together? What links with what? What’s changed, what hasn’t changed? And how do we use it all, anyway?

Looking around, fact is that he’s right: I need to apply a bit more enterprise-architecture to my own enterprise-architecture here. Rather than just churning out the work, day after day, more and more new ideas, new concepts, new connections, I need to do more to help people make sense of those ideas in context, and to put them to practical use.

So I’ll make a quick start here, with a brief summary of how the various sources fit together. But for the rest, I’ll need you to help me to help you – if you see what I mean? :-)

This weblog is where most of the visible action happens. Its main role is to present ‘work in progress’, and to ask for comment and feedback to guide that work-in-progress. The good part is that this is where you’ll find whatever I’m working on at the moment – always pushing the boundaries, which I hope is significant for a fair few people at least. The catch is that, almost by definition, what you’ll see here isn’t likely to be in ‘finished’ form. It also covers a huge scope: for example, that ‘no-plan Plan‘ for an extended view of enterprise-architecture is just one small part of it. So it’s very fragmentary, and there’s a lot of it – more than 500 distinct articles so far, excluding background admin items and the regular collections of ‘A week in Tweets’. And I’ll admit the search-tools here aren’t good: a small set of categories, a subset of tags, and a very simple text-search field. Making sense of what’s going on here isn’t easy, especially for someone who’s just dropped in for the first time: so yes, I need to do more to make it easier. Yet what do I need to do?

The books are ‘finished work’, of course. Each book addresses a single issue or theme, and can be used as a standalone item in its own right. Yet other than the barest set of categories, there’s not much there to show how they all link together – which they do, even across the categories. For example, the main purpose of the screenplays and stories is to illustrate ideas that are often too abstract – or, in some cases, too challenging – to explain other than through some form of fiction: yet in essence they’re still the same ideas as in the overall theme of enterprise-architecture. Likewise the books on dowsing: although some people don’t like the fact, they do actually describe the process and practice of sensemaking in some of its most extreme and most concrete forms. But again, making sense of those cross-connections isn’t easy or obvious: I need to do more to make it easier for it to make sense. Yet what would that be?

I probably don’t make enough use of the Sidewise weblog. It’s sort of halfway between this blog and the books: complete standalone articles that address a single theme. More like a story-bank, I guess – or an idea-bank, perhaps? It’s there, anyway: though I do need to explain more about how it links in with everything else. Yet how?

The slidedecks are likewise ‘finished’ – though without the context of the respective conference or whatever, they often seem a bit incomplete. It’s probable I ought to record a sound-track for each: perhaps you might let me know if that would help?

Then there’s the two ‘official’ websites, the Tetradian website and Tom Graves website. Both of these are literally years out of date: at present they’re useful as historical archives, but not much more than that. It’s obvious I need to update them both, and urgently: but what would be the best approach? What do those sites need? More to the point, what do you need from those two websites?

And there’s also the SEMPER Metrics website. Its purpose is to showcase the SEMPER diagnostic, that assesses organisational ‘ability to do work’, and indicates appropriate tools, techniques and tactics to address any identified problem-areas. It even includes a fully-functional implementation of the diagnostic; but since the access-permissions mechanism still doesn’t work properly at present, I’d have to admit that there’s not much point… But it’s there, and usable, sort-of, and potentially useful to quite a lot of people, too: yet what should I do to bring it up to date, and link it in to everything else?

So I’ve spent a lot of time and effort over the past few days trying to find any tools that would help me bring all of this together into a more meaningful, accessible, usable form. Fact is that I can’t find anything that would actually work. There’s CMapTools, of course, or Compendium or Cohere; yet none of them will read in a website or weblog and help me to build an automated, self-maintaining set of concept-maps across all of the articles and other items, which is what seems to be most needed here. Any suggestions, anyone?

The key item that would seem to make sense for this kind of sensemaking would be a glossary/thesaurus, coupled with annotated links to articles and other items. Would that work?

I do have a sort of ‘wiki-engine’ that I wrote some years back that I can re-use for this purpose, though it’ll take some significant hacking to get it closer to self-updating from this weblog. Would that be worth the effort?

And what else would help you to make sense of all of this body of work? And help you to put it into practice in your own context?

Anyone have any advice / comments / suggestions for me here, please?

Many thanks, anyway.

Standing up for the value of our work

October 28th, 2011 6 comments

How do we prove the value of our work? How we defend that value against unprincipled attack? These are real questions that we all need to face, especially in inherently-’unprovable’ disciplines such as enterprise-architecture.

So let’s put these questions into practice.

Several people have asked me for a detailed worked-example of the sensemaking-technique of context-space mapping [CSM]. Recently, though, I’ve also ‘enjoyed’ yet another attack from Dave Snowden, in which he made two key assertions:

  • that the cross-map process used in CSM is not a ‘mash-up’ but a “hash-up”
  • that the entirety of CSM and, by inference, all of the other sensemaking tools and techniques that I’ve developed for enterprise-architecture and related fields are “invalid … in certain essential aspects”

He gave no evidence or reason as to why the cross-map process is supposedly so invalid as to be a “hash-up”, or any details as to what any of those purported “certain essential aspects” might be: so in essence, all we have from him is a circular ‘proof’, that it must be ‘true’ because he asserts that it’s ‘true’. This is a classic form of unprincipled-attack, one which most of us will face at some time or other in enterprise-architecture and the like.

His assertion is that CSM has no value; yet since that assertion itself has no rational basis, there’s likewise little point in trying to use any kind of rational defence. Probably the only meaningful response is ‘proof-of-the-pudding’, to demonstrate in practice that it does have value. And if it does have value – in other words, that it presents insights that had not previously been available, and might not have been available by any other technique – then, in turn, that should demonstrate that the attack does not have merit. We probably wouldn’t expect the attacker to understand this point: but it may help in our relations with others, in a more professional context.

So perhaps I ought to thank Snowden here, because he’s indicated the obvious candidate for this practical demonstration: what I’ll do here is apply context-space mapping to Snowden’s Cynefin framework.

And let you be the judge as to whether this cross-map technique has any practical value.

(This will, again, be long – my apologies…)

Read more…

More on ‘the toad in the road’

October 14th, 2011 No comments

How can we ensure that the ideas and models that we use are appropriate to the context? What methods can we use to evaluate new ideas? Perhaps more to the point, how do we protect ourselves from ideas that won’t fit in our architecture-ecosystem?

This extends the previous post on ‘Coping with the toad-in-the-road‘, where the ‘toad’ is “a clear, simple, easy-to-understand wrong answer” – in other words, something that isn’t appropriate or useful in the context.

(Again, I want to emphasise that the ‘toad’ here is an out-of-place idea or model or theory – not a pejorative description of a person!)

In general I use the idea of a ‘living system’ as my core metaphor for an enterprise – which in turn suggests other metaphors such as an ecosystem or, on a smaller scale, a simple suburban garden.

So imagine that the ‘garden’ describes the ways in which we ourselves do our enterprise-architecture. It’s a garden of ideas and models and tools and techniques – an environment for ideafarming, perhaps. Some people’s gardens might be formal, constrained, regimented, rather like that at a classic French chateau. Other people’s might be large enough to contain the kind of sweeping vistas of which Capability Brown might be proud. I’d have to admit that my own idea-space is, uh, a bit more eclectic? – the style sometimes referred to as cottage garden’, with its own definite charm and vibrancy and bright colours everywhere and occasional surprising juxtapositions, but with so much semi-intentional ‘unorder’ that some people might at first see it only as a mess. Oh well.

Whatever the style of garden, though, we need to be careful what we introduce. Some ‘good ideas’ can run rampant if they’re let loose in the wrong place: consider the damage done by now-wild rhododendrons in northern Wales, or gorse (furze) or rabbits in Australia. Which, in turn, brings us to the metaphor of the toad-in-the-road.

I like toads. We used to have one that lived very happily for years in the laundry-drain just outside the house: we had to remember to take it out of there before we did any washing, and politely put it back again afterwards. (True story. :-) ) They’re often very long-lived; some can survive drought for decades, hibernating in a little patch of damp somewhere beneath the surface, popping up again as soon as the conditions are right. And although there are some toads that we won’t want in a garden – or anywhere, really – most of us wouldn’t mind a toad that will fit in well with our ecosystem. Toads are wonderful for keeping down the slugs and other garden-pests: if we have a strawberry-patch, we definitely want a good toad. But we don’t want that toad in the road – or anywhere else where it doesn’t fit, is probably putting itself at risk in any case, and is demanding our attention when we could really do without it being there.

Hence, the same with ideas that are out of place for the context: the metaphoric toad-in-the-road.

It’s not ‘an elephant in the room’. It’s not ‘an eight-hundred-pound gorilla’, or ‘a bull in a china-shop’. It really is quite small: it’s just a toad in the road – an idea that’s in the wrong place. (If it was in the right place, it’d be back under the strawberry-patch, happily munching on slugs. Metaphorically speaking, anyway.) But it somehow looms much larger in our attention than it really is – especially when it’s sitting out there, in the road, in the way, and generally making a right old nuisance of itself. Sigh… “oh no, not again”… yep, that kind of feeling.

In the previous post, I came up with a list of four categories of toad-in-the-road:

  • the friendly toad that gets in the way a bit, but is really useful in the right place
  • the not-much-use-for-anything toad that gets a bit too much in the way, especially when it’s over-excited
  • the bloomin’-nuisance toad that we’re best off to toss out of the garden, and keep out as best we can
  • the darned-dangerous toad that we need to keep out of our space at any cost

In reality, though, there aren’t any categories as such: they’re all toads, each with their own characteristics. And in terms of working out what to do with the toads – especially those that have just arrived in our garden – it might be more useful to take a somewhat different approach:

  • what is the natural habitat for this toad? [where does this idea or model really belong?]
  • are there any seasonal concerns, such as mating-season? [where is this idea in terms of the 'hype-cycle' and the like?]
  • are there any behavioural characteristics of which we need to be aware, such as aggressiveness or excessive timidity? [in what ways is this idea promoted, and by whom?]
  • is it likely to be toxic or invasive in our ecosystem? [does this idea tend to destroy, override or block out other more-useful ideas?]

Every toad-in-the-road has its own distinct combination of these themes – and the combination will usually vary over time or context, too. Hence it’s probably more useful to take this approach than some overly-simple set of categories.

Every idea has its own habitat – the place or context where it would most naturally fit. When evaluating a new idea, a key part of that task is to identify where it claims to fit, versus its ‘natural’ fit – because often there’ll be a mismatch. In many cases, the mismatch will arise from a conflict on terminology: a term that has a specific meaning in one context has a significantly different meaning in another context – which creates a toad-in-the-road when the previous meaning is carried through to the new context.

One example from the previous post was Roger Sessions’ work on minimising ‘complexity’ in IT-systems: it’s a very good idea that does make sense in an IT-context, where ‘complex’ is a kind of synonym for ‘extremely complicated but controllable’ – but it doesn’t make sense in non-IT enterprise-architecture, where ‘complex’ means something that, by its nature, cannot be controlled. In that sense, its ‘natural habitat’ is IT: we need to ensure that it’s only used in IT, and gently dissuaded from wandering anywhere outside of that domain. We might describe that as negotiating with the toad to help it find its way home.

Some of the most useful ideas are ‘mash-ups’ – a fertile hybrid resulting from a re-mix or re-use of an idea in another perhaps-’unnatural’ habitat. Perhaps the most important point in evaluating these is that it’s technology, not science – almost by definition it can be unlikely to make sense in strict ‘scientific’ terms, because it’s doing a mix-and-match across domains. For the same reasons, evaluating such ‘mash-ups’ may require quite a lot of contextual skills and experience – a lot more than the simple logic-proofs that apply in the straightforward ‘exact-sciences’. We should also note that whilst people who are over-enamoured of science-like certainties may rail against ‘miscegenation’ and the like, fact is that ‘mix-and-match’ is an important part of evolution, and hybrids often bring vigour back into a tired environment.

We don’t have to look far to find examples of valuable ‘mash-up’ ideas: they’re common in almost every environment, though in some cases they have to be hidden for a while from the ‘truth police’ until they prove their value – the story behind the discovery of quasicrystals, which won the 2011 Nobel Prize for Physics, being one infamous example of the latter. (We also see fascinating examples in the natural world: for example, blue-tits and other small birds taught each other how to peck through the metal-foil caps on milk-bottles in Britain to get at the cream underneath.) Mixing metaphors a bit – and why shouldn’t we, in this case? :-) – we might describe this as an ‘ugly duckling’ kind of toad: we need to work with the toad to help it find out who it really is and where it would truly belong.

Some ideas are just plain wrong – often because there’s not enough rigour or muscle behind them, or because they’re a kind of sterile hybrid from the wrong kind of re-mix. This, of course, is the flip-side of ‘mix-and-match’: many of the mash-ups just won’t work in any domain. The evaluation-rules will vary according to context – science for science, art for art, and so on – so we need to take especial care when an idea bridges across domains, whence multiple and often conflicting evaluation-rules would apply.

An example of a cross-domain mismatch – also mentioned in the previous post – is the notion of ‘engineering the enterprise’, embedded in parts of the Zachman framework, implicit in almost all of Taylorist ‘scientific management’ and its derivatives, and also in many of the ideas about ‘enterprise ontology’. This notion might make sense if ‘the enterprise’ was some kind of machine: but by definition it’s a human construct – “the animal spirits of the entrepreneur” and suchlike. The only way that ‘engineering the enterprise’ can be forced to make sense is if we force people to act as if they’re machines – which rarely delivers good outcomes for anyone. Sadly, once we’ve evaluated this kind of idea and found that there really is no way it could work, the only kind thing to do is put it out of its misery: we could describe this as respectful euthanasia for the toad.

Some ideas may be too simple to survive on their own – usually the result of too much repetition in the same place, slowly wearing away all of the useful rough-edges and exceptions. Simplicity is not inherently a problem – in fact it’s often of real value when we look for a starting-point for new hybrids, or a mix-and-match to address true complexity. What we’re evaluating here is the crucial difference between ‘simple’ – which often isn’t simple at all – and overly-simplistic – which isn’t much use to anyone.

Every ‘law’, ‘rule’ or ‘regulation’ – whether scientific or otherwise – is an abstraction of some kind, a simplified version of some aspect of the real world. There are no shortage of examples: in most contexts we’re surrounded by them, everywhere we look, and there’s no question that they do usually make work and life more simple. It can become a toad-in-the-road, though, whenever anyone starts to believe that the world really does work accordance with that purported ‘law’ or whatever: because the blunt fact is that the real world is rarely that simple. If it is too simple, yes, it does still have its uses, but we need to acknowledge its limitations: we could describe this as finding a sheltered space for the toad, protected from the rough-and-tumble of the real world.

Ideas may have their own seasons – often following the ‘hype-cycle’ or some other lifecycle. For any new idea, the early part of the hype-cycle is like a breeding-frenzy – and however useful the idea may turn out to be in the longer term, we’re not going to get any sense out of anything until that mating-season is over. We need to catch the idea either before the breeding-frenzy starts, or wait until all the dust and hype settle down again.

On the IT side of enterprise-architecture right now, obvious examples include the hype around cloud-computing and IT-consumerisation and, of course, the wild proliferation of ‘certification schemes’ (or scams, as some would put it…). For business-architecture it’s all the excitement about business-models rather than business-plans. We can also see that previous breeding-frenzies around ideas such business-process outsourcing, Agile development or Six Sigma have faded back enough for us to be able to evaluate what aspects might be useful in specific contexts. But whilst the breeding-frenzy is in full flow, just about all we can do is put up large warning-signs, and hope for the best.

(By the way, that triangular symbol above is the standard ‘Migratory Toad Crossing Ahead‘ warning-sign: UK DOT 555.1, to be precise. An essential item for your enterprise-architecture office! :-) )

Ideas can be aggressively territorial – it ‘hogs the space’, blocking out everything else. Often this will be associated with a ‘term-hijack‘, where a narrow subset of a context is purported to be the whole of that context – actively blocking out any view of the rest. These types of ideas can be a serious pest, because they’re so busy claiming and defending ‘their’ territory that they can make it all but impossible for other often-more-useful species in that ecosystem to survive. When evaluating new ideas or models, we need to test for any such tendencies: these are usually typified by over-simplification or over-certainty, endless repetition of its catch-phrases, habitual attempts at term-hijack, and a strong tendency – sometimes backed by force – to redirect any straying attention back to itself.

In enterprise-architecture, the most obvious example at present is the IT-centrism inherent in TOGAF and the like, though a new ‘business-centrism’ is also now coming to the fore. In both cases the underlying driver – in addition to the rather pointless ‘need’ to dominate the entire ecosystem – is an overly-simplistic misuse of the notion of a ‘centre’ to the architecture. (In reality, there is no single centre to the ecosystem, but rather that everywhere and nowhere is ‘the centre’, all at the same time.) There are all too many other examples of the ‘territory-grab’ problem, of course, in just about every aspect of enterprise-architecture. As for tactics, we may need to put up metaphoric warning-signs – as for any idea’s breeding-frenzy – but our best approach here is to always emphasise the whole ecosystem, and adjust the structure of ecosystem as necessary to dissuade this toad’s dominance.

Ideas can be too noisy in the way they promote themselves – ‘too noisy’ in the sense that, again, they drown out out other potentially-valuable ideas, but more by actively demanding our attention rather than blocking our view of everything else. This tends to happen a lot when the hype around some new idea is building at full blast, and especially so where the idea is forcefully promoted by some charismatic figurehead. It’s difficult to evaluate any ideas at all when we can barely hear ourselves think, let alone hear about anything else…

A good example for enterprise-architecture was all the hype around the earlier versions of Andrew MacAfee’s ‘Enterprise 2.0‘. The notion of using social-network software within a business was – and still is – a good idea: but the initial over-focus on technology above everything else was plainly absurd, and describing it as ‘Enterprise 2.0‘, implying an entirely new kind of enterprise, was even worse – a ludicrous if largely-unintentional term-hijack. But again, this is only one of all too many examples: the current over-hype of ‘anything-Cloud’ is another ‘noisy toad’ that we’re dealing with right now. Probably the best tactics here are to block out the sound where necessary, and emphasise our other senses instead.

Some of the most useful ideas may be too quiet for us to notice – the converse of ‘too noisy’. There are a lot of good, useful ideas out there: but they’re often so diffident and quiet that it can be difficult to identify their potential value to our ecosystem when we find them, or even to find them at all.

For me, in enterprise-architecture, one example would be Nigel Green‘s VPEC-T. Another would be the stream of ideas on sensemaking and the like on Cynthia Kurtz‘s StoryColoredGlasses website, and especially her crucially-important concept of ‘unorder’; which leads in turn to the work on business-story work by Shawn Callahan and colleagues at Anecdote. Everyone has their own examples, no doubt. But given the cacophony and near-chaos that’s always around us in the idea-garden, we do need to make a deliberate effort to understand the deeper needs of our ecosystem, and keep our eyes and ears and other senses open for the ‘the quiet ones’ that often matter most.

Some ideas are naturally toxic – they make it impossible for other ‘competitor’-ideas to thrive, or even survive, in that context. These are the cane-toads of our idea-garden: and whilst any idea can be toxic in some sense, it’s especially common with out-of-place paradigms, because by definition they purport to be a complete or final ‘the truth’ about the whole of a ‘world’ – and hence will always attempt to exclude every other possible view. When evaluating new ideas, we need to note how much they depend on asserting that something else is ‘wrong’ – and if so, why. We also need to identify the contexts to which it does apply, and which it doesn’t – because any ‘territory-grab’ beyond its natural context will automatically tend to make it toxic to other more-useful ideas in that broader space.

There’s a subtle point to watch here. In a sense, any idea that’s over-territorial or even over-noisy is sort-of-toxic: it will certainly tend to block out everything else, for a while at least. But in the case of ‘cane-toad’ ideas – truly toxic ideas – it’s not a behaviour as such: more that they poison everything, just by their very existence. As I said in the previous post, we probably don’t have many true ‘cane-toads’ in enterprise-architecture as such – though IT-centrism certainly comes close – but in the broader business sphere and beyond, such ‘cane-toads’ definitely do exist. Examples include the near-feudal concepts that still dominate most management-models; the absurd over-obsession with money as a measure of value in business; the insanely-inadequate notions of ‘economics’ on which our world supposedly depends; and, going deeper, the dangerous delusions of ‘rights’ and, deeper still, the all-pervasive, ever-pernicious paradigm of possession. (Those last are so toxic that, to be blunt, we need to kill them off before they kill us all…)

We do need to careful not to harm something that’s simply out of place, so for most ‘cane-toads’ the preferred tactics would be to isolate and remove, and publish warnings to other ‘gardens’ about the risk. Yet for any lethally-toxic toad – one that poses an existential threat to every ecosystem – the only safe tactics are to eradicate and exterminate entirely: and we do need to face up to the fact that on rare occasions that is the only option we have.

Many ideas can hibernate, re-emerging whenever the conditions seem right – and we need to note that this applies even to the most toxic of ideas. Every ‘toad in the road’ is “a simple, clear, easy to understand wrong answer”: and because they’re simple, because they seem clear, and because they’re easy to (sort-of) understand, that tends to make them very attractive, and very popular. Which means that despite the fact that they’ve long been identified as a ‘wrong answer’ – in some cases a ‘wrong answer’ for any question – they still on keep coming back, and coming back, and coming back, like a toad re-emerging with the rains after a drought. The catch with ‘idea-toads’ is that they often change their surface-appearance each time: but underneath it’s the same mistakes, the same old shallow, stupid, over-simplistic ideas – hence that dread feeling of “Oh no, not again…”.

For our discipline, probably the classic example is Taylorism – or rather, the vapid belief beneath its supposed ‘scientific management’ that everything can successfully be made subject to a simplistic sense of ‘order’. We know it doesn’t work, other than in quite narrow and clearly-constrained contexts: that fact has been proven time and time again, not least by Deming and others at the ‘front-line’ of production and elsewhere. But the same mistake still keeps coming back, time after time, for the simple reason that people want to believe in the myth of ‘control’. Hence, for example, Davenport and Hammer & Champy’s ‘Business Process Reengineering‘, an almost unmitigated disaster – other than in the few cases that didn’t try to use technology as the sole basis for complex business processes. Hence, for example, the many misapplications of Six Sigma, which by definition only makes sense in a context where there are literally millions of identical events. And hence, at present, the sad struggles of proponents of ‘business-rules engines‘ to get them to deliver any real value in business-contexts that, again by definition, are often inherently beyond any feasible rules’. Oh well…

For any of us blessed – or cursed – with long memories, dealing with the vampire-like return of yet another formerly-vanquished toad can be both sad and extremely frustrating. So in evaluating any supposedly-’new’ idea that has aspects that we sense we might have seen before, we need to check its anatomy and underlying structure – and we need to be especially careful to do so whenever the conditions are right for the return of any well-known toxic-toad.

Ideas may take on any combination of these characteristics – and the combinations may vary even for a single idea in different contexts or in different stages of its lifecycle. In evaluating ideas, and testing for a potential ‘toad in the road’ we do need to be careful of applying assumptions that themselves may not be valid in a different time or place. We also need to respect the nature of the toad itself: applying ‘scientific’ criteria to evaluate an artistic idea has never worked well – and the inverse has rarely been much use, either…

We see a lot of these ever-changing combinations in enterprise-architecture. For example, IT-centrism is a Simple idea that keeps re-emerging from the depths, no matter how much we push it away; and as soon as it appears again, it has an immediate and usually very-noisy mating-frenzy with whatever the current technology might be. It’s much the same with Taylorism, as above. Right now, the ‘big noise’ is around ‘cloud-computing’ and related ideas such as ‘platform-as-a-service’ – which, once we think about it for more than a minute or two, is just a current hybrid of some very old ideas (centralisation, service-orientation) and some somewhat-newer ones (access-from-anywhere, any-platform). So whenever faced with this, or any other ‘new’ idea, all we need to do is apply the various tactics described above – and erect the appropriate ‘Toad Warning’ signs wherever they’re needed.

Do remember, though, that it’s ‘Toad Warning’ – not ‘No Toads!’ (A nice shiny triangular sign, as above – not the more threatening circle-with-a-slash-through-it type of sign.) We like our idea-toads; and even if we don’t want to touch them (ugh…? yuk!), most toads are good – in the right place, such as out in the garden, protecting our precious plants from parasites and pests. So all that we don’t want here is – yikes! – a Toad. In. The. Road!

In short, be kind to your idea-toads, treat them well, treat them with respect, find them their proper place if need be – and remember, that next toad-in-the-road that you meet could well be one of yours…? :-)

SCCC: Simple, Complicated, Complex, Chaotic

October 9th, 2011 19 comments

Folks, we have an important issue on terminology that we need to address.

In two comments to my previous post, Dave Snowden has made it clear that he objects to any reference to the term ‘Cynefin‘ that does not conform exactly to his specification for that term.

This includes any usage of the term ‘Cynefin-categorization’, which I’ve been using in order to distinguish (and advise others to distinguish) the usage of the ‘Simple, Complicated, Complex, Chaotic’ category-set, from Cynefin-proper. Snowden has made it clear that the term ‘Cynefin-categorization’ is not acceptable for this or any other purpose.

We are reminded that Cynefin-proper is a sensemaking-framework, and that in general the term ‘Cynefin’ should not be used in relation to any form of categorisation. If the term is used to describe categories, that usage must include all five Cynefin categories, including the central domain of ‘Disorder’. Under no circumstances may it be used to indicate the four-item category-set of Simple, Complicated, Complex, Chaotic. We are also reminded that the Cynefin framework has a very specific graphic-format, and that the term ‘Cynefin’ should never be used in relation to a simple 2×2 matrix.

The practical problem is that the ‘Simple, Complicated, Complex, Chaotic’ category-set and its variants are in common use throughout the enterprise-architecture discipline and many others, and have been so for many years. Although I seem once again to have taken the brunt of Snowden’s ire on this, the reality is that a lot of people are using that type of category-set and describing it as ‘Cynefin’ – usually as a result of (mis)-reading the Cynefin page on Wikipedia. A lot of people – as in Nigel Green’s example – are using that type of category-set with a 2×2 matrix and describing as ‘Cynefin’, or ‘based on Cynefin’. It’s clear that we cannot and must not do this any more.

Obviously the full category-set ‘Simple, Complicated, Complex, Chaotic’ is too long for routine use, which is why many have used ‘Cynefin’ as a convenient shorthand. Again, we cannot and must not do this any more: hence we need an alternative shorthand term.

The obvious choice is the simple acronym: SCCC for Simple, Complicated, Complex, Chaotic. (It could be shortened to SC3, but I’d prefer not… :-) )

Could we perhaps adopt this from now on?

Or does anyone have a better alternative? Suggestions, please?

— —

On a separate but related matter, Snowden’s comments to that post once again make clear his opinions on the (lack of) quality and value of my work, such as stating that the tools and techniques that I’ve developed for sensemaking and the like are inherently “invalid … in certain essential aspects”, and insinuating that the cross-map techniques for ‘context-space mapping’ described in my book Everyday Enterprise-Architecture and elsewhere should be dismissed as a ‘hash-up’.

Which, I’ll admit, does hurt: critique is important, and I do value genuine critique, but this feels more like wholesale destruction just for the dubious enjoyment of doing so… Oh well.

There’s no question Snowden is entitled to his opinion, of course. And I’d certainly agree that he’s forceful in asserting those opinions. But unlike some others, I do suffer from deep and persistent self-doubt, and I’ll admit that this has thrown me straight back into that space again, seriously doubting whether what I’ve been doing has any value to anyone at all…

So I’m asking for your honest advice in this: is Snowden’s opinion the right one here? Does my work have any value to you, or to any others that you know, in enterprise-architectures and elsewhere? Should I just accept his view that what I’m doing is valueless to everyone, and the implication that I really ought to give up and walk away from it all, to leave you and him and everyone else  in peace? Or if you consider that it does have any value, what can I do to make it better, and perhaps more resilient to the kind of dismissals and denigration that we see here and elsewhere?

Comments/suggestions? Over to you, if would?

Many thanks, anyway.

A human view of Simple, Complicated and Complex

October 8th, 2011 11 comments

What is simple, complex, complicated, or chaotic? And from whose perspective?

For a long time now I’ve been using those context-categories – often referred to as the ‘Cynefin-categorization’ – with a straightforward cross-map to levels of repeatability, somewhat analogous to the states or phases of matter:

Although we do need to be wary of misusing the proper Cynefin framework, it can be valuable to use the common Cynefin-style sort-of-cross-grid depiction of those categories as a base-map for context-space mapping. This example, from an earlier post here on business-rules, cross-maps those categories with repeatability, timescale and logic-modality (‘truth’ versus ‘value’):

Time, interpretation and abstraction

That spectrum of ‘levels of abstraction’ here is about the way in which various assumptions about ‘how the world really works’ are a kind of overlay or ‘abstraction’ on top of actual reality. Rules (‘high abstraction’) overlay many assumptions onto reality – and often the most fixed assumptions, too – whereas principles (‘low abstraction’) are much more fluid, more a choice of how to interpret rather than an assertion of ‘truth’.

(In case anyone’s concerned, this is not Cynefin – it’s just a routine ‘mashup’-style diagram for context-space mapping, where we intentionally mix and cross-map different and perhaps nominally-incompatible schemas as a way to generate potentially-useful ideas and views about some context of interest. The Cynefin frame is a useful base-map for this, but there are many other base-maps we can use – see Everyday Enterprise Architecture for more detail.)

So anyway, as in that diagram, I’d long since ended up with a fairly fixed view about the relationship between different types of context, and the kind of guidance that we use to work with each context:

  • Simple: rule-based
  • Complicated: algorithms
  • Complex: patterns and guidelines
  • Chaotic: principles

Hence, for example, that’s the mapping that I used in reviewing Nigel Green’s cross-map of application-types, in my recent post ‘What can we simplify in enterprise-architecture‘.

All of it a safe set of assumptions that we can make about the nature of reality. Simple, straightforward, obvious. Or so I’d thought…

(Yes, you can see where this is heading… :-| )

What finally woke me up from my metaphoric slumber was the following, from my futurist colleague Marcus Barber, in a comment to the ‘What can we simplify’ post:

Thanks for the article – some thought bubbles for me are

  • Simple: ‘guidelines’
  • Complicated: ‘Rules based’
  • Complex: ‘Algorithms’
  • Chaotic: ‘patterns and non patterns’

As the user, simple is what works without me needing to think too heavily about it – ‘rules’ rarely allow me to do things simply, though they may simplify by offering me a checklist to follow. That makes them structured but not simple. So a guideline would be something that works generally well enough for me not to have to think too hard as a user and fits in with your idea about simplification being addressed in different ways

Complicated therefore embraces the rules structure as in ‘if this, then that’ and ‘if not this, then that, or that or not that’

Complex – for the algorithms, is where as a user, my head hurts. In this space I sense that complex means that what ever is happening is knowable to me, and that I’d need much effort to gain a serious understanding

Chaotic is for a user where sometimes I see a pattern, sometimes I don’t. Only the very few would discern the potential what and how from amid the morass of outputs.

My first response was “He’s wrong!”, followed by a slightly-more-honest “Why is he wrong?”; and then the blaring realisation that it’s not wrong at all, in fact it’s very right – and that what had been ‘wrong’ was my too-simplistic and perhaps too-smug certainty on this… oops… :-|

It gets worse. Here I am, frequently railing against IT-centrism and the like – yet that simple mapping of ‘simple = rules’ etc is actually just about as IT-centric as it can get. By contrast, Marcus’ mapping actually is a human-oriented view into the Cynefin-categorization: no doubt about it.

Hmm… oops… :-|

(For what it’s worth, I suspect that the ‘official’ Cynefin view is somewhere between those two views, but that’s something for Snowden to describe, not me. I do know that many IT-folks use the term ‘Complex’ in a way that at first can look similar to Marcus’, but more as ‘very-Complicated’, ‘things we should be able to control but haven’t found the right algorithms for yet’ – which I still do believe is misleading, because it doesn’t allow any space for inherent-uncertainty, but that’s just me, I guess…)

Machines find repeatable rules easy to follow, and non-repeatability impossibly complex; whereas real people often find a rule-laden environment all but impossible to bear, yet may well thrive on the uncertainty and unrepeatability of ‘chaos’. That’s a very important distinction of which we do need to be aware.

If we don’t take enough notice of that distinction, we end up with something like Taylorism’s ‘scientific management’ or a feudal-style ‘command-and-control’ culture, which only ‘succeed’ through requiring people to act as literally robotic machines. Which, yes, those people can do – but as Deming and others demonstrated, it’s almost the least-effective way of using people’s abilities in a work-context. (So much so that ‘work-to-rule’ has long been used as a form of workers’-protest – because it really screws things up, yet in a way that can’t be challenged by ‘the bosses’…)

All of which has huge implications for enterprise-architecture and the like. For example, a mismatch between what IT-folks would think of as ‘simple’, versus what people doing the work would regard as ‘simple’, would lead directly to the kind of process-redesign disasters that we saw so often in business-process reengineering. People can navigate their way quite easily through the myriad of minor variations in a typical real-world business process; but for a rule-based IT-system those same variations can quickly become an impossibly-complicated mess of exceptions on exceptions on exceptions to the supposedly-simple ‘business-rules’. There’s a major task of translation needed here, one that’s all too often missed or ignored: hence Nigel Green’s book Lost In Translation, and the VPEC-T framework that it describes.

And we’ll need the same kind of translation, but in the opposite direction, for most planning and design for business-continuity and disaster-recovery, where people need to take over the tasks of out-of-action IT-systems. Expecting people to follow the exact same ‘business-rules’ as an IT-box might not only be nearly impossible in practice – way too much ‘picky-petty-detail’ for almost anyone to remember – but would also be incredibly inefficient and ineffective. It’d be much more effective instead to trim all of those business-rules down to a much simpler set of principles and priorities, matching more closely to the way that real people really work – and then use skills-development and governance to clean up any rough edges at run-time and beyond.

That’s what’s obvious – when I remember to use my own tools on my own thinking, that is… Oh well… :-)

So there’ll be a lot of options and ideas to explore there: Simple may not be as simple as it looks, and Complex may not be so complex, either. A point well worth pondering a bit more, I think?

What is the boundary of a service?

September 29th, 2011 3 comments

“What would be the smallest service? Did anyone ever look for the/a boundary condition of a service?” – an important pair of questions from Jan van Til in an earlier comment here.

The first question is a bit difficult, because the only correct answer would be that ultimately it’s right down at the sub-cellular level – which isn’t likely to be much help in most business-contexts…

So in practice the way we need to answer that question is actually the same way we would answer the second question: the ‘smallest’ service, and the boundary-condition for a service, is whatever and wherever we choose it to be.

I’m not being facetious here: I’m serious. This is actually a crucial point in all service-design – yet it’s a point that many people seem to miss.

First, another key question: what is a service? The short answer is that a service is ‘something that serves’. Which again might at first seem a bit facetious: but seriously, it’s not, because it encapsulates everything that really matters here. At this level, we need to keep to the abstract: hence we deliberately don’t say what the delivered service might be, but instead focus on the fact – or action - of ‘service’. And a service is a service because it serves: and, usually, that it serves or services the needs of something other than solely of itself.

Yes, very abstract – but actually very important from an architecture perspective, because it provides explicit constraints whilst at the same time keeping everything open.

To give a concrete example, consider a kidney. (Okay, you might prefer not, but it’ll do as an example, surely? :-) ) What does a kidney do? From a services perspective, what does it provide? Assuming a living body, the kidney provides a number of services, such as removing excess water from the system, filtering out impurities, breakdown of certain by-products of digestion, some specific functions for the immune-system, and so on. We can then look at various service-interfaces at that layer (mainly the bloodstream and the bladder), the biochemical protocols and exchanges, whatever. All of this would make perfect sense to someone who’s studied anatomy, physiology and the like.

But notice that we’ve invented an arbitrary service-boundary here. We could go up a level, and bundle all of the functions of the kidney under the heading of ‘digestion services’. Or we could go down a level or two, to the individual services that the kidney provides. We could go down quite a lot further, such as to the ‘containment-services’ provided by certain types of cells that denote and delimit the outer edge of what we would generally think of as ‘the kidney’. Yet there’s nothing concrete or explicit that would always define for us ‘the‘ service-boundary: instead, we choose the level, and the service. The boundary of the service is whatever we choose the boundary of ‘the service’ to be.

So, to bring this back to business: what is a ‘business-service’? What denotes the boundary of a ‘business-service’? In practice, we’ll see exactly the same as with the example of the kidney: a ‘service’ is something that serves in some identifiable way, that we happen to describe as ‘a service’.

That’s it: there is no explicit ‘the boundary’ for ‘a business-service’. Which is why we end up with all sorts of names and terms being used, often interchangeably, for all sorts of different ‘services’ within business, with all manner of intense arguments as to which term fits what and which service is ‘above’ or ‘below’ or contains others, and so on. For example, look at all of the chaos and confusion around the following terms:

  • business service
  • business unit
  • business process
  • business function
  • business capability

In architecture, each of those terms would have a distinct meaning: for example, in Enterprise Canvas, a service is a conjunction of function (a description of what should be done) and a capability (the ability to do something), whilst a process would chain various services together to deliver an overall effect on something. But in most business-usage they’re just alternative terms for ‘a service of some kind, at some level of abstraction’ – with different terms used almost at random as sort-of-synonyms for each other, at different levels of granularity or abstraction. Hence all the confusion, because that arbitrary scrambling makes it very difficult to work what the heck any of those terms actually mean in any given context…

But the quick solution is to recognise that in practice all of them are ‘services’. And once we accept that we are responsible for choosing ‘the boundary’ of a service, suddenly things can get a whole lot simpler. Choosing a boundary will itself imply the service-interface for that particular view or granularity of service. Identifying the interface then also leads us towards identifying the exchange-content, the interface-protocols, and the probable functions and capabilities that this service would require. And because we have that choice, we can move any or all of these around as appropriate, for better fit to what we have available in our architecture or whatever, simply by choosing a different boundary for the service. The boundary isn’t something that’s fixed, predefined, preordained: it’s our choice.

(By the way, we can see exactly the same kind of thing happening with the ‘mote’ concept in the metamodel-structure that I described in earlier posts. Several people asked “what is the boundary of a mote?”, “how big is a mote?”, “which metamodel layer does a mote sit in?”, and so on. The actual answer is “whatever we say it is”: it’s determined by our choice of the context, not by the structure itself. Technically, the mote-structure is defined at the M3/M4 level, but in fact any mote could be used directly at any layer, right the way down to the M0 model-level. And the size of the mote is “whatever it needs to be”: a tag-mote, for example, is tiny – we could almost describe it as being at the atomic level – whereas an complete model and its entire change-history would also be represented by the full related-mote tree of another single mote.)

Hence we come back to the core theme of a service-oriented architecture: everything is or delivers a service. Again, that applies at every level: in Enterprise Canvas, for example, the ‘service-in-focus’ might be anything from a single line of code to the entire enterprise – there’s no inherent difference other than as determined by context. Everything is a service; and the boundary of a service is what we say it is.

Hope that makes some degree of sense?

[Many thanks to Jan for suggesting the topic - and yes, please do comment on this if you wish?]

EA metamodel: two questions

September 15th, 2011 2 comments

Following on from the previous work on EA metamodels, I keep coming back to those two questions from Graeme Burnett: for everything in a context, we need to be able to ask “tell me about yourself?” and “tell me what you’re associated with?”.

That focus does help to keep things simple here…

(Please remember that this is still very much a thought-experiment, but I do believe we’re getting closer now to something that really is implementable.)

To recap, we’d previously ended up with the concept of a ‘mote’, a kind of very-low-level entity that consists merely of an ID, something a bit like a role or opcode, a single optional parameter, and an optional list of related-motes. Conceptually, an individual mote looks a bit like a bacillus:

On its own, it’s tiny – really tiny, and almost meaningless. But that related-mote list turns out to be incredibly powerful – much more powerful than I thought it would be, in fact. It’s also looks like it’d be surprisingly easy to implement.

Even more interesting, it actually removes the distinction between metamodel-layers within implementations, because with this mote-structure they’re all the same: everything is a mote. Whether it’s a model, a metamodel, a metametamodel or metametametamodel, everything is either a single mote or a collection of motes, all with the exact same structure.

Everything’s a story, too: “tell me about yourself” returns a mote’s own story, whilst “tell me what you’re associated with” returns the story that this mote shares with others. The story may be very simple – as it is with a tag-mote – or very broad and complex – as it would be with a mote that represents that represents an entire model – but it’s still just a story, retrieved from each mote in the same way.

More interesting still, the mote-structure also in effect defines a file-structure that can be used both to exchange models between toolsets, and exchange model-types and notations between toolsets. And in essence, subject to a certain amount of intelligence in the toolset, all of that exchange can be done with text-files in a standard structure-format such as JSON or XML. Which gives us a fully non-proprietary file-format for just about everything we would need in an EA toolset.

(Toolsets would differentiate themselves by their user-interface and user-features: what we’re describing here is just a data-structure and file-format, and a conceptual API to drive everything within that structure – not a full features-specification for toolsets!)

And what’s perhaps most interesting of all is that all of that arises from those two questions: “tell me about yourself”, and “tell me what you’re associated with”.

Interested?

Read more…

What’s the point of this ‘EA metamodel’?

September 8th, 2011 3 comments

I’ve been writing a lot recently about metamodels for enterprise-architecture and the like: but what’s the point? Why bother? Why all this fuss about something that’s way too technical to be of interest to almost anyone in the real workaday world?

The real point behind all of this discussion (and there’ve been some really valuable comments here – many thanks indeed!) is that it’s not actually much about the metamodel at all. The structure of the metamodel itself is just a detail that we need at some stage to make things happen.

It’s not really about the model-types or models that could be constructed via such a metamodel – other than that we want this metamodel to support any type of model that would be needed in EA or strategy or the like.

It’s not even much about toolsets – other than that we need some non-proprietary method to allow us to move model-data and model-definitions from one toolset to another, and that we need toolsets that will more truly support the ways we actually work.

What it’s really about is how we use models in enterprise-architecture and other cross-domain disciplines.

The key-word there is ‘cross-domain‘. In a single-domain context – software-architecture, perhaps, or IT-oriented process-design – there are standard model-types for that domain (such as UML and BPMN respectively), and we need to be careful to follow the rules that define those model-types. Sometimes – as with UML – there are multiple model-types and multiple notations, but they all act as views into the same formally-constrained context-space. The main focus in a single-domain context is on design and implementation – on doing something, in accordance with the rules that apply within the respective part of Reality Department.

In cross-domain disciplines like enterprise-architecture or strategy or business-model development, life is a lot messier (in terms of modelling, anyway :-) ). There is, by definition, almost an infinity of model-types and notations that could be used in different ways, all of which follow different and often conflicting rules. Most of those model-types come from specific single-domains – but often we don’t use the various model-types in the same way. Some of the emphasis is still on design – on linking the different domains together, despite the clashes between all those different rules. Yet we also need some means to map across those disparate domains: which is why – from our perspective – we need an underlying metamodel that would allow us to keep track of entities and relations and the like as they move between different models. Some structures such as UML and the underlying MOF standard will allow us to do this to some extent within a single domain – yet doing the same between domains is still something of a nightmare. Which is one reason why we need this ‘EA-metamodel’ work to happen.

Yet often, in cross-domain work, the real focus is not on design, but on sense-making, and thence to decision-making. (Design does matter, of course, and matters a lot, but it usually comes later in the process.) Peter Bakker put it well in one of his comments:

For me the goal is not to make a tool to make or adapt other models but to gain insights from a diversity of models together which you won’t get from looking at the models separately.
For that we need a sense-making tool which can translate the information from all those different senses (models) into a common “brain language” and use that common “brain language” to create new insights (patterns).

To illustrate the point, Peter indicated in other comments that he was using the ideas here in a ‘thought-experiment’ to develop context-insights by moving ideas around between four different model-types:

  • mind-map
  • Business Model Canvas
  • tubemap
  • Venn-diagram

Each of those model-types have their own distinct notations, rules and ways of working. Yet in this type of work, they’re also all merged together into a single sense-making process. Same, and different – both at the same time.

Overall, it’s a process I call ‘context-space mapping’, because we build maps and cross-maps across the whole context-space. (There are quite a lot of posts here on context-space mapping, if you’re interested; also some detailed description and practice in my book ‘Everyday Enterprise-Architecture‘.) And within that process, we tend to use models in radically different and often in intentionally-’wrong’ ways. We move things around; we compare, contrast; we break the nominal rules of the model-type (which means, though, that we need to know those rules first if we’re going to get any real value from breaking them…); we use models in very different ways from which they were originally designed – using UML or Business Model Canvas as a concept-map, for example.

What we look for in that process is not so much the certainty of following the rules, but the insights that arise between the models, behind the rules. When ‘the usual rules’ don’t seem to work, or don’t seem to make sense – which is usually the case in any sense-making exercise – we need to run the logic itself backwards, in order to derive what rules actually apply in that part of the real-world that we’re dealing with. It’s part of what I sometimes describe as the ‘business-anarchist‘ role, and which is a distinct discipline in its own right – the discipline of surfacing implications and hidden assumptions, and then reworking them into something we can actually use.

That’s what we need that type of toolset for – to support that type of cross-domain, cross-disciplinary sense-making.

That’s what we need that versatility in models for – to support the toolset in how it defines and uses and displays and cross-compares all the different types of models.

And that’s what we need that metamodel for – to support consistency and idea-tracking across the whole of that sense-making model-space, mapping across the entire context from every alternate direction and view.

So in all of this deep-technical-detail and so on, it’s essential that we never lose track of the real goal here: a means to support how we actually work with models and the like in enterprise-architectures. That metamodel-structure that I’d proposed in the previous posts is just one idea towards implementation of all of that. It’s nothing special, it’s not ‘My Preciousss’ or whatever :-) – it’s just a way to present something that people can argue about and test out the underlying ideas. Other people who know they’re doing with the detail-work on metamodels would no doubt do it much better than I can: yet we do need somewhere to start, some way to start the ball rolling.

That’s what it’s really about. It’s not the metamodel itself that counts; it’s what we can do with it that counts. That’s the real point here.

Over to you for comments, perhaps?