Four Fundamental Best Practices for Enterprise IT

Although many people are cynical about the whole idea of best practices, I’m a believer. I think that such beasts do exist, just that too many companies, analysts and especially consultants spend too much time applying the label to whatever works in their best interest at the time. To counteract this cesspool of non-best practices, I thought it best to put down a few ideas of my own. Following are four fundamental best practices I have distilled from almost 20 years in enterprise IT. I wonder if you agree with them.

Before proceeding, I suggest that you take a look at the three principle tests that I use to define a best practice.

Best practice 1: Minimize Complexity

IT has a tough position in business. We are ignored while everything is working well, and in trouble when things start falling apart. We are held accountable, but generally cannot control our own destiny. The only way we have a fighting chance is  to minimize the complexity of the solutions we must support.

As I said in Sailing the Titanic (Why We Need ILM and Then Some!): “To make a timely (and tired) Harry Potter analogy, IT are the  house-elves of the business — powerful but subservient, with little input into what happens above and around them.”

This is where the current trends of virtualization, consolidation, and standardization comes in. A single administrator can manage a far-larger environment if it’s standardized, and these systems tend to be far more reliable as well. Sadly, minimizing complexity is the antithesis of a true hacker’s heart. Who wouldn’t want to play with the latest and greatest toys? Why not build an intricate and interconnected system? But these solutions fail my “best practices” test: They’re risky, unusual and just plain imprudent.

Best Practice 2: Use the Right Tool For the Job

Any woodworker or mechanic will tell you that using the right tool makes any job easier. Even if it works, it’s just bad practice to masquerade network-attached storage (NAS) as a block device or a storage area network (SAN) as a collection of shared files. I am always skeptical of so many oddball innovations trumpeted by vendors large and small because they seem to fail the “right tool” practice.

I wrote more about this in Use Process Solutions For Process Problems, Technical Solutions For Technical Ones and Why Do I Ignore NAS?

But sometimes they work out just fine.  You see, best practices can’t predict the future or what works in a certain situation. It’s better to minimize complexity and stick to what you know than to press for the perfect solution every time. It wouldn’t be right to bring SAN storage into an all-NAS environment  just for a single database application, for example. Although we generally shouldn’t try to drive a nail with a screwdriver, it can be the best option when a hammer can’t be found!

Best Practice 3: Prepare For Failure

The hacker in me is tempted to stop tinkering as soon as a system is functional, but the realist in me knows that I have to make it twice as good. You can’t prepare for every eventuality, but you can seek out probable points of failure and harden them.

For example, see Chris Evans’ discussion of  Choosing Between Monolithic and Modular Architectures

Many of the fundamental best practices in enterprise IT come down to this. Redundancy from RAID and N+1 components, the widespread use of multi-path technology, and high-availability design are all examples of preparing for the worst. We would not bother with all of this if we didn’t know that errors occur even in well-engineered systems, and that everything we build is sensitive to failure.

Best Practice 4: Align Expectations with Reality

We all face conflicting demands, and we are tempted to offer best-case responses to keep everyone happy. But excessive optimism leaves IT folks stressed and end users frustrated when things don’t go right.  It’s time to adjust expectations.

See The Techie/Business Schism, where I talk about the looming disconnect even within IT

Concepts like service level agreements (SLAs) and business impact analyses come from an innate knowledge that the real world doesn’t always conform to the best-case assumption. Although we don’t have real control over user demands, we can try to set correct expectations by admitting what we can and can’t do realistically.  Don’t let those who rely on us labor under misconceptions of our capabilities.

Stephen’s Stance

We can’t let others lead us astray with talk of “best practices”, but we can define some of our own. My three-part best practices test, and these four general practices, have served me well over the years. What are your best practices? Image credits: Dave’s Bike Tools by bre pettis