What Do You Really Need?
When you go to buy a house, everyone would love to look into the ten million dollar mansion on the hill, but when making such a significant investment as a house, we control our desire to see outrageous, and look at what ever it is that we, given our income and outgo, can afford to pay for – be it pay for in cash or pay for every month for the next thirty years. The process to determine what type of house we want is pretty simple. So simple in fact that some of it happens subconsciously. “How many bedrooms are required for our family” is generally the first question, modified by “is the family growing, so should we buy extra bedrooms?” Just about as important is “How much can we afford?” which is rarely clear at the first pass because payments and interest rates both fluctuate, and you have to factor in what your salary will likely be over the next thirty years. Followed by “What subdivisions or school districts do we want to be in?” and only after all of these are at least started on do you start to look at what’s available.
Would that we did the same thing in IT. We often go into a purchase with the immediate project at our fingertips and worried about it to the exclusion of all else, which is akin to looking at a house you intend to buy on credit without considering what your likely income will be over the life of the loan. Or better, buying a one-bedroom because you don’t have kids, even though the lady of the household is currently pregnant.
A good salesperson will help you see that you’re buying for far more than your current project, be it a software solution like a DBMS or infrastructure solution like an ADC, but then you’re at the disadvantage of not knowing for certain whether you will get the full value for it across the organization. Better to start with “we might need X, what other projects, systems, or groups could take advantage of X if it was available?” and get them in on the selection process so as to best serve the organization. Or if you’re lucky enough to be able to purchase X on your current project’s budget alone, at least get those other areas involved so they know what features/functionality might be available to them.
That’s generally the case with an ADC. Most IT departments go looking for an ADC to solve a specific and current problem, but the applicability of the solution has much more far-reaching implications than the original project. Getting others involved early may turn up additional uses for the solution and help to refine requirements before you jump into the review process.
When you consider the huge amount of functionality that a modern ADC brings to your organization, going over what you think is essential to success of your project and exploring ways it could help both your project and your organization before calling in the sales teams is probably a good idea. Assuming you’re like most (but certainly not all) customers, your initial need is for load balancing. Do you need WAN Optimization? How about Web App Acceleration? Web App Security? How about Remote Access and security solutions like SSL Offloading? The list is large, and if you’re considering the investment in an ADC to begin with, it is worth finding out how thoroughly it can be employed across the organization, and what the actual benefits to the organization might be. It is, after all, infrastructure, and limiting your view to a single project might be as bad a mistake as buying that one-bedroom home.
But I’m just taking the example that’s closest to my current work area. This applies to a very many IT purchases, and can help drive efficiency through the organization if you’re in an IT shop that isn’t already sharing potential solutions regularly – and most of you are. The choice of middleware for a given project certainly might impact other projects and even upgrades to in-place services, if the information is readily available to all. There are a variety of ways to share this type of information, via Wiki, regular meetings of PMs or Architects, email lists… What really matters is that you’re all talking, so the plan is less project-specific and more organizationally enabling. Because one solution serving multiple projects can pay for a whole lot of manhours communicating, several is taking money off the bottom IT line, something that’s even more important today than it has been for a while.