Tom Graves / Tetradian

Nice to see that even the ‘big fish’ are finally ‘gettin’ there’ on the real scope of enterprise-architecture…

A month ago we saw Open Group begin to re-frame their previous IT-centred approach to EA into a new style of ‘enterprise transformation’. (The conference was still more IT than anything else, of course, but at least it’s a solid move in the right direction.)

Then a couple of weeks back it was academic and EA-luminary Jeanne Ross making clear her opinion that enterprise-architecture does not belong in IT, under the CIO. To quote her interview in CIO.com, “companies need to acknowledge that ‘architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO’”.

And now it’s Gartner, at this year’s Gartner Enterprise Architecture Summit in London earlier this week. I wasn’t able to get there this time, as I’m currently ensconced in central-America working on a bunch of EA-related projects; but fortunately the indefatigable Gerold Kathan was there, sending out a whole stream of useful tweets:

• gkathan: #entarch has no value until it is acted upon – deliverables should not be confused with value #gartnerEA
• gkathan: customize and adapt your #entarch framework – industry frameworks should be used for inspiration, not perspiration #gartnerEA
• gkathan: bringing something new like #entarch into top level management is hard: they will treat it as enemy in the beginning #gartnerEA
• gkathan: “EDD” is impacting application lifecycle: “executive deficit disorder” – short term focus and irrational decisions #gartnerEA

But what really caught my eye was this little beauty:

• gkathan: you have to reach out the 4 walls of your organization – extended enterprise includes e.g communities #gartnerEA

To which I can only sigh ‘Hooray!’…

I’ve no idea which of the Gartner consultants it was who said it; and since Gartner itself seems to have a policy of not crediting ‘outsiders’, I’ve also no idea if that comment has any link to the various conversations I’ve had with Gartner folks over the years. But just for the record, here’s my version of the full scope that an organisation’s EA must address, all the way out beyond the market to communities and more:

I’ve used a few variants of that in my EA presentations over the years – such as ‘What is an enterprise?‘ and the very-popular ‘The enterprise is a story‘ – but that’s the core idea, anyway. Nice to see that Gartner too is at last officially acknowledging that kind of scope for EA.

On the other side, I ought to acknowledge another ‘big fish’ that sort-of got there quite a long time ago. I was trawling through my downloads on this little-used netbook, and came across a report from Infosys – ‘Enterprise Architecture Expands Its Role In Strategic Business Transformation‘ [PDF] – from way back in 2008. It seems that even back then, the IT-centrism that still dominates ‘the trade’ was beginning to be challenged a lot more than most of the ‘big fish’ would be willing to admit:

Architecture steps out of the scope of IT and becomes part of planning and implementing strategy. In 22% of responding organizations, architectural processes are already being used for general business transformation.

And there’s this in the report, too:

Transformation is implemented in multiple streams within multiple units and functions of the firm. Today’s approach of architecture – looking at everything outside of IT as ‘the business’, and trying to access it through fairly generic, coarse-grained models – is bound to fail. A future enterprise-architecture will be ‘the architecture of the enterprise’. It will need to address the whole organization and each of its functions through appropriate models which are meaningful to the specialists of each area, and help them drive transformation. This means that it will have to provide structured models to represent architectures for production, research, finance and HR – much as it has for IT.

There’s a subtle trap in that that view is still centred around the organisation – ‘inside-in’ or ‘inside-out’, rather than the essential ‘outside-in’ view indicated in the Gartner quote above –  but at least it’s a lot broader than the obsessive IT-centric view that predominated then, and is still all too common even now. Credit where credit’s due – and worth reading the rest of the interestingly prescient report, too.

Gettin’ there, anyway – slowly, perhaps a bit too slowly for comfort still, yet we are gettin’ there. Feels good.

The real art of enterprise-architecture, and perhaps its hardest challenge, is in presenting the right level of detail. Not too little, not too much, but just enough.

Just Enough Detail.

To which people will, of course, immediately ask, “Okay, but how much detail is ‘Just Enough Detail’?”. And I’ll have to admit that there isn’t a simple. certain, predefined answer. You just have to kinda know when enough is enough, you know? – which is why it’s more art than science, I guess. And why experience – usually gained by not getting it right… – is so important here.

