I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference. One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.” Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.
I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed. I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time. But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”
Are the practices in the TOGAF framework truly “best” practices? Are these practices the best ones that the EA field has to offer?
I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”
After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve. (I nearly always agree with Jeff, BTW. We sometimes differ in language, but nearly never in approach). That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice. Who are we to say? We are practitioners. While that is good, it is not enough in my mind to qualify the practice as “best.”
To be a best practice, in my opinion, a method or approach has to meet a higher bar. There has to be evidence that it is, in fact, better than just a “good practice.”
I think a best practice should have:
- Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
- A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
- Some analysis to show that it meets other criteria like broad applicability and simplicity, and
- We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).
I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover? 2%? 10%?
Is 10% coverage enough to say that a framework is based on best practices?
8 thoughts on “Rumination on the concept of “best practice””
There are no best practices, only practices that fit best.
Oh wait, add "Developing practice"…to that list.
I am similarly doubtful of "best practices" in almost every field. As far as I can tell, very few "practices" in IT have been shown to be "best" by any sort of objective evidence.
I can only speak anecdotally on this – and therein lies the rub. Even the methodology used by the TOGAF committee(s), as you describe it, is really a sort of anecdote redaction.
Everywhere I look I still see ample evidence that 'practice' has far from solved the complexity and technical debt issues EA addresses.
We are doing better. But it's early days yet. There is much room for improvement in our current body of knowledge.
Hi Nick, my original comment didn't get posted, so what is currenty showing doesn't make a lot of sense! Did you get it? I thought it was quite good… Oli
What to do with best practices in an ever changing world? Adhering to best practices usually means repeating the past over and over again and hoping for the same (or even better) results.
Long comments often require that you submit the comment twice. Once you hit the "post" button, the software presents your own comment back to you in a smaller box and you have to hit "post" again. My apologies. If you want to send your comment to me personally, I can post it in your name.
We need to acknowledge that the semantic purpose of the phrase "best practice" is to shut off a discussion. This is not all bad. I have certainly been in plenty of EntArch discussions that went on far too long. It does mean that the very concept of "best practice" is dangerous. Best practice implies that the matter is settled.
I concur with Nick that the bar for establishing a best practice should be higher and definitely needs to include the context. And I would suggest that we replace the notion of "best practice" with "state of the art practice". It combines the positive connotations of "best" with the recognition that we should expect to improve on it.
The reason I think this matters is that deviating from a "best practice" is inevitably seen as "less than the best" while "state of the art" allows us to experiment and incrementally improve. Best practice tends to ossify while state of the art practice is a snapshot of a process in continuous improvement.