‘Best Practice’ | Enough with the nonsense


I’m not sure about you, but I hear these types of things a lot in my work with clients and vendors..

“Vendor design must follow best practice”

or..

“Is this solution best practice?”

And it drive me nuts. Because if we were being really brutally honest, the answer is usually no. Best practice is not a boolean value. Its a moving target based on a combination of the things that are important to the business. Cost. Process. Performance. Manageability. Skillsets. I could go on. I tend to summarise them as ‘the real world’.

For the sake of argument (and there should be plenty of it), let’s define best practise as the set of configuration, management, and operational ‘rules’ that the vendor suggests should always be followed for a given piece of technology. With me so far?

More often than not, any given solution or platform has dependencies on dozens of other products, applications, systems and business processes. Every single one of these has its own set of ‘best practice’ parameters. In many cases, they will share similar or identical parameters, but in potentially just as many cases, they wont.

And they’ll conflict with the real world that they live in.

Lets take a real basic SharePoint example…

SharePoint runs on top of IIS.

IIS best practice is to have a separate application pool and identity for every web application on the server to ensure dedicated memory space for each application and keep a layer of isolation between sites. Simple stuff.

SharePoint 2010 involves a number of service applications that support a given web application (the website you actually set the thing up to host in the first place)

Even in a reasonably small deployment, there may well be dozens of these, each of which is its own web application, and each has an application pool.

If you were to put each of these in its own pool, you’d need a massive amount of memory for even the most simple webserver hosting a single published website.

While this isn’t impossible – you can put tonnes of memory in servers these days – in the real world its just not realistic.

So you end up grouping similar applications into common pools in a sensible manner.

So is it best practice? No. But is it what the client actually wants, can afford, and will therefore sign-off? Yes.

Now in this particular example, the core issue is the cost of memory – which while not super expensive, does start adding up when you have multiple webservers, and look to replicate this in test, dev, and DR environments. Tomorrow memory will be cheaper. It will be even cheaper the day after tomorrow. So the precise point at which you hit the ‘too much’ point will change over time, and your proximity to the mythical ‘best practice’ point will change too. The actual best practice hasn’t changed – just how acheivable it is relative to your budget.

What I would really love to start hearing from people is things like this..

“Vendor design must incorporate best practices where they align with business drivers”

or..

“How aligned are our business goals with best practice requirements?”

The point I’m trying to make is that while its great to use the general concept of best practice as a goal, it doesn’t work to simply expect everything to comply at all levels. Simply saying ‘it should follow best practice’ isn’t a silver bullet – and chances are you can’t afford best practice. Instead, know that its something you can aim for, but don’t get uppity if you can’t justify the expense or effort of achieving it.


JB / The Daywalker

Ginger IT dude hanging out down in New Zealand, playing with technology since ages ago.

Currently Service Delivery Manager at Silicon Systems, formerly Skype for Business MVP, and generally into all things Microsoft (and a few things that aren’t).

When I’m not nerding out on technology, you can find me running ultramarathons, brewing beer, or in my woodshop building something.


On The Socials

Visit Us On LinkedinVisit Us On TwitterVisit Us On Facebook