One thing I do know is that one of the most-quoted answers is usually just plain wrong for this. John Zachman has always said that we need to document everything in ‘excruciating detail’. In a sense, yes, he’s sort-of right, especially if you hold to his metaphor that enterprise-architecture is essentially the same as engineering an aircraft. (I happen to believe that that’s a seriously-misleading metaphor, but that’s another story.) Yet in the real world – even in aircraft-engineering, as I know from much first-hand experience – much of the detail won’t stay the same for long enough to make that ‘excruciating detail’ requirement achievable in practice. Tricky…

Reality is that everything changes, everything moves. And the more they change, the more the demand for ever-more-detail becomes a trap. And when the pace of change itself is accelerating fast – as is definitely the case in most enterprise-architecture contexts right now – the more dangerous that ‘too-much-detail’ trap becomes, and the more we risk falling into it.

Yet on the other side, not enough detail means we won’t have enough of an anchor for meaningful sensemaking or decision-making – so we risk making bad decisions on the basis of too many arbitrary assumptions. That’s not a good idea either.

Hence Just Enough Detail.

The point is that that ‘just enough’ of Just Enough Detail varies all the time, from context to context, depending on who we’re with, what we’re doing, what we’re aiming to do, the type and rate of change, and all manner of other factors. Take this example from one of my favourite ‘show this to clients’ books, Matthew Frederick’s 101 Things I Learned In Architecture School:

There’s actually not much detail in that image. There’s no detail at all of the wall – and yet that’s still enough detail to make out that it is a wall (and probably a white-plaster wall at that). Other than the outline, there’s almost no detail of the woman, or her clothing – and yet it’s enough to get a good sense of who she is, what she looks like. There’s a bit more detail of the church and its dome – enough to tell that it is Brunelleschi‘s masterpiece in Florence – and of the townscape around it. Not much detail, then – and yet that’s all the detail it needs to tell the story. Not too much; not too little; Just Enough Detail.

So, over to you: how much or how little is Just Enough Detail in each part of your enterprise-architecture? How do you show that Just Enough Detail to whoever needs to see the story?

How much does Just Enough Detail change between different layers of abstraction, between different audiences, between backbone versus edge?

How do you know when it’s too much detail, or too little? How do you know when it’s just right? – when it’s Just Enough Detail?

How do you learn this delicate, ever-changing balance of ‘just enough’? From where and in what ways do you learn that balance – without causing too much damage whilst learning it?

Just Enough Detail, always. An interesting challenge, yes?

Hooray hooray hooray! – the message is finally getting through!

This from an interview with MIT-CISR‘s Jeanne Ross in the current (29 April 2012) online edition of CIO.com:

Myth: CIOs should own enterprise architecture. Not so fast. CIOs often wind up accountable for the entire enterprise architecture, despite not typically having the authority or vantage point needed to create one that provides what the organization needs. This leads to a disconnect. “When the CIO owns enterprise architecture, it’s a bad fit,” says Ross. “IT is being asked to do something the organization isn’t committed to.”

In reality, companies need to acknowledge that “architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO,” says Ross. “If the CEO doesn’t accept that role, there really can be no architecture.”

Yep, that’s exactly what we’ve been saying for, oh, well over half a decade now – with the full explanation of why we’ve been saying it, too. But now that the same is being said by such an EA-luminary as Jeanne Ross, perhaps there’s some chance that it might actually be heard at last?

Here’s hoping, anyway…

At least he was open about it, I guess. “Tell you what I’ll do”, he says to my colleague here in Guatemala, “I’ll find you a client, then I’ll sit in, learn everything you do, and then I’ll apply it in my own business. How does that sound to you?”

Uh, no. Not a good idea. Not just because it’s a really bad deal from our perspective, but much more that Reality Department really doesn’t work that way: there’s no short-cut to experience.

Yes, it all looks simple enough – in fact that’s the whole point. A lot of simple visual summaries, and surprisingly simple-seeming methods, too. Yet it only looks simple because we’ve been through a heck of lot of hard work to make it that way. Hard-won experience, won the hard way through years and years of practice in many, many different contexts, getting it ‘wrong’ time and time again, in many, many different ways in order to get it right.

