The 'Natural Platform' - Why people matter more than performance in picking hardware

One of the things that I get asked is 'what hardware should we run this on?'. I've said for years that I don't care about the tin and the tin is irrelevant from a differentiation perspective. Now before people leap up and say 'but X is 2x faster than Y' let me make a couple of points

1. Software tuning and performance will have miles more than a 2x impact
2. The software licenses will probably cost more than the hardware
3. The development will definitely cost more than the hardware
4. The software support and maintenance will definitely cost more

So what does that mean?  Well it means that when picking harder you should consider the people cost and the support costs much more than you could consider the performance.  What you should be considering is

 'what is the natural platform for this software?'

The natural platform is the one that the software is tested on.  That doesn't mean its the same as the hardware platform from the software vendor that they want you to buy, its the one that the developers are actually using to test that the software works.  Why do you do this?  Well when there is a bug, and lets face there are always bug, then instead of just having the support folks available to fix it you have all of the developers as well because they don't need to switch from their current environments.

Like I say this doesn't mean 'pick a hardware platform from the software vendor' it means pick the natural platform.  So if you think/know the developers are on Linux and deploying to Linux servers for test then you know there are more people able to help on Linux than anything else.  If they are developing on Windows and deploying to Linux then either of those platforms is natural.

As an example of what happens when you don't, let me take you back to 2000.  I was working on a project and we were using MQSeries, JMS and of course Java.  We developed it on Windows and deployed it to Linux for test.  For production however we'd been convinced to go for AIX to give us some major grunt.  We deployed the code into UAT and.... it broke.  Our assumption was that this was our fault because we didn't know AIX that well and clearly running IBM's AIX with IBM's Java Implementation, IBM's JMS implementation and IBM's MQSeries meant that it had all been tested, this was their flagship platform surely this was what it was meant to run on?

36 hours later we were talking directly to the product team who identified the problem as a memory issue that only occurs on AIX.  Making clear this meant that our configuration (pure IBM) had clearly not even been tested.

Working on another project where the database environment was different to that from the package provider and the hardware was a mainframe we had massive issues in just getting anyone who knew about our set-up in order to fix some problems.

These are normal problems and the key to them all is that its not about whether box X is faster than box Y they are about getting the best support and fixing problems quicker.  I'm not arguing that you shouldn't get an environment that scales, what I'm arguing is that when you look at the costs of tin then performance is a distant second to the people costs of fixing problems when they go wrong.

The problem is that normally the people buying tin are just buying tin.  In these days of virtualisation its about picking the right OS inside your virtualised server but its still important to think natural on platforms.

Pick the natural platform not the fastest shiny box.

Technorati Tags: SOA, Service Architecture

Improvised Explosive Consultants - neutralising a bad consultant

One of the challenges I often have is where a company employs a consultant to give 'independent' advice and the individual employed is a total snake-oil salesperson.  They've read a couple of books and websites and see their only job to lob in a 'bomb' in a meeting and sit back.  I categorise a bomb as a piece of input that is

• Completely and utterly wrong
• Contains a grain of truth that has been warped and distorted but can be made defensible 
• Said with conviction and patronisation as to how you can't see their point

So its the person who says 'Where are the WSDLs, this is an SOA project I expect to see WSDLs' and then follow up with an accusation that you don't have enough detail as you haven't done to WSDLs.  Or someone who in an MDM project asks 'why aren't you storing transactions in the Master, how are we expected to get them?' or questions to which answers are so obvious you don't bother putting them on the slide deck 'how on earth can you say you are doing a global implementation if you aren't using HTTP for the user interface'...'Err we are'.... 'Well you should have said, its a critical point'.  You know the sort of thing.  Dumb questions.  The reason they are dumb questions is that this person is meant to be an expert.  People who don't know can't ask dumb questions, they ask questions and you help them understand but when the person is put forwards as an expert then you have an issue.  I think of these people as Improvised Explosive Consultants as they are normally doing a specific thing, taking a small grain of knowledge and improvising it into a bomb to derail the project to show their value.

You see they are there to keep their fees up and to do that they need to demonstrate 'value'.  One of the easiest ways to do this is to undermine others and doing this in a technical area just means you have to seem smart to someone who doesn't understand the subject area.  One of the problems this causes is that you can't just call 'bullshit' on the bomb as often it sounds plausible to the layman while being rubbish and because doing so creates an antagonistic environment which is counter-productive and often leads to the IEC being seen as 'scoring a hit' with their insight.

This sort of consultancy often leads to bad decisions being made, the bomb is used to confuse and thus a confusing solution is then created.  The bomb maker, the IEC, is of course not going to be doing any of the actual delivery but can continue to stand at the side throwing bombs to demonstrate their 'value' and superiority.  So how do you defuse an IEC?

• Don't lose your temper - they are after this as it shows the bomb has been effective and makes you look uncertain, even though you've probably lost your temper because of the level of stupidity
• Get the specific objections down on paper - after the meeting where the bomb is thrown get the IEC to write a clear email listing their 3-5 points.
• Attack the facts not the person - don't debate the person keep on the facts.  Use terms like 'I'm a bit confused by number 3 because wouldn't that mean....' rather than '3 is just rubbish, don't you understand.
• When you finish knocking down the points send an email confirming that they accept that all of their 'challenges' have been addressed.
• Then send their reply of 'yes' (probably including some phrase like 'its important to check these things') to the whole group making clear that you've addressed all the points and the solution hasn't changed at all
• Repeat this every time. 
• When you get to the third bomb, add a statement to the reply that 'while you appreciate that IEC is just trying to get to the right solution, as we all are, I'm concerned that the team is being delayed addressing these concerns.  So far we've addressed 15 points and none have resulted in a modification to the solution.  Could I please ask that anyone who has specific challenges to the solution at this stage please email me (or add to the bug/CR/etc repository if you have one) before the meetings to speed up this process.

Hopefully during this process the IEC will quickly be identified with delay and your documented history of their comments producing nothing but additional work will result in them being defused.

If you are on the other side and think you might be employing an IEC there are a few key ways to check

1. Do they talk about their delivery successes or just their advising successes
2. Do they use patronising tones when people whose opinion you think is worth something explains stuff to them. 
3. Do you find that people with a history of successful delivery say they are 'confused' where these challenges are coming from.
4. Does the person talk about problems without out talking about simple clear solutions

If you've answered yes to 3 or more of the above then take a long hard look, you might have an IEC.

Technorati Tags: SOA, Service Architecture