Some interesting things happening in the process of RFQs and software platform analysis prior to purchase. More and more we’ve been seeing people inquiring about infrastructure.
It’s not like they didn’t care before, certainly they did. But now, it’s about two different “levels” of infrastructure. The first is functionality. We’ll see a lot of questions about how things are set up, what functional expectations there are, how things work, failover systems, scaling, all of that.
These are key questions – so very important. So many people are asking though that don’t have any real idea of whether things are set up “right” or in a manner that support the claims. I’ve talked with vendors that outline all of the key bullets to their solutions, then start asking how they’re put into play, what their experience has been like if X, Y or Z happens. Many times, the vendor rep doesn’t know – but they made sure to check the boxes on the request for information forms.
I get really nervous when NO ONE at the org can tell me what their processes are really like, or what types of incursion attempts they’re seeing blocked, etc. Many people requesting this information don’t have any means of knowing how things need to be set up to be reasonably implemented either though. In talking with customers we’re helping through acquisition stages of platforms they are considering, it’s clear that they have a set of qualifier questions and concepts, but vetting those is another story.
Somehow we need to figure out how to help people discern between the “yup, yup, yup, we do that, honest!” and the honest, thoughtful implementations.
There is a new thing happening more and more though that’s pretty cool (from the perspective of this Microsoft-fan/MVP). Many times now when we’re going through qualifying and final steps of an acquisition process, brands matter.
There have actually been cases where all sorts of questions were sort of queue’d up about the data platform and when we went through the description of the platform in use (Microsoft SQL Server) there was an almost audible sense of relief. Not to get overly mushy, but I think it’s a sense of trust.
It’s accepted that SQL Server has the data security and protection pieces needed to get it right, and that it’s reliable and fast and all of those key fundamental things. Once that’s established, you can move on to the implementation details to see how
I’m not bringing this up as a commercial though (I realize it sounds like it). I mention all of this because a) we need to educate people about implementation items that they can be aware of. And b), if you’re deploying solutions, it may be shifting to matter HOW they’re deployed, WHAT tools you use and the combination of all of these in your applications. Choose wisely, because where it didn’t used to matter how you got it done, just that it got done… may be gone with the wider and broader interpretation of customer expectations, data protection and all of the things happening in that area.
IMHO, It’s worth a considered infrastructure discussion and planning phase in your next project.