The real trap is that these simple-seeming ideas and methods aren’t simple rules, prepackaged sense-making and decision-making that will always work in every context. These are simple principles, simple guidelines, the kind of easy-to-memorise information that helps decision-making in real-time, in circumstances that are subtly different every time. (See my SCAN posts for more on these distinctions.) If you try to use them as ‘rules’ for inherently-uncertain contexts, without understanding why those principles apply, or how they need to be tweaked every time to match each different context, you’re going to be in real trouble – along with everyone else around you. Not a good idea…

The same often applies even to things that really are ’rules’. Take that example of perhaps the greatest simplification ever made: e=mc². All the core information you need to build a nuclear power-station is right there in that equation: but there’s a heck of a long way – a heck of a lot of engineering-experience – to go from that one equation to building a nuclear-power station that actually works.

Same with everything else, really: simplification is essential, but can also be deceptive – especially when people mistake ‘simple’ for ‘easy’…

Which is also why I get a bit hot-under-the-collar about the current proliferation of ‘certification-schemes’ in enterprise-architecture and elsewhere. Some of them are genuinely valuable, but others – to be blunt – are little better than money-spinning scams, in terms of the actual value that they (don’t) deliver. And the crucial distinction revolves around the role and recognition of experience.

For example, the TOGAF Foundation and Archimate Foundation certifications have real value. They verify that the respective person has a credible command of the terminology and language – a requirement that matters a lot for communication across a dispersed and disparate team.

Likewise the ATAC certifications should have real value, because each explicitly tests practical experience in the respective area.

But unless they’ve changed it in the past year or so, the full TOGAF certification is delivered through the absurdly-inappropriate mechanism of a multiple-choice test. And to my mind, that’s not merely useless, it’s actually worse than useless, because it’s exactly how not to test for the kind of experience that that type of competence requires. (When I did the TOGAF 8 exam some years back, I almost failed because I answered several key questions correctly in terms of real-world experience, rather than the theory-based wrong-assumptions that the test thought were ‘right’.) The result of that kind of pseudo-test is a bevy of people who can wave a certificate around, but have no idea how to do the work in any real-world context.

A good training-course can make all the difference, and the better training-providers do take up some of the slack here. (I’ll wave a flag at this point for John Polgreen at Architecting The Enterprise, who’s been doing sterling work for years on adapting TOGAF for the US-government context.) Yet none of that competence carries through anywhere into the actual test: so unless we know each of the training-providers, we have no way to tell whether a candidate does actually know what they’re doing, or merely that they have a piece of paper to prove that they know just enough to get into real trouble, but not enough to get out of it again.

In effect, right now, the full TOGAF certification is of less real-world value than the Foundation certification – which is both bizarre and sadly pointless. And I’ll hasten to add that I’m using TOGAF here merely as one example amongst many: it may well be that most of the so-called ‘certifications’ in this field are even more meaningless than that. And the results can be seen everywhere in the trade…

In short, it’s a mess.

What we need to be testing for is genuine understanding of a context, and the ability to adapt for uniqueness. And that calls for much, much more than can be covered in a crude multiple-choice test delivered through a mindless machine. Sure, that kind of test is cheap, and relatively easy to administer: but it’s also all but meaningless for anything than foundation-level rote-knowledge. It really does take years of painful practice to develop the experience needed to do this work well: and if this trade is to gain the credibility that it needs, we need to stop pretending that we don’t need to test for that experience.

Time to re-think how we do this, and how we respect this, too: there’s no short-cut to experience.

A lovely one-liner and follow-up from Kevin Smith (of PragmaticEA / PEAF fame), in a Skype conversation earlier today:

Is the EA the DJ?

He doesn’t tell people how to dance.

He provides the music for them to dance to.

He sets the mood.

He sets the tempo.

http://www.youtube.com/watch?v=oq71rV2FXSI

http://www.electronicarchitecture.co.uk

Listen. Feel. Connect. Interact. Imagination. Innovation.

Just thought it was an idea worth sharing, is all.

If it’s not a cycle, don’t call it a cycle.

In the past few days I’ve had a fair bit of struggle to get clients to understand the difference between a linear-sequence with a beginning, a middle and an end, versus a true cycle where the end of one sequence links to or becomes the start of the next.

