Tom Graves / Tetradian

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?

In designing management-structures, why is it so often assumed that responsibility-relationships only go one way?

Our organisations often place enormous attention on insubordination, a refusal or failure to follow ‘orders from above’; yet why don’t they place the same level of attention on insuperordination, the refusal or failure to respect the the same relationships and responsibilities to those ‘below’?

For that matter, why do we still prop up the misplaced myths of ‘above’ and ‘below’ anyway? After all, in a service-oriented view of the enterprise, there is no hierarchy - they’re all just mutual peer-level service-relationships, no different in nature from any other. And does anyone benefit from those myths any more? – other than people who need to prop up arbitrary and unwarranted delusions about their own importance?

This came up for me today from three different directions:

• reviewing several posts here on management-architectures, particularly ‘Rethinking the architecture of management‘, ‘Management as ‘just another service’ ‘ and ‘Rebalancing top-down management-architectures‘
• a Tweet from SystemsWiki, pointing to a brilliant HBR paper by Gary Hamel, First, Let’s Fire All The Managers‘ [PDF]
• thinking about ‘bosses’ I’ve known – some good, some not-so-good, and some just plain incompetent

I’ll happily give names to the good ‘bosses’ – Helen Mills at Australia Post, for example, or Graeme Burnett at DSTO. For the others, well, I’d best be a bit more circumspect, hadn’t I? – which is an interesting point in itself…

But there’s one of the latter that comes particularly to mind. It was on a large engineering-project a couple of decades or so ago; almost all of the team were contractors, some of them world-class level, because it was a genuinely innovative system that had to do things that had never been done before. To make it all work, and to hold the team together, we needed a manager at the same kind of skill-level. What they gave us instead was – to be blunt – an incompetent idiot, a classic civil-service time-server, eking out his last years before retirement. Not a good choice…

He was way, way out of his depth and his comfort-zone – a fact that became painfully obvious even before the first day was out. He had no experience or understanding of the inherent anarchy of innovation: as an ex-military-type, all he knew was command-and control. Which really, really, really didn’t work.

We limped on under his endless incompetence for a few months, until one day it all came to a head. At a particularly fraught team-meeting, every one of the contractors blew up at him, saying that he alone was the reason why the project was so far behind schedule; furious, he rushed out, accusing everyone of insubordination, and yelling – and I quote – that “I’ll have all of you frog-marched out of the establishment!”

At that point, the executive realised they needed to intervene, kinda urgently… The team explained to them that whilst, yes, they would perform best with a good manager, they would actually be better off with no manager at all than with this guy. And for once – hooray! – we actually had senior-management who had some real grasp of what was going on – and they agreed. So for the rest of the project, we ran as a self-organised team, without any manager at all.

In short, our incompetent manager had been fired for insuperordination – failing to deliver the required management-services to the level needed within that context.

Looking around at most management-structures, it’s clear that that needs to happen a lot more often…

And this, of course, is where it can get v-e-r-y tricky for enterprise-architects and the like. We can see what’s not working. We can see why it’s not working. We know exactly what to do to get it working again. And yet we’re supposed to pretend that the myths of management-hierarchy are somehow sacrosanct, that insubordination is real and punishable, but insuperordination and plain management-stupidity is not. We’re allowed – in fact required – to ‘fix’ anything and everything except that which is the blatant cause of the problems, namely those myopic myths of management, which we’re not allowed to challenge at all. Hmm… About time we started being honest this, don’t you think?

Implications for enterprise-architecture

Insuperordination isn’t just lack of leadership: it’s a structural failure of the management-model to support essential symmetries of responsibility in mutual service-relationships.

And as a structural flaw – one that has serious impacts on overall enterprise risk – it’s very much a concern for enterprise-architecture.

The key requirement here is to stop thinking in terms of hierarchies. If we take a service-oriented view, it’s clear that management-services have a very real function, as information-aggregators and resource-distributors, dealing with the trade-offs across a functional-silo.

Yet those types of services are not well-suited to managing end-to-end cross-silo process-flows: there needs to be a separate category of coordination-services that handles that task – a fact which immediately implies matrix-relationships of some kind.

And those matrix-relationships need to be peer-to-peer – which doesn’t fit at all with any Taylorist-style concept of top-down management-hierarchies.

In short, top-down ‘command-and-control’ hierarchy is an overlay on top of a tree-structure that arises naturally from aggregator/resource-distributor relationships. The tree-structure provides a genuine service; the hierarchy, all too often, a genuine disservice. Don’t conflate the two structures: they’re not the same.

The way to separate them is that the tree-structure could be viewed in any orientation: top-down, bottom-up, sideways-in, centre-out – it’s all the same. But the hierarchy is always described as top-down: it can’t be made to (seem to) make sense in any other way.

The top-down management-model is essentially a leftover remnant of a supposedly long-dead feudal past, in which position in that hierarchy denotes ‘rights’ to demand subservience on pain of punishment for ‘insubordination’. As a structure based entirely on ‘power-over‘ – with all the dysfunctionality that that implies – it can only be made to seem to work as long as there is no need to engage the ‘subordinates’ actually in the work: “check your brain in at the door” is how one colleague described it. But when the work does require that kind of personal engagement – as is becoming more and more common throughout almost every business context – then the overall system will either operate only at low efficiency, or even fail to operate all, if that ‘conventional’ command-and-control hierarchy is allowed to remain in place.

It’s an architectural choice. Command-and-control hierarchy will only work with low-agility: if we need to preserve command-and-control hierarchies, we will not be able to achieve high-agility in that context. If the organisation – or some part of the organisation – needs high-agility, we must define a structure in which that section of management is peer-based, as ‘just another service’ – and in which the responsibility-failures of insuperordination must be recognised as exactly symmetric with insubordination.

In any given context, we can choose one model, or the other: they don’t mix well, and we can’t have both in the same context – as even current military doctrine [PDF] now makes clear.

If we want our organisations to work, we need to stop pretending that insuperordination doesn’t exist – and instead acknowledge that it’s one of the most serious sources of organisational risk.

That’s the message that we need to give to our enterprise-architecture clients.

Challenging, yes – but it’s the only way that this is going to work.

Comments/suggestions, anyone?