Saturday, August 19, 2006
Enterprise Architecture: There is no such thing as best practices...
In The Periodic Table, Primo Levi tells a story that happened when he was working in a varnish factory. He was a chemist, and he was fascinated by the fact that the varnish recipe included a raw onion. What could it be for? No one knew; it was just part of the recipe. So he investigated, and eventually discovered that they had started throwing the onion in years ago to test the temperature of the varnish: if it was hot enough, the onion would fry.
It is funny how enterprise architecture disciplines seem to only focus in on new stuff where the better focus may be on finding places where we throw onions into vats. Some great places to look are within many of the time-honored governance processes that seem to be more and more pervasively implemented within modern enterprises. The notion of best practices seems to be uttered out of many IT executives without regard for whether they still make sense.
For example, the notion of representation and buy-in is all important. There are many articles stating that IT breaks down do to the lack of communication and therefore suggests that EAs should communicate even more. Nothing could be further from the truth. How come no one ever suggests creating an organization structure where the average person would only have to communicate to two groups instead of sixteen?
At least we are moving somewhat away from the control the message culture of the 90s but have also went overboard with this. Sometimes we have to send out documents before their time. Sometimes, documents get circulated before even spell checking has occured? Some folks feel good that they are sharing and in all honesty many of the folks we send documents to won't read them anyway.
So what is the benefit? We managed to kill our internal email systems and consume more storage (NOTE: Buy stock in EMC) than what makes sense. By circulating documents before their time, we make those who actually read things become distracted and turn their focus to errors on the page instead of getting them to focus on issues that actually matter.
A best practice is a rule in disguise. What happens if a rule was put in place to solve a specific problem? What if that problem still exists, and following the rule still solves the problem? When you point out the expense of following the rule, people can get scared, fearing that they won't be able to solve the original problem without adhering to the old rule.
Maybe we should eliminate all so-called best practices and then attempt to implement our proposed solution. When the old problem comes back then we can then return to the best practices and create a new document to explain why this practice was in place originally instead of just following it blindly. I wonder if our corporate thinking on reference architectures is one of these best practices?
Anyway, we should start a campaign to ban the phrase best practices and smack any industry analyst or IT executive with a wet noodle everytime they use it. Instead, we should change our vocabulary to say practical considerations...
| | View blog reactionsIt is funny how enterprise architecture disciplines seem to only focus in on new stuff where the better focus may be on finding places where we throw onions into vats. Some great places to look are within many of the time-honored governance processes that seem to be more and more pervasively implemented within modern enterprises. The notion of best practices seems to be uttered out of many IT executives without regard for whether they still make sense.
For example, the notion of representation and buy-in is all important. There are many articles stating that IT breaks down do to the lack of communication and therefore suggests that EAs should communicate even more. Nothing could be further from the truth. How come no one ever suggests creating an organization structure where the average person would only have to communicate to two groups instead of sixteen?
At least we are moving somewhat away from the control the message culture of the 90s but have also went overboard with this. Sometimes we have to send out documents before their time. Sometimes, documents get circulated before even spell checking has occured? Some folks feel good that they are sharing and in all honesty many of the folks we send documents to won't read them anyway.
So what is the benefit? We managed to kill our internal email systems and consume more storage (NOTE: Buy stock in EMC) than what makes sense. By circulating documents before their time, we make those who actually read things become distracted and turn their focus to errors on the page instead of getting them to focus on issues that actually matter.
A best practice is a rule in disguise. What happens if a rule was put in place to solve a specific problem? What if that problem still exists, and following the rule still solves the problem? When you point out the expense of following the rule, people can get scared, fearing that they won't be able to solve the original problem without adhering to the old rule.
Maybe we should eliminate all so-called best practices and then attempt to implement our proposed solution. When the old problem comes back then we can then return to the best practices and create a new document to explain why this practice was in place originally instead of just following it blindly. I wonder if our corporate thinking on reference architectures is one of these best practices?
Anyway, we should start a campaign to ban the phrase best practices and smack any industry analyst or IT executive with a wet noodle everytime they use it. Instead, we should change our vocabulary to say practical considerations...