Cycles are literally cyclic: they’re not just linear sequences, they repeat, often in self-similar ways that are rarely ever quite the same. And the problem is that there are a lot of so-called ‘cycles’ that aren’t cycles at all. Some examples:

• Tuckman’s ‘Forming, Storming…’ lifecycle
• Adizes’ organisational lifecycle
• Gartner’s hype-cycle

At root, these are just linear sequences. For example, Tuckman’s ‘Forming’ stage (purpose) leads to ‘Storming’ (the all-too-necessary-yet-often-avoided people-stuff), thence to ‘Norming’ (planning and preparation) and ‘Performing’ (the actual process of delivering the project). And there it stops: if we’re wise, there’ll also be a final ‘Mourning’ or ‘Adjourning’ phase (closure, completions, lessons-learned), but as far as the individual project is concerned, that’s it. The End – the end-point of a linear sequence.

It’s not a cycle.

To make it a cycle, we need to be able to link the end of one sequence to the start of another: ‘Adjourning’ feeds into and informs the ‘Forming’ of the next project.

Once we have a true cycle, iteration-effects such as complexity and emergence start to appear; continuous-improvement becomes possible; agile self-adapting strategy in a fast-changing environment starts to make sense.

Yet those benefits only become available or visible where there’s a true cycle – not merely a one-shot linear-sequence that happens to call itself a cycle, but isn’t.

Cycles enable visibility of iteration-effects; one-shot linear-sequences don’t. And it confuses the heck out of people that we can have those two very different types of structures arbitrarily assigned the same name.

So if it’s only a linear-sequence, call it a sequence. If it’s a true iterative cycle, call it a cycle. If, like Tuckman’s project-lifetime model, it’s a sequence that can also be linked back to itself to create a true cycle, call it a sequence when it’s a sequence, and a cycle when it’s a cycle. Don’t mix them up!

In short, if it’s not a cycle, don’t call it a cycle. Please?

Enterprise-architecture is dead – long live enterprise-transformation! Or so it would seem, from the description of the current Open Group conference at Cannes.

Yet is all as it seems? I’d have to admit that the conference-programme does worry me a bit. Despite the presence of a fair few people with a broader view than just IT – Alex Osterwalder, Len Fehskens and Stuart Boardman, to name just a few – so much of it still seems to be the same-old search for the ‘next big thing’, the next soon-to-fail IT-based magic-bullet: currently ‘Big Data’, mobility, cloud, cloud and more cloud. Oh well.

A bit of history might be relevant here. Back at the start of the 20th century, the electric motor was the great ‘next big thing’. Huge excitement! – huge hype! – the electric motor will solve everything! No doubt that it transformed industry: freed at last from that terrifying tangle of belts and pulleys, machines now placed wherever fits the workflow, smaller, more compact, more convenient. A whole new infrastructure to power it, control it, monitor it, measure it, manage it.

(Sounds familiar, perhaps?)

And finally, when electric motors were literally everywhere, embedded in almost everything, the realisation that although the electric-motor is an important enabler, it’s only an enabler: isn’t the enterprise itself.

The enterprise isn’t solely about machines, or information, or ‘making money’: it usually includes all of those things somewhere within the overall picture, but first and foremost it’s about the hopes and desires and aims of people. If we ever forget that fact, there’s no space for enterprise – and hence nothing against which enterprise-architecture, or enterprise-transformation, could ever make sense.

As Simon Sinek puts it, any enterprise-scope work must always start with ‘why’: the ‘how’ and ‘with-what’ come later in the story. And for enterprise-architecture that ‘why’ must always be about the whole of the scope – not solely about some arbitrarily-selected subset. Open Group’s TOGAF is excellent for enterprise IT-architecture; yet its rigid focus on IT (as defined in sections B, C and D of its Architecture Development Method) renders it problematic at best for anything else in the enterprise-architecture space. It’s fixable, as I’ve explained at various Open Group conferences and elsewhere over the past five years or so: yet still that kind of update has not been applied to the ADM, and in that sense TOGAF 9 represented a sadly-missed opportunity. As a profession, we need to do better than that.

To give some idea of what I mean by ‘the enterprise’ – and hence its architecture and its transformation – take a look at some of the projects I’m exploring at present in Latin America:

