Thursday, December 13, 2012

Architectural Homeopathy

Sometimes when you are in a meeting someone says something brilliant, I had that experience today when someone said 'We have a sick body, can we please stop pretending everyone is a surgeon'.  Her point was simple, historically in the company they have had challenges of people having opinions and critically of decisions being made without data and whose implementation success isn't tracked.

I talked about 'Thinking is dead' previously and this is a clear manifestation of that and in the world of IT I'd like to give it a name... Architectural Homeopathy in other words people making IT decisions which

  1. Are based purely on an individual opinion on what will succeed
  2. Are not backed by a case as to why it will succeed
  3. Whose implementation success is not measured (beyond 'it went live')
This approach also has another aspect which is related to comments and challenges to recommended practices.  A good architectural challenge is to say that 'X won't work because we don't work in a centralised way, we need to do Y because we are federated and Y has already been proven to work here', the Architectural Homeopathy challenge is 'X won't work, we should do Y'  or more likely just 'X won't work'.  No evidence will be proposed to support this 'feedback' and no constructive change can be based around it, but if any issues occur the Architectural Homeopaths will say 'You should have done as I said'.

Architectural Homeopaths often build whole careers out of this, building approaches based on 'it worked for me' and failing to see the broader elements that drove success or criticising a proven approach based on a perceived technical flaw while missing the real problem (I'd argue that REST for enterprise integration is a great example of that).  These are the folks who propose great views of architecture without actually having delivered it themselves into operation and coached others how to use that approach.

The point here is that Architectural decisions need to be defensible based on data, even if it turns out to be wrong that gives you the ability to learn.  Proven approaches with justifiable approaches that are measurable against a set of criteria are what professionals should strive to do.  'Advisors' who promote approaches and cannot demonstrate their success and more importantly how others have adopted their approach and delivered success should be treated the way a Homeopath is treated by the medical profession.

I have no objection to the phrase that coding is an art not a science, that it is a creative endeavour not simply mechanistic.  That is fine, but unlike art its success is quantifiable, it either works as intended or it does not.  What I object to is people promoting architectural approaches (or indeed business approaches) which are based on a series of powerpoints and opinions with all of the real support evidence of Homeopathy.  These Homeopaths throw in comments based on this ignorance and personal 'belief' and disrupt progress and love to claim that 'it would have been better my way' while not explaining in detail what their way really would have entailed.

Architectural Homeopathy... get into the sack...


Dave said...

I like your article and the sentiment. However, I find it far more likely to come across Cognitive Bias.

Rather than "X won't work, use Y", I often get, "X won't work, I want to use Y and here are some statistics I've collected to justify it."

For example, I've got experience with both REST and SOAP; and worked in the enterprise and internet.

In my experience, most of the SOAP based SOA enterprise architectures that I have seen, are too complicated and require hundreds of engineers to implement.

Then I've also seen internet companies implement simple and efficient REST scalable services used my millions of users.

(this maybe just be an example of Conway's Law)

That being said, I know when both tools are appropriate and that both can work if used properly. I have no axe to grind against either.

Anonymous said...

I adore this metaphor, and look forward to the next installment, "Architectural Fundamentalists".