When people attempt to build complex software solutions using a mix of vendors, I call it vendor soup.
A recent example is healthcare.gov. That particular vendor soup was rich with delays, chunky with cost overruns, seasoned with vague requirements, and thickened with a lack of leadership and accountability. The GAO report on the problems with healthcare.gov is a great case study. The soup got made, but was it tasty?
The problem with vendor soup isn’t necessarily the vendors themselves. There are plenty of technology solutions and services that typically don’t make sense to implement from scratch: large-scale cloud computing infrastructures, billing systems, content delivery networks, source code management systems, software development tools, databases, and content management systems are just some examples. Vendors also provide expertise needed on an infrequent basis that may be inefficient to build in-house. I’ve used vendors in the past to help implement hardware prototype designs.
Even companies like Apple, Google, Amazon, and Microsoft use technology vendors because it makes economic and strategic sense; they don’t re-invent the wheel, don’t spend more than they have to, and focus on the things that are core to their businesses. But these companies still have armies of highly skilled software engineers and technical leadership to architect and direct the use of external technology vendors.
Quality software is hard to make. It requires a robust and well-defined architecture, a clear product vision and leadership, well documented code and APIs, consistently high engineering quality, common coding conventions and design principles, friction free communication between functional groups, an efficient and repeatable process for continuous product improvement, and relentless focus on the consumer experience.
Was even a single one of these attributes present with healthcare.gov?
No matter how competent the vendors may be, you can’t create an accountable, coherent, and high-functioning software development organization with vendor soup. Vendor soup is a tempting shortcut that looks great on a PowerPoint presentation to management. But who’s in charge when the countless things that can go wrong so easily in the software world…unstable apps, web sites that crash, user accounts that disappear, confusing user interfaces, links to nowhere, transactions that never go through…do go wrong?
If you’ve managed to cobble together a consumer-facing product relying primarily on vendors, you may be asking yourself: Did I make vendor soup? Obviously, the first hint will be that you have a lot of vendors doing things for you. But that alone does not make vendor soup. You need to ask yourself a few more questions. Does my product scale for future growth? Can I deploy new features and functionality quickly and easily? Are my costs under control? Do I have an efficient, well-defined architecture? Am I generating and protecting relevant intellectual property? Is my product constantly improving? Is the code elegant, robust, maintainable, well documented, well tested, and consistent? Do I have clear accountability? Is my product uniquely differentiated and superior to competitive solutions?
Now, be honest. If you find yourself saying “no” to more than a few of those questions, you have vendor soup. Don’t panic, it’s not the end of the world – you’ve gotten this far and nothing terrible has happened. They’ve fixed healthcare.gov (with help from former Microsoft colleague, Kurt DelBene). And there’s the possibility that for what you need, vendor soup may actually be OK. But at the very least, if you can recognize what you have, you won’t be surprised when vendor soup fails to meet your needs in the future. And if your long-term goals exceed vendor soup limitations, you can start planning a different approach.
Otto Berkes' weblog 