I get e-mail. Like this one from one of our technical sales consultants:
Hi, dumb question but I have been asked it a couple of times and I wanted to see how you would answer it. Why would clients choose [insert some consulting engagement type here] versus just using [insert some Swiss Army Knife technology here]?
Let me translate the question, first (and while I believe there are dumb questions, this was not one of them):
Why would I take a look at my data and application requirements, first, before buying a technology solution that promises to solve the problem for me so I don’t have to?
Product is not the answer to this old chestnut but a tool to implement the answer. As with all tools it is at least helpful to know what you are going to do with it once you have brought it home from the store. Products are nice but anyone who says “there’s nothing for you to worry about” is really saying “worry, just not until after I get a signature”
Most of the time the client only has a vague idea about what tools or products they really need, usually to solve some very specific issue. The problem is those one or two drivers do not drive you to a good decision. I like to turn the question around and ask “what is it about this technology that makes you think it will solve all of your problems?”
The truthful answer is “well, not ALL, just these one or two problems…”. So why not use the right technology to its fullest and solve for more than just one pedestrian use case? The only approach then is to examine your customers’ requirements and see what shakes out. If you don’t do that kind of analysis, you run the risk of solving one problem while creating several more. Performance dragging? We have a product solution: Implement flash drives. No more performance problems! New problem; everyone wants flash drives and now my budget is toast.
Since the question was posed in the context of using automated storage tiering tools, I wondered aloud how these tools would determine what a “tier” of storage looks like? They don’t, you do. So how does the architect figure this out and then set parameters for the tools to do their jobs? Gotcha.
No application owner will start a conversation with “I’m happy to use the lowest cost solution” when there is no incentive to save money and every incentive to insure against some imagined worst case scenario (and they are creative in their imaginations, I must say). The underlying theme has to be one of trust, transparency and ability to deliver. Throwing a product in between the design requirements and actual solution (instead of a person) perpetuates the vicious “IT doesn’t understand us” cycle. We rob tools like these of their most powerful benefits when we sell them as a way to avoid actually understanding our customers’ requirements when designing the underlying architecture.
Build to the requirements, then see how you can use tools to enhance, optimize and automate the service. You need to perform the analysis. This is why you shouldn’t just buy some technology to solve what is normally and fundamentally a service management problem. Let the requirements dictate the functionality and you save money and time in the long haul. Use the tools to make your decisions work like the magic they are.
Pingback: Can you believe "ILM" is still an open question? | The Practical Polymath