As someone who designs data storage networking systems, I often get non-disclosure agreement (NDA) briefings from vendors and review public roadmaps, as I'm sure many of you do also. I often find myself dismayed at the difference between what and when vendors tell me is coming and the timetable and features of the actual product.
We all make disparaging comments about sales and marketing folks when these kinds of things happen, but more often than not, when a promise isn't kept it's not their fault; they are just the messenger. Vendors are not purposely making stuff up just to get your business; at least that kind of thing doesn't happen very often in my experience. What they are doing is providing the most hopeful information that they get from people in development on both the hardware and software side. Perhaps more caution is warranted on the part of vendors, but there are nonetheless things you can do to protect yourself.
The big issue for end users and purchasers is figuring out what the warning signs are that a vendor is not going to make a release schedule for software or hardware. I have noticed some common signs over the years for when a schedule is close to reality and when it's not even close. It's somewhat of an art, but there are some telltale signs you can learn to spot.
Of course, over the last couple of years, almost every vendor has had one or more product schedule that slipped because of the economic downturn; it's not fair to hold vendors to a pre-collapse schedule. For recessions such as 2008, 2000 or 1990, you should reset your expectations. But there are a few factors to consider the rest of the time (and some that might be good warning signs before a downturn hits). They include:
- Vendor financial health
- Past history
- Technology complexity
Vendor Financial Health
The issue of vendor financial health is an interesting one. Some might claim that if vendors are in good financial health, they should make their schedules, and the flip side is that if they are in poor health, they will not make their schedules. The reality is far more nuanced. Let's divide this into three areas:
- A vendor in poor financial health, which I define as losing money for four or more quarters in a row; one good quarter does not in my opinion get you out of this category.
- A vendor in fair financial health, which I define as breaking even for four quarters in a row. Again, a single good quarter does not, in my opinion, get you out of this category.
- A vendor in good financial health, which I define as having good profit margins and growth for four or more consecutive quarters. A single bad quarter is not enough to change this assessment.
If a vendor is in poor health, you would think that they would be less likely to meet timetables or be innovative, but this is far from the truth. A vendor in poor health can become successful, whether it was IBM (NYSE: IBM) in the 1990s or Apple (NASDAQ: AAPL) more recently, and a vendor in poor health can become successful and then go back to poor financial health again, as Sun did. Poor financial health is not necessarily a reason not to believe the vendor.
What does matter is whether the vendor has a well stated plan for what they are going to do and the markets they plan to focus on, as you cannot be everything to everyone. You need to make sure that their market focus is on the products you plan on using and that they are not developing something for another market. For example, if you are looking for enterprise storage and the company you're looking at is now focused on midrange/low-end storage in their public statements, you need to find a new vendor. Sometimes companies that are in trouble find their mojo and rise from the ashes, but more often they do not. Look at the number of big tech companies that were once at the top of their game and are no longer around: DEC, Compaq, Cray, SGI and Sun are just a few. A company has to have a purpose that serves the market and know what that purpose is -- and it has to meet your needs.
Companies that are breaking even and those that are doing well may have some of the same issues. Do they know their way, do they seem to understand the market and be innovative, do they know how to serve the market and still make a profit? The tech industry has no company that is "too big to fail," unlike the financial markets. Every company needs to have a way to make money; it's essential not only for the company's survival, but for you to be able to plan your IT infrastructure with some confidence. Giving away free software or free hardware does not tell you how they are going to make a profit and still serve the market. Everyone can download a free OS or buy $100 disk drives; a company serving the market has to have a way of selling something to make a profit.
Companies that are doing well might lose focus and forget the markets they need to serve. They may get obsessed with something that is not really their market, but feel they need to expand into another market that they might not understand. Sometime vendors do this via acquisition; other times they just set sail and the leader says "follow me." More often than not, moving into a new market unprepared can result in failure not only in the new market, but can also cause the vendor to divert resources, which hurts the existing market. I am sure we can all think of examples -- we've already listed a few -- and how those examples affected the products we were expecting. Keep your eyes open.
Past Roadmap Failure and Future Results
I know of one vendor's product that has not kept to the roadmap in more than five years, not once. Roadmaps come out and are often wrong at release. This is an extreme example, but past performance is a very good indication of future results, based on my experience. A history of past performance with no significant management changes isn't a sure thing, but it's a good bet. I am not saying who is wrong here; marketing could be setting unrealistic expectations for development, development managers could be doing the same thing, or the developers might not be thinking things through. Whatever the reason, it happens. If a vendor has not met development schedules for a long time, and for the most part everyone in the company is the same, then based on my experience, the likelihood that a development plan will be achieved a year or 18 months out is questionable. There have to be consequences for continued failure to meet a roadmap, and when there is not, it becomes SOP for everyone.
Technology Complexity and Testing
This is the hardest of the three to evaluate. The complexity of a hardware or software project is difficult to evaluate from afar unless you are very familiar with the technologies and the development process, so armchair quarterbacking on whether a project will complete on time is difficult.
What is not difficult to determine is how much innovation is involved in the project as opposed to natural product progression. If the vendor is developing a new RAID device that uses 8Gb Fibre Channel instead of 4Gb FC, and adding more bandwidth, performance and the like, that is usually a far easier product progression than, say, the development of a new storage architecture with hardware virtualization, support for iSCSI, FC and FCoE connections, a new RAID rebuild framework, and so on.
One of the first questions I always ask to get a feel if the vendor is up to the task is to ask about all of the new regression tests that must be developed. Who cares about the technology if it is not well tested? What I find is that vendors that have a realistic plan have already developed or are developing the new testing framework with new testers that know some of the issues in testing new technologies. A good percentage of projects that are late are late because of poor testing, poor test methodologies or, worst of all, lack of developed tests. I always laugh my hardest when a vendor says to me, "We did not develop the complete testing suite in time." Not the kind of thing I'd want to hear if I were a stock holder in the company. So for me, one of the most important questions if I do not understand the technology is what is the test plan and where are the tests? Complex technology can come out on time if the plan takes into account important details, and testing is a good benchmark for telling if those important details have been considered.
For the most part, my experience has been that vendors don't lie about product timelines, but that doesn't mean that they don't stretch the truth, as some folks only look at the potential short-term commission check instead of building a long-term relationship. Even if people are telling you what they believe to be true, that does not mean you shouldn't evaluate the situation yourself.
If things are bad enough -- say the company is in financial trouble and also not executing on its vision -- it may be time to find a new vendor, but that's an internal decision based on your own organization's criteria. Hopefully I've given you some warning signs that can help keep unpleasant surprises to a minimum.
Henry Newman, CTO of Instrumental Inc. and a regular Enterprise Storage Forum contributor, is an industry consultant with 28 years experience in high-performance computing and storage.
See more articles by Henry Newman.
Follow Enterprise Storage Forum on Twitter