• a medium-sized brewer needing to resolve problems with internal theft
• a large manufacturer addressing multi-way ‘cultural translation’ between Asian ownership and executive, US management and methods, and Latin engineers and workforce
• a government department working with a film-producer to use social-media to break the cycle of mutual distrust between police and schoolkids and teenagers in the slum-districts
• an NGO wanting to use the ubiquity of cell-phones as a means to improve health-care in widely-dispersed indigenous communities

It’s likely that in each of these contexts, an enterprise IT-architecture will play some important part: but the IT itself is not the sole focus of the overall task. To make any of those transformations work, we need to start from people, not IT – start from enterprise as enterprise – and keep that whole enterprise in mind at every moment.

It may well be that enterprise-architecture is dead – but if so, it was killed by inanely inappropriate IT-centrism, in Open Group and elsewhere. As we move to a nominally broader-based enterprise-transformation, could more effort be made to ensure that we do not repeat the same IT-centric mistakes? Please?

A great Tweet from Oscar Berg this morning:

• oscarberg: IMO #socbiz is primarily a mindset&way2see business in increasingly connected & digital age

I think he’s exactly right there: in essence, ‘social business’ is a different mindset about the way a business relates with others, and also with itself (as in the now seemingly-all-but-forgotten ‘Enterprise 2.0′).

But there’s a real booby-trap there that it’s essential to avoid (and that too many people did fall into with ‘Enterprise 2.0′). And that’s that this is not about the technology: it’s about the connections.

Okay, we’ll be fair about this, and agree the new digital technologies are important, as enablers of connections that would otherwise be hard (but not impossible) to set up via other means. As Andrew McAfee once put it, we’d have to agree that “it’s not not about the technology”.

Yet in social-business the connection is what matters: the ways we connect are always of secondary importance relative to that core focus.  If we ever lose sight of the fact that the technology is merely an enabler of connection, and not the connection itself, we’d be in real trouble real quick, with no way to see why we’re in trouble. Oops…

Something always to keep in mind here, please?

