Tom Graves / Tetradian

The echoes of the ‘naming-problem‘ around business-architecture and the like continue to rumble on, this time via another happy Twitter-exchange with Ron Tolido:

• rtolido: @tetradian just show me the non-IT people that invented #entarch and / or #bizarch
• tetradian: @rtolido we’re in a circular-definition here: what you call #entarch or #bizarch is whatever was ‘invented’ by IT-people… //  crucial problem is that IT-people labelled as ‘enterprise architecture’ to something that wasn’t ‘architecture of the enterprise’ // likewise with IT version of ‘business-architecture’, which _isn’t_ ‘architecture of the business’ // once we sort out that mess, it becomes obvious IT-people did not invent it – but until then, we have those circular-definitions… // non-IT-people: Deming, Boyd, Beer, Alexander, even Taylor, for heavens’ sake…
• rtolido: @tetradian All true! Just pointing to the actual roots of both #entarch and #bizarch . Not saying it’s a good thing per se.
• tetradian: what you’re doing at present is propping up _fundamental_ mistake: mislabelling of ‘IT-view of business’ as ‘business-architecture’ // ‘Open Group Cert in IT-view of Business’ is fine – just don’t call it ‘business-architecture’, because it isn’t! // Data Architecture 101: don’t assign names to things that don’t mean the same as what those things actually are!

And that last point is actually a good idea: apply a bit of bog-standard data-architecture practice to this problem. Let’s look at this whole mess from the perspective of Data Architecture 101:

– Step 1: A core principle: all entities shall be assigned meaningful names or terms – i.e. that the assigned name shall correspond to the ‘natural meaning’ of the entity.

– Step 2a: If a term that is currently assigned to an entity does not match the ‘natural meaning’ of the entity but is not in common use, the updated name for the term shall be promulgated, and action taken to dissuade use of the former misleading-term.

– Step 2b: If a term in common use is currently assigned to an entity but does not match the ‘natural meaning’ of that entity, an architectural ‘waiver‘ or ‘dispensation‘ shall be issued, acknowledging the current usage of that term.

– Step 3: If a waiver is issued, the waiver does not mean that the misleading usage is acceptable, but rather that although the fait-accompli is accepted in the present, all efforts must be made to prevent the misleading-term from becoming further entrenched, and every opportunity taken to promulgate a replacement ‘natural-meaning’ term.

This is basic stuff, the kind of routine data-architecture work I was doing twenty years ago and more. Software-coders do it every day; web-designers do it; database-administrators do it. But not, apparently, the people who purport to maintain the formal standards for this kind of work. To use a certain famous phrase, “this does not compute…”

Let’s look at this in a bit more detail.

First, that principle from Step 1, the notion of a ‘natural meaning’. A term or entity can of course be assigned any name at all: sometimes projects and the like are intentionally assigned misleading names, for security purposes or because they’re being used only as ‘working title’ or suchlike. Sometimes such names do stick, misleading or not: ‘tank’ is a classic example. But in general – especially in a data-architecture or in any part of an enterprise-architecture – an entity should be assigned a name that aligns with its use and function: for architectural purposes it doesn’t help anyone if we decide to use the label ‘Glue Pot’ for a delivery-truck, for example, or ‘Salmonella Breeding Station’ as the label for the cafeteria business-unit. In general, it’s a lot more helpful if we call a spade a spade, and so on.

[We can take this a bit further, perhaps - hence the old adage that "An Englishman calls a spade a spade, but an Australian calls it a bl**dy shovel"... ]

Hence the notion of ‘natural meaning’, that in order to minimise the potential for confusion, things should be named according to what they are or what they do.

And a simple test for ‘natural meaning’ is inversion of the term: if the inversion gives the same meaning as the assigned term, it’s more probable that, overall, the term won’t cause confusion. (There’s a proper grammatical-term for this inversion, but I’ve forgotten it: someone remind me, perhaps?) Take ‘data architecture’, for example: the inversion is ‘the architecture of data’, which in both cases is what actually happens in the practice of data-architecture – so we can be reasonably comfortable that we have something close to ‘natural-meaning’ there. In practice, ‘data-architecture’ is a term we can trust to make sense.

Likewise ‘security-architecture’, as the architecture of security; or ‘brand-architecture’, as the architecture of the relationships and the like between business brands;  or ‘IT-infrastructure architecture’, as the architecture of the infrastructures of IT-systems. These all make clear sense, whichever way round we put it; and keep the same meaning, whichever round we put it.

But when we try this inversion with the supposedly-’official’ usages of ‘enterprise-architecture’ or ‘business-architecture’, it just doesn’t work:

– enterprise-architecture:

• natural-meaning (from inversion): the architecture of the enterprise (i.e. organisation as a whole, plus extensions into the value-network and overall ecosystem within which it operates)
• common-usage in TOGAF, FEAF etc: the architecture of the IT-systems in use within the organisation, with some reference to the usage of those systems within the organisation’s business

– business-architecture:

• natural-meaning (from inversion): the architecture of the business (or, more specifically, ‘the business of the business’)
• common-usage in TOGAF, FEAF etc: anything not-IT that might impact upon IT, organised and described solely in terms of its actual or potential impact on IT

In both cases the IT-oriented common-usage is a very long way from the natural-meaning of the term – which guarantees confusion as soon as we move outside of the narrow confines of an IT-oriented view. And in both cases that common-usage meaning describes only a very small subset of the scope of the natural-meaning – in other words, wherever the IT-oriented common-usage is dominant, it represents a serious term-hijack that blocks visibility of the remainder of the natural-meaning scope.

Which, in any competent data-architecture, would clearly indicate that have a couple of seriously-invalid term-usages here. Which means we need to do something about it. Which brings us to Step 2.

