Best practices – adapt, then adopt

Just how applicable are ‘best practices’? How certain can we be that they’ll be ‘best’ for each seemingly-equivalent context?

I’ve been brewing on this for quite a while, when via serendipity up comes this retweet by software-architect Simon Brown:

• RT @simonbrown: RT @ntcoding: finally, people are starting to realise best practices and principles are no more than a suggestion http://simpleprogrammer.com/2012/12/15/the-more-i-know-the-less-i-know/

Just two words here: read it! From an architecture-perspective, it’s one of the best descriptions I’ve seen of the in-person experience of transitioning from simplistic certainty to the more realistic ‘I don’t know‘ and ‘It depends…‘ – the transition from applied rote-learning to true skill, the experiential transition from order to unorder (to use Cynthia Kurtz‘s terms), or starting to accept the inescapable reality of the right-hand ‘Not-known’ side of the SCAN frame:

Best-practices are, in essence, methods that have worked well in one specific context. But that’s the trap: its ‘bestness’ is context-dependent – which means that it may not be ‘best’ in another context. And if we focus only on the method, we have no way to work out whether it would or would not be ‘best’ for our own specific context.

To make practical sense of this, we need to draw clear distinctions between methods, mechanics and approaches:

— In unskilled work, it’s not so much ‘best practice’ as ‘right practice’: methods are more akin to ‘scientific law’ and suchlike. Context doesn’t count here: what the method does will always be the same, everywhere, and will always lead to the same results. Yet that’ll only work where everything does remain the same, or where the supposedly-scientific ‘law’ does apply – in other words, over on the ‘certainty’ side of the ‘Inverse-Einstein test‘, the left-side of the red boundary-line on the SCAN frame.

— By contrast, skilled-work must be able to tackle uncertainty – the whole space indicated by the SCAN frame. Which means that sometimes there’s certainty, and sometimes there isn’t; and context most definitely can make a difference. That’s why we’re forced here to think more in terms of ‘best-practice’ – a value-based view – rather than ‘right-practice’ – a ‘truth’-based view.

In effect, each method is a balance between the mechanics and the approaches of the work-context:

• the mechanics are ‘objective’, that which remains the same everywhere – the content, the applicable ‘scientific laws’ and suchlike
• the approaches are ‘subjective’, that which may be different anywhere or everywhere – the context, the personal, locally-distinctive, unique

Or, in visual form:

What works well in one place, one person, one organisation, may not work well with another – hence that comment in the tweet above that “best practices and principles are no more than a suggestion”. But what do we do with that ‘suggestion’? How can we know what to use, and what not to use, where, how, why?

In practice, we need to adapt each ‘best-practice’ to our context, before we adopt it in our context.

Yet there’s actually nothing in ‘best-practices’ themselves that can tell us anything about this: they’re just methods, someone-else’s merging-together of the mechanics and the approaches for their specific context. To apply them to our context, we must:

• separate out the context-independent mechanics from the original context-specific approaches
• identify, if possible, why these practices were ‘best’ in that specific context
• identify the approaches that apply in our specific context(s)
• re-combine the context-independent mechanics with the approaches for our context(s)
• adapt further as required for each scale or sub-context
• adopt as context-specific method for the respective context or sub-context
• re-assess and review each method on a periodic basis to adapt to changing skills and changing contexts

This applies to every purported ‘best-practice’. For example, it explicitly applies to TOGAF (The Open Group Architecture Framework), which in essence is a collection of best-practices for enterprise IT-architecture. As any competent TOGAF trainer would tell us, attempting to use TOGAF ‘by the book’ will rarely give good results: instead, it always needs to be customised to the local context – adapted, as above – before it can be adopted to work well in that context.

[And that, by the way, is one of the key reasons why proper training in TOGAF and the like is so important – and why, on its own, the standard certification-schemes for that and other purported ‘best-practices’ can sometimes be worse than meaningless…]

To do that separating-out of mechanics from approaches in the method, we need good analysis- and assessment-skills – and it’s often a lot harder than it looks.

To identify what applies in our context, what work-arounds will be needed in our context, and so on, we’re going to need a solid enterprise-architecture, or at least a solid understanding of the respective domain-architectures that apply in each context.

And to be blunt, I don’t think it’s possible to do this well without a proper enterprise-architecture – by which I do mean a literal ‘architecture of the enterprise’, not merely the architecture of the business or the architecture of the enterprise-IT.

Adapt.

Then adopt.

Use your enterprise-architecture to guide both.

Which is, of course, just another best-practice? 🙂