[A collection of notes that I made somewhen around May 2010 that I don't seem to have published before, and seem to be relevant now as I explore my own business-model. (Not an April-Fool joke, by the way. ) ]

A culture [enterprise-culture] is a set of prioritised values and goals – usually ill-expressed, conflicting, a muddled-mixtures of tacit and explicit. (Can be revealed by POSIWID – ‘the purpose of the system is what it does’.)

An enterprise begins with a vision.

A vision is a single emotive idea (a ‘parti‘, in architectural terms).

Values are used to identify what is and is not aligned to the vision.

The vision is the heart of a story; the enterprise is that story.

The organisation does not define the story - the enterprise does.

The organisation can choose which story to serve, and its role in serving that story.

The values of the enterprise provide a means to identify [and measure] alignment to the story.

The organisation can change its choice of enterprise to serve; yet doing so may (will) disrupt the values and prioritisation of values on which the organisation at present depends.

The story is the journey itself – there is no ‘final destination. (If there is a goal, the story will end, and likewise the reason for the organisation’s existence; so if there is a goal, plan from the start as to what will happen when the story ends.)

The structures and strictures of the organisation are a means to serve the story.

If you change the choice of story, you’re asking every person in the organisation whether they want to be [remain] in the organisation – to reconsider their ‘reason to be’, in relation to the enterprise and organisation. Not a trivial change!

Every person is ‘in’ multiple enterprises – prioritises which story (or stories) they serve.

To be successful, an organisation provides a clear prioritisation of stories.

The enterprise determines quality - what quality is. The vision is the ultimate anchor of quality (as per ISO-9000).

In the market-model, markets are:

• transactions (physical)
• conversations (virtual)
• relationships (relational)
• purposeful (aspirational)

Markets are all of these things, all together. (There’s a crosslink to here to effectiveness: for example “cheap, easy, gets all the shopping done in one go” etc.)

Market-sequence or market-cycle:

• reputation (also crosslink to vision); trust and respect (relational dimension)
• brand is ‘pre-packed reputation’
• attention and conversation (shift to virtual dimension)
• is often the preferred starting-point in the cycle (hence advertising, pre-brand)
• transaction (physical dimension), profit as ‘extracted value’
• transaction-only is (overly-simplistic) machine-model of the market
• needs full completions – customer, market, shared-enterprise – to complete the cycle and (re)affirm reputation

Hence ‘cost’, ‘profit’ etc are multi-layered – determined by the values of the enterprise.

[A possibly-useful item from the archives - hope it's of some value to someone, anyways.]

Still going round my all-too-usual loop: what the heck am I doing here?

(In a business sense, of course… )

This is a follow-on to my previous post ‘Don’t start with How‘ – about how I’ve been needing an urgent rethink of all my websites and other stuff, and how I ended up going round and round in circles in that rethink by starting from the How. What I need to do instead is follow Simon Sinek’s advice – and my own advice too – and start with Why.

So okay, let’s start this dance again. From the top, please, folks?

So what is that ‘Why’? What the heck am I on about? Nearest I can find is a summary I’ve used often for enterprise-architecture, and which fits well with everything else too: that things work better when they work together, efficiently, reliably, with elegance, on purpose.

That tag-line is actually about the four-and-a-bit dimensions of effectiveness, hence I could rework it into something quite a bit shorter, and closer to a proper enterprise-vision:

• making things more effective, for everyone

Okay, so I don’t make many things as such – more I mostly think things… (Well, someone has to do that, I guess?) And phrasing needs to be much better, tighter, too. But it’s adequate as a start for now.

So how well does that tie in with my existing business-tag-line, “the futures of business“? The short-answer is ‘sort-of’ (if only somewhat ‘sort-of’…). For example, it gets to be a problem if I have to explain what ‘futures’ is, before I can even start…

(But it’s not as hard as the endless struggle with trying to explain what ‘enterprise-architecture’ is and does… )

The business-focus of what I do is business-transformation.

(Which is about futures, and change – yet also conveniently avoids the no-no word ‘change’ itself… )

This focus on transformation can go all the way from very-big-picture to fine-detail.

(Hence tools such as Enterprise Canvas and the ‘This’-game.)

…and all the processes of doing / thinking / relations / purpose that guide that business-transformation.

(Hence context-space mapping, the tetradian, SCAN, SCORE, the ‘This’-game and so on.)

…to bridge between strategy and execution.

(Including the big-picture scope that comes ‘above’ or before strategy, and the unchangeable-past that comes after execution.)

…it’s about how it works as a whole, for everyone.

(Which, again, is about the really-big-picture, and concerns such as whole-enterprise scope, ‘anti-clients’ and the human aspects of enterprise.)

 …a focus on responsibility and ‘response-ability’.

(Hence the SEMPER diagnostic, and tools such as RACI-maps – and also, at the really-big-picture level, ideas around responsibility-based economics.)

…and, in parallel with that, an emphasis on the human side of systems.

(Hence the book and ‘manifesto‘ on the human side of business-architectures.)

…which links to the role of story in business-transformation and the various architectures of the enterprise.

(Hence a whole swathe of posts and other explorations here, various presentations and the like, and, of course, another book.)

… there’s the notion of service, and the architecture of the ‘service-oriented enterprise’.

(Hence that book too, and all of the work around Enterprise Canvas and the like.)

…about different players’ roles within the enterprise, and responsibilities to the enterprise that go with that role

(Hence the work on the complex tradeoffs between control and agility, and on the respective responsibilities of backbone versus edge.)

…about what’s needed to keep on-track to purpose.

(Hence frameworks such as ‘Vision, role, mission, goal‘, and themes such as governance and service-viability.)

…the need for tools, toolsets and methods that can support the whole of this scope.

(Hence revised-ADM, extended-Zachman, extended-VSM, Enterprise Canvas and yet more books, and many posts on tools and toolsets, methods, metamodels and the like.)

…and a focus on value and values as core to the whole enterprise.

(Hence many posts on values and related topics, and on kurtosis-risk (‘long-tail’ risk) and the like.)

All of which is, yes, a lot. Yet all of it does come back to effectiveness – and effectiveness for everyone, rather than solely for a self-chosen few.

So that’s it: start from the top, working downward each step of the way towards something practical, something we can use.

And that’s me, I guess; that’s ‘my’ enterprise, the enterprise to which I seem to belong. The enterprise I need to express in everything that I do.

Comments, anyone? Anything that I’ve missed?

Over to you, anyway.

(And thanks also for being here with me on this often-strange journey of mine… )