Buying a suite vs. best of breed

One of the ego-boosting things about the software racket is when long-time customers, even ones to whom you haven’t sold anything in a while, still call and ask your opinion on something they’re considering. I have a handful of these, and I never hesitate to offer them my honest take on whatever it is they want. Trust and credibility mean everything in software, which is so much more nebulous than hardware, or automobiles, or toasters.

So I was recently asked by a long-time customer what I thought of his strategy of assembling a “best of breed” solution for their current needs, as opposed to purchasing a suite. What this means is, he needs solutions for password reset, single sign-on, access requests, workflow, endpoint connectors, auditing and reporting, compliance, and so on. Should he assemble the best stuff out there and string it all together on his own, or concentrate on only one or two vendors, looking for the best solution on average?

Quite often, disparate solutions integrate. Plenty of the vendors talk to each other’s packages, even when they compete. Oracle owns Peoplesoft and Siebel, for example, but every competitor has connectors for these common business apps. Everybody talks to Oracle database. Oracle talks to IBM and CA directories. CA has connectors for just about everything. And so on. There are also generic connectors, such as for relational databases and LDAP. Some of the bottom-feeder solutions in the identity market tell you, “You don’t need provisioning. Just take our roles or profile data and pop your requests directly into your business apps via SPML.” They do this because they’re too lazy or cheap to have connectors, but they conveniently forget the fact that the vast majority of commercial apps don’t (yet) support SPML.

If you think you’ve found the perfect combination of products, and have a sound plan for linking them, then life is good. Maybe. They might have connectors, but you’re responsible for the deployment. If there’s an issue, guess what? The vendors point at each other. And what happens when one or the other sends out a patch, an update, a dot release? How does this affect the integration? Even with a single vendor, customizations are often a problem during an upgrade. What if you need to migrate to the next version of your chosen operating system, and one vendor or the other is behind?

Hypothetically, if you need to cover identity, access, and compliance, and your strategic vendor does a great job with the first two but not the third, perhaps you plug in only that piece from another vendor who does a superior job in that arena. You might also segregate run-time from offline apps. Report writers, auditing tools, and role mining usually run in the off-hours, or at least CAN be. Those might be standalone.

However … a suite from a single vendor can also be a good thing, for obvious reasons:

• Their modules will already be integrated. If not, their building should be burned down.
• Upgrades to those various modules will invariably be correlated, if not by number then at least by functionality.
• Interfaces will (hopefully) be consistent.
• Consolidation under a limited number of vendors means consistency in quality and support. If it’s a single vendor, then you usually have what’s known in the industry as “one throat to choke.”
• There’s no finger-pointing when integration breaks. “They’re ALL your product, so fix it.”
• You can leverage the vendor’s salesguy for a better quantity discount on the consolidated price. In other words, it’s cheaper because it’s not ala carte. “I’ll buy all of it from you, sure. But what will you do for me?”
• Their report writer and auditing tool and SoD library and so on are already designed to know and take advantage of the schema and other aspects of the core tools, so you’re not having to custom-code the integration, create custom schema, or diddle with a bunch of XML files.

So you might consider following the lead of much of the market and consolidating your vendors, at least for the larger stuff. Sure, there are a lot of good, smaller vendors out there as well, with more of a limited menu, and they still have plenty to offer. But in the end, even if you’re running a charity, you’re not running it for software vendors. Do what makes the most sense, in terms of budget, implementation, and ease of support.

                                                      *****

I'm going to spoil my otherwise elegent conclusion with a quick digression on the term BoB. Sometimes vendors use “best of breed” to insinuate that their single product is simply “the best,” or that it’s been through the meat grinder of the market and emerged as a leader. But it’s terribly overused as a descriptor. I know of two startups that use the term “best of breed” to label their barely-known products, only one of which has even a single paying customer to date. In truth, BoB should be used to indicate the mind meld of multiple technologies in a way that produces the optimal business and technical value.