It’s clear that Step 2a can’t apply here, because both of these invalid terms are very much ‘out there’.

Which means that we move to Step 2b: we issue a waiver.

But we do not forget what a waiver actually means here, and what responsibilities it places on all of us, collectively, in terms of action we must take in future to correct the architectural risk. In particular, it does not mean that we simply throw up our hands in the air and say “oh well, it doesn’t matter” – because clearly it does matter, because equally-clearly that usage of the term will not make sense to anyone outside of the ‘in-group’ cabal. Instead, the waiver says that we must take action to correct the fault – exactly as with any other type of architectural fault.

Which brings us to Step 3. What we actually need in this case is the metaphoric equivalent of a full ‘Cease & Desist’ order, to demand that people not only stop all use of this misleading usage of the terms, but take action to correct all materials in which either of those two misleading usages occur. For example, TOGAF would need to be rewritten from scratch: given the natural-meaning, it wouldn’t be allowed to use the term ‘enterprise-architecture’ just about anywhere in the whole document, and ‘Phase B: Business Architecture’ would either cease to exist, or be reconstructed as a proper multi-domain structure, within which ‘the architecture of the business of the business’ is merely one amongst many other domains that can impact upon IT.

Let’s not beat about the bush here: that is what needs to happen. Anything less represents not only only an architectural risk on a major scale, but an ongoing risk whose impacts increase exponentially with every passing day.

Sadly, Reality Department indicates we’re very unlikely to get this – not least because it would require Open Group, CapGemini, Federal Enterprise Architecture, Gartner, Zachman and all the rest to recall every scrap of their past publications on ‘enterprise’-architecture, and rewrite the whole darn lot. But we need to say, and continue to insist, that this is what needs to happen in future. We do not simply allow them to continue promulgating these (and many other) fundamentally-wrong term-usages in the enterprise-architecture space.

That’s Data Architecture 101, as applied in a perfectly straightforward way to current ‘enterprise’-architecture – what the Americans call ‘eating our own dogfood’.

And if we aren’t willing to do it to our own work, why on earth should anyone else trust us to do it to theirs?

Pretty simple, really.

So, whatcha gonna do about it, folks?

—

One separate but related and very important addendum: I am not knocking TOGAF in itself here, nor anything or anyone else in the IT-architecture space. IT-architecture is extremely important, and Open Group and others have been doing sterling work in that space for many years. To my mind, no-one should doubt this, and I’m very happy to sing their praises on that part of the work, and invite and encourage others to do likewise.

All that I’m saying is that what TOGAF etc call ‘enterprise-architecture’ should not be called ‘enterprise-architecture’, for the simple reason that it is not ‘the architecture of the enterprise’.

Likewise the somewhat jumbled collection of bits-and-pieces that TOGAF and its ilk call ‘business-architecture’ should not be called ‘business-architecture’, for the simple reason that it is not ‘the architecture of the business’.

