Credit: Colin Anderson
It's not terribly often that the planets align just right, and you see with extraordinary clarity how several seemingly disparate projects or initiatives can fit together into an elegant array. At such moments, your work can come together like Voltron.
But most times, when dealing with heavy-duty IT projects, the converse is true: All kinds of mayhem abound as several different teams try to reinvent their own wheel and bolt it onto the corporate IT chassis. When there is little central coordination or no technical core person or group that plays keeper in design meetings, a lot of time and energy is usually wasted, and the end result of all efforts is perhaps not quite as cohesive as it should have been.
[ Cash in on your IT stories! Send your IT tales to firstname.lastname@example.org. If we publish it, we'll keep you anonymous and send you a $50 American Express gift cheque. | Get the latest practical data center advice and info in Matt Prigge's Information Overload blog and InfoWorld's Data Center newsletter. ]
This is how you wind up with a massive SAN bought and built for a relatively small project that sits right next to a massive SAN constructed for a different project. Each is using maybe 15 percent of its overall capacity, in terms of both storage and load, and will never require more than that. Instead of consolidating those two endeavors and saving a pile of time and money, the units are destined to run essentially at idle until they're replaced, costing twice what they should have along the way. This, friends, is the result of poor internal communication. It's also how storage salesdroids own summer houses in the Hamptons.
It doesn't have to be all ravage and waste. A firm technical hand in the design and planning stages of these projects can identify these overlapping requirements and devise appropriate solutions that satisfy everyone's needs without major duplication of effort and expense.
The key here is that these people need to be invited to the right meetings, or alternately, any project that touches IT should be required to involve these people from the outset. Time and again, it seems that numerous manners of schemes are cooked up in nontechnical meetings, with outside vendors bending all the nontechnical ears that they can, promising "My Little Pony" outcomes while glossing over the steaming cesspool that forms their integration "strategy." I'd like to think that the era of technical contracts signed without IT involvement are behind us, but I don't think we're there yet.
All this makes it that much sweeter when things happen the right way, when initiatives dovetail into existing and planned infrastructure like cogs in a machine, when proper planning prevents piss-poor performance. That's the bull's-eye IT veterans aim for. It's a primary goal not just to curtail waste, but because it will require less time and headache to administer, and mainly, it's done properly. Too many elements of IT are simply not done properly, and when we have the opportunity to ensure that the job is done right, it's a cause for minor celebration.