Just Enough Detail
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?
Somewhat related, there was a film contest recently. The winner is getting a lot of press. The rules were: the story has to be told in less than 3 minutes and with only 6 lines of dialogue. The porcelain unicorn (http://youtu.be/dCAs_CyopMQ).
Remember to put only what is important to convey the business story!
How much is enough? This is a question that I have contemplated posting on LinkedIn EAN only in the last day or two! But I rediscovered this post that I tweeted (amongst my extensive portfolio of about 15 tweets!!)
My own experience is that three level process breakdown is sufficient for developing a business capability heatmap that will enable the creation of a sufficiently robust business change program / roadmap. I have no analytical proof. I do not even have enough historical data from completed business change programs. I only have the evidence that the funding was secured on each occasion.
That is the test – did we present sufficient information to enable a decision or enable a more confident or lower risk decision? How much greater return / improved decision will we derive by investing more effort and time into making the same decision?