[The latter point should be obvious when we consider that TOGAF's 'business-architecture' assumes that the entirety of the non- IT executive - in other words, the CEO, CFO, COO, CMO, CHO and any non-IT CTO, and all of their respective domains - can all meaningfully be lumped together as 'the business', with only IT needing aany differentiation from the rest. Anyone who's had any dealings at executive-level will know that it's, uh, not quite as simple as that? :wry-grin: ]

Best leave it there for now, I guess. Over to you?

This one continues the recent theme of IT-centrism and why it’s such a problem for enterprise-architecture, but extends it into a slightly different direction, courtesy of a Tweet yesterday by Ron Tolido:

• rtolido: interesting stuff coming soon around a global Business Architect certification standard by The Open Group #ogsfo

Important to say here that I have enormous respect for Ron: quite apart from his senior role at CapGemini, he’s also an amazing innovator in IT-architecture and enterprise-architecture, with ideas such as Slow IT, the importance of a demolition strategy, and the SCOOTER metaphor. Yet I must admit I was absolutely horrified at that comment above, and said so:

• tetradian: @rtolido IT-centrism in TOGAF etc has crippled #entarch for half a decade: please don’t let OG do the same to #bizarch as well…

The point is that, given their track-record so far on business-architecture,  I can hardly think of any organisation that’s less qualified than Open Group to create such a standard. For Pete’s sake, even the Piddletrenthide Parish Parent-Teacher Panel would probably do a better job of it…

And no, I’m not being nasty here – I’m serious about this. The utter shambles that is TOGAF’s ‘Phase B: Business Architecture’ should sound clangorous alarm-bells about any such suggestion: it’s just a random collection of ‘anything not-IT that might affect IT’, with no structure, no symmetry and no sense. If you want to see how so much of so-called ‘enterprise’-architecture actively increases the infamous ‘business/IT-divide’, you need only to take a careful look at the TOGAF specification for its ADM Phase B. And these people seriously consider themselves competent to define a global certification for business-architecture? No way! – please…?

Anyway, my Tweet-response above triggered a reply from Ron:

• rtolido: @tetradian it’s an IT thing to criticize IT-centrism but after all: #entarch is an IT people invention. Let’s try to do better with #bizarch

To which my first response was ‘What the…?‘, which came out in more polite form on Twitter as this:

• tetradian: @rtolido “it’s an IT thing… entarch is IT-invention” – disagree on both counts, but yes, please let’s do better with bizarch…

Let’s tackle Ron’s points in reverse order…

At least there’s an acknowledgement that we could do better with business-architecture than has been done with those current attempts at ‘enterprise’-architecture. That’s something. Good.

On “#entarch is an IT-people invention”, it isn’t. That’s a convenient myth that IT-people want to believe – though no doubt a fair few of them will want to throw various historical quotes at me to ‘prove’ their provenance. Sure, the term ‘architecture’ has long since been linked to IT – almost half a century, by now. And somewhen around a couple of decades back, some bright spark extended that idea to distinguish between a context-specific IT-architecture versus an IT-architecture at organisation-wide or enterprise-wide scope, as ‘enterprise-wide IT-architecture’ – at which point some idiot conflated that nominally-valid term to a no-doubt ‘simpler’ shorthand term as ‘enterprise-architecture’, without any awareness of just how misleading that would be, or how much damage that term-hijack would cause. Yet reality is that there are many long-established business disciplines such as systems-thinking and design-thinking as applied to the enterprise that have a much better natural fit with the term ‘enterprise-architecture’; the original meaning of ‘business-analysis’ was also probably very close, too. In short, ‘enterprise IT-architecture’ is arguably “an IT-people invention”; but enterprise-architecture most definitely is not.

On “it’s a IT thing to criticise IT-centrism”, I’m not quite sure what Ron means there – whether only ‘IT-people’ have the right to do so, or else that anyone criticising IT-centrism is inherently self-identifying as an ‘IT-person’. If it’s the former, then the fact that I’ve had perhaps 30 years experience in and around IT might qualify me to criticise? But more to the point, my background is as an explicit cross-discipline generalist – I’m one of the few people formally qualified as such, with an MA in General Studies from London’s Royal College of Art. And it’s in that sense, as a long-experienced practitioner of ‘design-thinking’ within a very wide variety of business contexts, that I see IT-centrism as such a problem. (And, for that matter, business-centrism – which I’ll come back to in a moment.) In terms focus of attention, the single most important fact in enterprise-architecture, or business-architecture, or any other architecture, is this:

Within any architecture, everywhere and nowhere is ‘the centre’, all at the same time.

What happens in any form of ‘-centrism’ is that we keep on being dragged back to some specific area that claims to be ‘The Centre’ of the architecture. Rather than an ‘outside-in’ view – an awareness of the whole – we’re constrained to an ‘inside-out’ view, where everything in the architecture is seen only in relation to and in terms of that single ‘The Centre’. If there is no direct connection to that ‘The Centre’, or no direct impact, whatever-it-is is usually dismissed as ‘out of scope’, and often deemed not even to exist. Hence, in TOGAF’s inherently ‘inside-out’ view – in which IT-infrastructure is its actual ‘The Centre’ – we have no means to describe anything that is not-IT and that does not in some way impact directly on IT.

[To illustrate the point, try using TOGAF or its linked Archimate-notation to describe the physical activity of a production-line, the trucks and conveyor belts and other machines of physical logistics, the human activity of paper-based record-keeping, or the physical infrastructure - cooling, power-supplies and suchlike - of an IT data-centre: if you can do it all, you'll have to use some horrible kludges and fudged reframings of the supposed standards in order to do it... And yet all of these things would be essential in an enterprise-architecture for the respective industry.]

I need to reiterate that it isn’t only IT-centrism that creates this kind of problem: it’s any-centrism. What I’ve also been seeing recently is a lot more ‘business-centrism’ in enterprise-architectures, where ‘the business of the business’ is taken to be ‘The Centre’ of the enterprise-architecture. We see this, for example, in the insistence that financial metrics are the only metrics that count, and that return-on-investment (ROI) and the like can only be measured in financial terms – which might be valid within certain subsets of business-architecture, but are way too constrained to be valid in the far broader scope of enterprise-architecture. In some ways this trend worries me even more than IT-centrism, because by the nature of business it will tend to have even more of the wrong kind of credibility, making that much harder to counterbalance and correct within the architecture.

Anyway, Peter Bakker dropped in a useful comment at this point, pointing to a classic early essay by Christopher Alexander, famed author of A Pattern Language:

• pbmobi: @rtolido @tetradian #entarch & #bizarch just see the trees, we need architects who see the semi-lattices http://www.chrisgagern.de/Media/A_City_is_not_a_tree.pdf #ogsfo

• taotwit: @tetradian @rtolido erm.. Tom I think you’re mixing up what EA is with what should be!
• tetradian: @taotwit @rtolido if someone’s defining a new standard, surely it should be about what should be, not about preserving current mistakes?
• taotwit: @tetradian @rtolido good point – I hope they listen to the likes of Alec Sharp and Patrick Hoverstadt

Agreed with Nigel there: a business-architecture certification scheme would need input from people like Alec or Patrick, or likewise from other key figures in business-architecture or business-innovation such as Alex Osterwalder or Steve Blank. But, like me, none of them are members of Open Group – which means that not only do we not have a voice, but what we say will be ignored anyway. In other words, Open Group expressly locks out many of the people who are doing real innovation in business-architecture, and then wonders why there are real doubts about the usefulness or validity of what it then produces as its ‘standard’.

Which brings us to the disaster-area of certification. In principle it’s a good idea, even a very necessary idea: every profession needs some way to identify and validate core knowledge and the like. But when the certification for a discipline is managed by a group that evidently do not understand what that core-knowledge actually needs to be, then we have a problem… and that’s exactly what we have with Open Group and business-architecture.

Open Group are an IT-standards body: and they’re very, very good at what they do in IT. But they’re not a general business-standards body – and that fact is becoming extremely important here. In the days when TOGAF was solely about IT-architecture – as it was up until version 7 – then it made sense for the ‘enterprise IT-architecture’ standard to be maintained by the Open Group. But the problem with any enterprise-scope architecture is that, by definition, you have to take everything in the enterprise into account: hence an expansion out into data- and applications-architectures in TOGAF 8, and then, in TOGAF 8.1 ‘Enterprise Edition’, the addition of a loosely-defined ‘anything not-IT that might affect IT’. Unfortunately they made two fundamental errors at that point: because that random bundle represented IT’s view of what it called ‘the business’, they labelled it ‘Business Architecture’; and they then described the whole IT-specific structure as ‘Enterprise Architecture’ – both of which sort-of made sense from their own inside-out perspective, but made no sense to anyone else, especially when looking outside-in. Oops…

Anyway, back to certification. So first, there is a real value in having a common language for specific types of architecture. In that sense, the TOGAF 9 ‘Foundation’ certification is genuinely useful, because it tests knowledge of that common language.

Likewise the practitioner-certifications such as ITAC, which assess someone’s practical skills and competence. Unfortunately it’s no use to me, though, as it still assumes that the only possible path to enterprise-architecture is via detail-level IT-infrastructure architecture, which I don’t do and never have. (I’ve done a lot of mainstream data-architecture in my time, but that doesn’t towards ITAC certification either.)

But to my mind – and in my experience, too – the mid-level certification, ‘TOGAF Certified’, is actually worse than useless: to be blunt, it’s almost a measure of how much someone is not competent to do enterprise-architecture. Yikes… there are some serious problems there…

That perhaps sounds a bit harsh: it’s not. There are two interlinked reasons why this is so.

The first is that ‘TOGAF Certified’ is a content-based exam. All it tests is how well people know the TOGAF specification – not architecture-practice. And to be blunt, the TOGAF specification is a long way from what’s needed to do enterprise-architecture – especially in any industry other than ‘the usual suspects’ of banking, finance, insurance, tax. (Why those industries? Because their business-models are built almost entirely around large volumes of simple structured information with automatable business-processes – in other words, strongly IT-oriented. Which doesn’t apply to most other industries.) I almost failed my TOGAF 8.1 exam because I answered several questions in terms of what I knew worked in practice, rather than what’s written in the book. And the ‘correct’ answer in the book was just plain wrong: I knew from real-world practice that it was exactly what not to do. Needless to say, I wasn’t impressed when I was penalised in the exam for doing it right…

The second reason is that TOGAF is not a standard. This isn’t some arbitrarily-unkind assertion that I’m making: it’s not only common knowledge, but I’ve even heard several senior Open Group figures say so in public. (Exact quote: “Of course no-one uses TOGAF out of the box! – we always have to customise it one way or another”.) The best way to describe TOGAF is that it’s a somewhat-better-than-random cookbook of ideas and practices vaguely held together by a almost equally-vague structure of the Architecture Development Method [ADM] – and that’s it. There’s not much guidance in TOGAF itself on how to customise TOGAF: you get that from experience, with a bit of help from some of the better training-providers.

So what we have at present in the ‘TOGAF Certified’ exam is a way-too-simplistic multiple-choice test on the supposed content of a ‘standard’ that actually isn’t a standard and often doesn’t match up at all well with real-world practice anyway. So just how much use do you think that’s going to be? To anyone? Honestly? Hmm…

And given that, how much credence would you place on a certification-scheme by the same people on a domain which they demonstrably don’t understand much if at all, judging by the current content of TOGAF’s ‘Phase B: Business Architecture’? Oops…

Hence why I’m extremely wary of letting this current attempt by Open Group go unchallenged: they really are almost the least-appropriate group to do the job.

No question at all that we do need some very good work to happen on business-architecture, and urgently so. But please, not from Open Group? – at the very least, not until they’ve tidied up the utter shambles of ‘Business Architecture’ in the current TOGAF, and can demonstrate that that they can keep their reflex IT-centrism under better control than at present?

Sigh… Oh well… back to the grindstone, I guess…

Over to you for comment or whatever, anyway.

A set of Tweets from the third and final main day (01 Feb 2012) of the Open Group conference in San Francisco, collated via the#ogSFO hashtag. (Tweets from Day 1 are here; from Day 2 are here.)

Once again, many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

Same minor edits as in the previous posts:, I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

I’ve also added a few wrap-up remarks of my own at the end.

As usual, somewhat less volume again on this day of the conference, but still several pages’-worth, so continue after the break.

Read more…

A set of Tweets from the second day (31 Jan 2012) of the Open Group conference in San Francisco, collated via the#ogSFO hashtag. (Tweets from Day 1 are here.)

Once again, many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

As before, I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

Not quite so much as the previous day, but still a lot, so continue after the break.

Read more…

A set of Tweets from the first day (30 Jan 2012) of the Open Group conference in San Francisco, collated via the #ogSFO hashtag.

Many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

There’s a lot of it, so best place a brief break here.

Read more…

This one is a pick-up from a Tweet by Bert van Lamoen:

• transarchitect: The priority shift we make is from efficiency to effectiveness to co-creativity. #complexity

Of course. Yes. That’s obvious, the moment I look at it.

Except that I’d completely missed before now.

Oops…

I’ve long since drawn a distinction between efficiency and effectiveness. Or rather, that efficiency – ‘doing more with less’, ‘doing things right’ – is only one dimension of effectiveness – ‘doing the right things right’.

[The set of five dimensions that I've used to summarise effectiveness, if you're interested, is efficient, reliable, elegant, appropriate, integrated - see  the slidedeck 'What is effectiveness?' or my book SEMPER & SCORE: enhancing enterprise effectiveness.]

Yet that type of ‘effectiveness’ assumes that there’s some kind of pre-ordained plan – ‘effective in terms of the plan’. What if there isn’t a plan? What if we don’t know what the plan is? What if we’ll only know what the plan was – or sort-of ‘was’ – once we’ve completed it? (‘Retrospective causality’, as a certain person would put it.)

That’s where co-creativity comes into the picture. Co-creating a ‘plan that is no-plan‘, together.

And that’s what I’d missed.

[I can see why I'd missed it: to be blunt, I'm, uh, not good at anything that involves being social, and the whole point and focus of co-creativity is that it's social. But it still doesn't excuse the fact that I shouldn't have missed it. Sigh.]

Yet I’m not the only one who’s missed it: there’s a whole societal shift implied here – a completely different way of working. One that doesn’t assume that there’s ‘The Plan’. One that doesn’t assume that there’s The Person In Control, or The Person Who Knows What’s Going On. Or even that there’s anyone who knows what’s going on. Instead, there’s a trust that co-creation will take us where we want to go: an effectiveness that’s an emergent property of the collective, without any ‘plan’ or pre-certainty at all.

I don’t see this as an ‘either/or’ – either effectiveness-relative-to-a-plan, or co-creation-with-no-plan. It’s more a ‘both/and’ – it seems more an effectiveness that arises from a sort-of plan-that-is-no-plan, one that covers the entirety of the SCAN decision-making space:

The classic ‘efficiency’-based approach is mostly about the left-hand side: assertions about ‘the true metrics’ and so on leads to The Plan which leads to control of actions and decisions at real-time – the Belief ‘domain’. It’s very mechanical – often literally so.

Looking at it now, the approach I’d taken to effectiveness did incorporate a lot more of the right-hand side, with a strong acceptance of various aspects of uncertainty – particularly in the human space, the ‘elegant’-dimension of effectiveness. But it still presumes a plan, an Assertion – and hence that’s where it naturally tends to return.

Co-creativity would seem to focus more on the ‘Use’-domain – literally, “What’s the Use?”. I believe that to work well – to avoid a collapse into a dysfunctional-chaotic free-for-all, a ‘co-non-creation’ – it’d still need some kind of guiding-light or anchor or direction, a shared “What’s the purpose here?”. Yet even that would likely be co-created too – a nice recursion there.

Hmm… A lot to think about. Or, preferably, co-create? Thanks anyway, Bert!

It’s customary at this time of year to do some kind of review: what’s happened in the past annual cycle, hopes and intentions for the next.

[Sometimes these reviews can be a bit too predictable in their over-focus on prediction? As Forrester enterprise-architect Brian Hopkins put it in a nicely ironic Tweet this morning, "I predict that the volume, velocity and variety of tech predictions will require #MapReduce to analyze by Dec 2012."... Hence, uh, no predictions as such here: apologies if that disappoints you... ]

For me, though, it’s been an interesting exercise to explore cycles within cycles, and the often urgent need to avoid the ‘gumption trap‘ of what Johnnie Moore terms ‘the Tyranny of Excellence‘:

We flounder when we over-react or repress failure. … [O]rganisations flounder if they set up procedures and practices that appear to be about excellence but are more about being in denial of our variability and complexity as human beings. Efforts to make meetings a guaranteed success quite often just lead to the repression of doubt or criticism. …

The risk is that we set impossible standards for ourselves and then get demoralised by not reaching them. The demand for perfection makes us hypercritical and we fail to appreciate what we are actually achieving. When we lose that sense of reality, ironically, we’re more likely to fail or perhaps to give up altogether.

(‘Flounder‘ seems a painfully-accurate metaphor there: a flatfish whose eyes have both migrated to the same side of the head, able to see only one side of the story… But I digress… – return to the story.)

That gumption-trap of floundering can be particularly destructive for those of us who have distinct peaks and troughs in our work-patterns. For example, looking back, I did quite a lot last year: amongst other things, I presented at three very different enterprise-architecture conferences, edited two books, and wrote coming on for two hundred blog-posts on enterprise-architecture and related themes – often three to four thousand words or more each, adding up to the equivalent of several entire books. And I spent a fair bit of time travelling for work, too: a longish stay in Australia, a shorter one in Brazil, and a couple other brief trips as well.

Yet there were distinct patterns in all of that. All of the conferences happened in the first half of the year, as did all of book-editing and most of the travelling; by contrast, most of the blog-posts were in the second half of the year, with a lot of intense work on themes such as metamodels, service-architectures, management-structures and ‘really-big-picture’ enterprise-architecture, and, currently, on tools-ideas and SCAN for sensemaking. Every now and then there would be a definite slump, a kind of ‘mini-burnout’ – I’m in one now, as it happens, where I’m struggling to get much of anything done at all, and on previous experience may well go on for another few days yet.

Within each day, there are definite cycles too. For me, my peak creative-time is usually in the mornings: best time for writing, anyway. The less- creative time in the afternoons tends to get used for editing, for doing diagrams, for – oh joy… – all the administrivia that our ‘sensible’ business-world currently requires. Sometimes in the evening I find myself back in the creative space; sometimes not.

If I try to force myself to do creative work in the off-cycle, I risk ending up doing no work at all, because the all-too-predictable feeling of failure can trigger that gumption-trap of floundering. Just to make things worse, as Paul Graham warns in his classic 2009 essay ‘Maker’s schedule, manager’s schedule‘, one interruption during that creative-time – or even just the threat of an interruption – can destroy creative productivity for the entire day: which again reinforces that sense of failure.

[The mindsets of 'makers' and 'managers' really don't mix - a fact I've been discovering to my cost whilst living in the same household as an elderly person who needs every day's activity to be regimented hour by hour on a rigid timetable, and who now literally cannot cope with any significant change of plan... Not fun, I can tell you: and seriously damaging to creativity, too... ]

And everyone has their own cycles, all of them somewhat different; and often those cycles will change over a lifetime, too, as the lethargic teenagers who can’t get out of bed before midday will change their habits when they become the parents awoken by a crying child at three in the morning. Daily cycles, yearly cycles, the cycle of a lifetime: cycles within cycles.

Yet what happens within most organisations? That’s right: we design systems that assume that people are machines, that they always work exactly the same all the time, in a measured, certain, predictable way. Or that they’re creative geniuses, every possible moment of every possible day.

And we then wonder why it doesn’t work.

Duh…

And then punish people for failing to work to our expectations. (Or teach them to punish themselves for ‘failing to meet expectations’, which comes to much the same thing.)

Oops…

So perhaps it might be a bit more wise to create organisational architectures that actually respect the fact that people are people? That they do each have their own cycles within cycles within patterns within flows within feelings, each subtly or strongly different? That some people indeed do not and cannot give their best work on a ‘manager’s schedule’? That that so-popular Taylorist attitude that regards people as second-class machines is perhaps a guaranteed path to mediocrity and poor performance?

Perhaps it might be more wise to respect people for who they are?

Strange idea for many managers, I know. But perhaps it’s the one that works?

And perhaps a reason why we really need to remind those managers that sometimes the best service they can provide to the whole organisation is to keep out of everyone’s way – such that the people who do actually make things can get their work done on their own natural schedules, rather than the ‘manager’s schedules’ of unusable, fragmented, discombobulated time?

Hmm…

Just reflecting on the passing year, the passing day, the passing time, that’s all.

[Update: as is so often the case, a perfect Tweet came up between writing this and checking Twitter - this time from Michelle James:

• CreatvEmergence: We need workplaces where people can engage and express more of their whole creative selves, not a reduced fraction of themselves

Expresses the point just as well as all of the above, really, and a lot shorter, too. Oh well. ]

This one started a couple days ago, with a straightforward Tweet-query from Dave Gray:

• davegray: “Strategy is design.” Agree or disagree? Why?

What followed was, for me, one of the best back-and-forth Twitter-conversations in recent weeks:

• nickmalik: @davegray design is a method.  Strategy is a result.  Fair to say good strategy may result from design, or luck, or intuition
• tetradian: @nickmalik @davegray would say that strategy tends to (or should?) come before design – or that they interweave with each other
• oscarberg: Strategy (what & why) primarily requires knowledge, tactics (how, when) primarily requires skill.
• davegray: @tetradian @nickmalik IMO a strategy is not a result. Profits, growth, revenue, etc. are results. A strategy is an approach. // hard for me to see how good strategy can be the result of luck. To me, it can’t be a strategy if it’s not intentional.
• mikerollings: @davegray @nickmalik @tetradian strategy must influence and be influenced by execution – you must be open to learning from happy accidents
• tetradian: @mikerollings @davegray @nickmalik “strategy must influence / be influenced by exec”n – open to learn from happy accidents” >strong agree
• davegray: @mikerollings 100% agree. @nickmalik @tetradian
• nickmalik: @davegray each step in a process produces a result.  The strategic dev step produces strategy as a result.  That step may use design, or not
• davegray: @nickmalik sure, strategy is a result of a strategic dev process, like a plan is the result of a planning process. cc @tetradian
• davegray: @tetradian @nickmalik it seems to me that design and strategy are both methods or approaches, ie, means to an end, with significant overlap.
• davegray: @tetradian @mikerollings @nickmalik 140-character limit constraining. Will write a post & try to make my point more coherently
• tetradian: @davegray @nickmalik in my exp., strategy sets out the intent, design is more about realising the intent (but also feeds back into strategy)
• ruthmalan: @tetradian @davegray @nickmalik Agreed Tom — you’ve better phrased my (playful) reply to Dave yesterday. Also consider: emergence vs intent
• davegray: @ruthmalan @tetradian @nickmalik I think this may be one of those times when words get in the way of meaning
• ruthmalan: @davegray [ @tetradian @nickmalik ]    or the lack of words? Can strategy, like meaning, be emergent? Or is it strictly intentional?
• davegray: @ruthmalan @tetradian @nickmalik strategy can intentionally create opportunities 4 emergence. Also unintentionally, but that’s not strategy // IMO a good strategy in uncertain environment preserves optionality & is ready to pivot quickly
• nickmalik: @tetradian two places where “design thinking” is used: developing strategy and implementing it. Which are we discussing?
• tetradian: @nickmalik design-thinking is used in both strategy and implementation; most of design-doing happens only in execution
• johnt: @davegray @tetradian From strategic planning to purpose and resilience http://bit.ly/vfJxaj >strong agree #entarch
• ArtBourbon: @davegray  @ruthmalan @tetradian @nickmalik looks like I missed a good discussion (strategy, intent, emergence etc)
• davegray: @mikerollings @tetradian I forget who said this: luck is when opportunity meets preparedness
• tetradian: @davegray @mikerollings “who said: luck is when opportunity meets preparedness” – Pasteur: see ch.3 and appdx in ‘The Art of Scientific Investigation’ http://bit.ly/7U1vgy
• mikerollings: @davegray @tetradian #nickmalik “Luck, Serendipity, and the Contextual Strategist” #entarch http://bit.ly/utJWnT >strong agree
• davegray: @mikerollings @tetradian I think context is part of it. Also important is a set of values/principles that guide decisions within the context
• tetradian: RT @davegray: @mikerollings “Also important is a set of values/principles that guide decisions within the context” >v.strong agree #entarch
• ruthmalan: @tetradian – thanks for ptr to The Art of Scientific Investigation – glad you shared it with Dave/Mike and we who follow y’all
• tetradian: @ruthmalan – glad you liked ‘Art of Scientific Investigation’ – one of my all-time favorite books! (eg. see end-summary chap. on Reason)
• ruthmalan: @tetradian There I was enjoying the Serendipity of the chapter on Chance Indeed, that end-chp summary on Reason is wonderful! Thx again!
• mikerollings: @davegray @tetradian values & principles are part of context, and there is no notion of the context setters & the consumer. We all do it.
• davegray: @mikerollings now you have lost me. Is there anything that isn’t part of the context? @tetradian
• mikerollings: @davegray Context=shared undrstndng within which we co-create. So there is context & doing. Some doing creates context w/ others @tetradian
• davegray: @mikerollings so our decisions & actions should be guided by shared understanding. Am I missing something important? @tetradian

As can be seen from the links above, the conversation triggered at least two excellent additional posts:

• John Tropea, ‘From strategic planning to purpose and resilience’ (mostly a long quote from Dave Pollard, but also a long list of pointers to other related articles)
• Mike Rollings, ‘Luck, Serendipity and the Contextual Strategist‘

My own view? I’d say they’re somewhat different: closely related, but somewhat orthogonal to each other. Strategy ‘is’ design in the sense of design-as-intent, but not in the more common sense of design-for-implementation. In that latter sense, strategy is an input into the design-process. Yet in a way strategy can also be in part an output from the design-process – especially when eliciting strategy for detail-layer changes. So yeah, it’s kinda complicated…

What happens when someone gets confused about the nature of different types of assets? Short answer: they try to treat everything as ‘possessions’ – and that’s when the lawyers have a field-day…

A great example of this is described in a BBC article (pointed to by LinkedIn), ‘Man sued for keeping company Twitter followers‘ (27-dec-2011).

The story revolves around social-media figure Noah Kravitz. During his time at tech-news aggregator Phonedog, he accumulated some 17,000 ‘followers’ to his Twitter-account there (@Phonedog_Noah). When he left Phonedog, he changed his username, and the followers either moved with the account, or moved to the new account (dependent on whether he changed the name itself, or moved to a new account – the BBC article doesn’t say). Phonedog regarded the followers as ‘company-property’ – as a ‘customer-list’, to be precise – which Kravitz had taken with him, and were suing him to get it back as their ‘rightful possession’.

There are so many fundamental concept-errors in Phonedog’s actions here that it’s difficult to know where to start… Yet they’re also very common mistakes in the broader business context: hence it’s worth exploring this from an enterprise-architecture / business-architecture perspective.

What we’re actually dealing with here is a fundamental misunderstanding of the nature of non-tangible assets, coupled with a fundamental misunderstanding about the inherent limitations of an economic model that relies on exchange of ‘rights’ of exclusive-possession over assets.

Let’s start by identifying four fundamentally different asset-dimensions:

• physical: a ‘thing’ – tangible, autonomous, exchangeable and alienable (“if I give it to you, I no longer have it”)
• virtual: information, ideas – non-tangible, semi-autonomous, exchangeable but non-alienable (“if I give it to you, I still have it”)
• relational: person-to-person connection – non-tangible, non-autonomous (exists between two entities), non-exchangeable and non-alienable
• aspirational: person-to-abstract connection – non-tangible, non-autonomous (exists from person to abstract), non-exchangeable and non-alienable

Assets may express multiple dimensions: for example, a printed book is both a physical-asset (the book itself) and a virtual-asset (the information or ideas in the book), and may also act as an anchor for aspirational-assets (people’s sense of connection to the book and/or to the ideas in the book). This linking of multiple asset-dimensions is often described as ‘bundling’.

The current economic-model relies on exchanges of ‘rights’ of ‘exclusive-possession’. It’s a concept that only makes sense with exchangeable and alienable assets – in other words, physical-assets. ‘Exclusive-possession’ does not and cannot make sense with any other asset-dimension. Yet since bundling of asset-types means that the rules for all asset-dimensions in the bundle will apply, the flawed assumptions of the economic model will seem to sort-of make sense as long as there’s some element of physicality in the bundle. But when that element of physicality is dropped? – well, that’s when things get, uh, interesting…

Hence the breakdown of the old media-industry business-models over the past few years. What they actually sell is information, but their old model were based on bundling – printed-books, physical disks, seats in cinemas – hence, with a bit of legal arm-twisting, it could be made to look like a physical ‘exclusive-possession’. But physical things are expensive, with all the concomitant costs and complications of managing them as physical assets: inventory, storage, shipping, building-maintenance, retail-stores and so on. Much cheaper to go all-digital. Which, however, then becomes an unbundled virtual-asset – which can only be exchanged by creating copies, which can then also be exchanged by creating further copies, and so on, all without any exclusive-’alienability’. Oops…

Hence the media-industries first tried an old tactic, which was to use the law of ‘copyright’ (which was and still is focussed only on the ‘possession-rights’ of publishers, not authors) to assert ‘possession’ over those virtual-assets. But the nature of information is that it ‘wants to be free’ – not necessarily in a monetary sense, but in that it’s only usable/accessible by creating copies, and copies of copies, and copies of copies of copies, which at some point will slip outside of any attempts at ‘control’.

Law alone didn’t work, so the next tactic was to try to control some crucial point in the physical ‘pipe’ for information: hence demands that the computer-industry should redesign all processor- or interface-chips to include ‘digital rights management’ that would be controllable only by Hollywood and their ilk. Not surprisingly, that didn’t go down very well with content-creators themselves – or the computer-industry, who happened to have their own lawyers and lobbyists too. Result: expensive stalemate – and still no ‘control’ of those naturally-volatile virtual-assets.

That’s been followed by one attempt after another to ‘control’ information, mostly by threats of legal action and the like. What the media-corporations are still not doing is facing up to the fact that not only is it inherently futile to try to control virtual-assets as if they’re physical, but doing so calls into question the theoretical and ethical basis of the entire possession-economy – physical-assets included. Definitely ‘oops’…

Which brings us back to the Kravitz/Phonedog case.

In that schema above, Twitter-follows are, in effect, a bundling of relational-asset (the perceived person-to-person link between the ‘follower’ and Kravitz) and virtual-asset (the information within Twitter that denotes the link) plus a certain element of aspirational-asset (because with some 17,000 ‘followers’, most of those will be more a link to the idea of Kravitz rather than a true relational-asset person-to-person link). What there isn’t anywhere in there is any physical-asset component – and hence nothing on which a notion of literally-exclusive ‘company property’ can make any sense.

I presume that somewhere there will be some utility that can extract a follower-list from Twitter – in other words, create a sort-of transferrable virtual-asset that Kravitz can give to Phonedog. Yet in practice even that makes little to no sense. First, the followers are not ‘customers’ in a transactional sense, either of Phonedog or of Kravitz: they’re just people who have a passing interest in what Kravitz might happen to say, an interest that may or may not relate to Phonedog as such, even in Kravitz’s (literal!) persona as ‘Phonedog_Noah’. It’s a trust-relationship, not ‘customer’-relationship. And second, transferring the list does not transfer the relationship: in fact it’s more likely to kill any potential relationship with the company, because it implicitly treats the ‘followers’ as if they themselves are nothing more than exchangeable ‘possessions’ – which many (most?) people would take as a fairly extreme insult. Certainly not conducive to creating trust, anyway.

In short, Phonedog’s attempts to ‘possess’ the relationships have all but guaranteed making it impossible for Kravitz to transfer them. The relationships are not under his control: relational-assets are real assets in a business sense, yet they exist only whilst they’re maintained by both parties to that relationship. The only direct option he has within Twitter is to destroy the link, by blocking: he can’t create a new ‘follower’ link, or transfer the link to someone else. (The equivalent is true with direct person-to-person links, of course.) Suing him for damages, about something that by definition isn’t in his control anyway, is both absurd and unfair.

There is (or, by now, probably only was) another option: emphasise the aspirational-asset element (person-to-idea rather than person-with-person), create a strong crosslink between the idea of Kravitz-as-employee-of-Phonedog and the idea of Phonedog-the-company, and use that crosslink to gently persuade Kravitz’s followers to also ‘follow’ Phonedog. (Note that a ‘follow’ to a company has a much higher aspirational-asset component than relational-asset component – something I probably need to explain in another post?) But all of that depends on fairly complex multi-way trust-relationships: for example, the followers need to trust Kravitz’s recommendation, and Kravitz also needs to trust that Phonedog will treat ‘his’ followers with similar respect. And again, there’s not much of those trust-interactions that’s under Kravitz’s personal control – hence again it makes little sense to try to assign him the sole legal responsibility for them.

In practice, Phonedog has done just about everything that they could do to destroy all of those trust-relationships – and then, having done so, tried to blame and even punish everyone else for their ‘loss’.

Not exactly wise, we might say?

Yet also not exactly uncommon, either. Quite the opposite, in fact…

The moral of this sad story, from an enterprise-architecture perspective, is be clear which asset-dimensions you’re dealing with in every context, and ensure that those assets are managed accordingly. Because if you aren’t clear about it, and fail to handle each asset-dimension appropriately, your organisation will inevitably find itself in this kind of mess. And the only people who ‘win’ from this kind of mess are the predators, parasites and scavengers in the legal-profession and elsewhere. Oh joys…

Over to you, perhaps?

A kind of announcement, really: a knowledge-base wiki for whole-enterprise architecture is now available and ready for content and use.

I’ve given it a temporary home on my Sidewise server:

• http://ea.sidewise.biz

No doubt it should have a proper domain of its own, but that’ll do for now to get us started.

[By the way, this is another follow-up to my post 'Helping others make sense of my work' - the need for a wiki was a suggestion that came up several times in the comments there.]

It’s a fairly straightforward wiki, based on the WikkaWiki framework – probably the cleanest and simplest wiki-framework I’ve come across. (I’ve struggled with many such frameworks over the years, of which Wikipedia is almost the worst…) Like all wikis, though, it does have its own quirks, hence some quick comments:

– Anyone can read, write or comment. (That’s the default: there’s actually a full access-control system for read, write and comment, all the way down to individual page-level, but that’d take too long to explain here.)

– However, to write, comment or edit, you’ll need to register a user-account. (There’s no charge for this, of course, and should be no privacy-implications: it’s just to stop spam-bots using the site.) There’s a quick summary on how to do this on the wiki home-page.

– One minor ‘gotcha’ is that user-names need to be in wiki-format – what’s known as ‘CamelCase’, beginning with a capital-letter and with at least one additional capital-letter after the start. For example, my user-name is ‘TomG’; you might make yours ‘FredBloggs’ or VikusVdM’.

– Editing is straightforward: click the ‘Edit’ link on the left side of the page-footer, or double-click on the page itself. The ‘Store’ (save) and ‘Preview’ buttons are at the lower-left when you’re editing.

– Formatting is a lot simpler than most wikis: in many cases it’s two repeated-characters. See the ‘Wiki formatting guide’ that’s linked from the home-page. Links are straightforward: ‘[[', then the page wikiname (internal link) or URL (external link), then a space as separator, the link-text, and ']]’.

– Usefully, a page can include a FreeMind-format mindmap: paste the FreeMind XML into the edit-space as the page-content. Read-only, unfortunately, but it’s an easy way to share mindmaps.

– Upload of images and other files is a bit more difficult, and at present only administrators can do it. I’ll hack the code as soon as I can, to allow a broader range of users to upload, but in the meantime, if you want to upload a file, send it to me and I’ll upload it for you.

I’ve put up some initial content to get started – a few dozen definitions, a couple of articles, and a whole load of links to other posts elsewhere – and I’ll continue putting more material up there over the next few days and weeks. But the rest is up to you, really: it’s everyone’s site, not just mine.

Anyway, it’s there, and usable: over to you?