The Best of Breed vs Suites Debate

Desirae Odjick writing on the ConceptShare blog has made a comparison of Best of Breed and what she terms ‘All In One’ software. The former is an implementation strategy where multiple applications developed by different vendors are combined. The latter is an aggregated package, usually delivered through interdependent components and offered by a single provider.

I normally refer to ‘All in One’ software as ‘Suites’ but I am not sure if there actually is a canonical term, so Desirae’s description may be equally valid. Her blog post has a good overview of the benefits of both options (irrespective of what you prefer to call either of them):

“In enterprise software, a debate has been going on for years: is best of breed the best software option, or will all-in-one software dominate the market? People tend to come down on one side of the debate, and it’s a question enterprise teams have to navigate while making important choices for their business and team. As tempting as it is to issue a blanket statement declaring one option better than the other, there’s a reason the debate has endured; there are factors in favour of both alternatives.” [Read More]

I have to note that ConceptShare’s essential purpose is as a Best of Breed ancillary vendor who generate market traction by having their product interoperate with lots of different DAM systems. As much as I would like to find some ways to pick holes in Desirae’s article and detect vendor bias, on this occasion, I cannot. It is a well written and balanced piece that gives a fair hearing to both sides.

There is a current tendency towards the proliferation of suites in DAM and the subject is overdue for a proper critique, which is what I propose to do with the rest of this article.

What Is Wrong With Suites?
We have talked about why the DAM industry needs to progress towards a Best of Breed model numerous times before on DAM News. But what, exactly, is wrong with software suites? Here are a few of the points that providers of suites often tend to use as arguments in their favour:

• Reduce procurement complexity and cost by single sourcing from one vendor
• Benefit from integrated products that are all designed to work together
• Take advantage of a consistent User Interface
• Gain access to an extensive professional services and support operations

I will deal with each of these below.

Simplified Procurement – Or Embedded Inflexibility?
Taking the first area, it is true that by buying a suite, you only have to issue one RFP and make a single decision about who to go with. But how much of a benefit is that? Relative to the inflexibility embedded into the decision to go with a single product for everything, the single source argument appears less compelling. There is a trade-off between the time saved in the procurement processes (which will usually take a few months) and having to deal with a bloated product that only partially addresses your needs for many years afterwards – perhaps long after the people who made the original purchase decision have since left the business.

Having both written and responded to a number of DAM RFPs in the past, I get the sense that what end users really want to be able to do with DAM is mix and match facilities from multiple products. Given the choice, they would select Best of Breed but since that is so difficult to achieve, they end up having to contemplate suites. They are usually under some duress to buy something and get started with implementation in short order by their colleagues. So they produce lengthy feature lists with every conceivable item imaginable because someone, somewhere in the organisation once mentioned it and it is politically easier to sub-contract the task of saying ‘no’ to the vendors rather than tackling the burgeoning scope problem in-house. Suites appeal to this instinct because they tick lots of procurement boxes simultaneously and appear neat and tidy to the buyers – until they start to use them.

The DAM market is in desperate need of a pool of experienced and vendor neutral professional service providers who can alleviate some of the complexity of using Best of Breed products from prospective DAM users so the process is simpler for them to manage than it is now.

An open and transparent approach where the client is assisted to clarify and prioritise requirements, sift through options and then select a collection of components that precisely meet their needs (without the advice being tied into any given product) is not as widely available as it needs to be for Best of Breed to work as well as it could.

Integrated Products Or Two Different Applications With The Same Logo?
Taking the next points: products that work together and consistent User Interfaces. The reality in most tech companies that are large enough to need to be sub-divided along functional lines is that you no longer have just one company, but a collection of fiefdoms or clans, each of whom are suspicious of (and competitive with) each other. While the vendor branding and marketing might want you to believe that their product is a single entity with each component in synchronised, smooth and graceful harmony with all the others, that is rarely the case in my experience. Under the surface, there is frequently bickering and in-fighting about who gets budgets, which operation has responsibility for some incompatibility or conflict that has emerged and a ‘management by committee’ approach to product design. That has implications for the extent to which suites are properly integrated and the facts are that this is not always as perfect as the vendor’s marketing might want you to believe. In some cases, this is more like having two independent and disagreeable vendors who have been reluctantly tasked with integrating their products with each other. Clearly, that does not apply in all circumstances, but the essential point to understand how well each component of the suite genuinely is integrated with its counterparts. This has to be properly tested and assessed, it is not sufficient to just assume they will be, or take any claims of integration on trust without seeing them demonstrated first.

In larger software businesses (and a few smaller vertical market aggregators too), some of the DAM components of their suites were not developed by the vendor themselves. DAM was not believed to be a market worth bothering with until the last 3-4 years by some. The recent surge in customer demand has since obliged them to acquire a belated interest. As a result, they may have made no serious in-house investment into DAM product development that they can now build upon. Some may have reached the conclusion that it would be easier to buy a DAM from some third party rather than build it themselves. Not all those who have a DAM component will used this tactic, but the benefits of bypassing a whole array of implementation challenges through sub-licensing someone else’s application (or buying a specialist DAM vendor outright) must be quite tempting, even if the trade-off is imperfect integration in the medium term. If you are a user of one of these semi-detached DAM systems, you are subsidising this integration work in progress.

Professional Services and Support – But Can Anyone Remember Who You Are?
The last area to examine is the scale of support operations the larger suite vendors claim to offer.  An observation I have made in the past is that small suppliers usually care more about individual customers because they absolutely have no other choice. In a large software business, customers are grist to the mill, while they cannot afford to shave several percent off their customer volumes and continue to get away with it over an extended period, the priority is on keeping most of the people happy, most of the time. In small operations, every customer is both hard-won and integral to maintaining positive cashflow (albeit some more than others).

These differing pressures percolate through to the way support and professional services are handled in both cases. When I have dealt with professional services teams from larger vendors, I often find that many are freelance contractors and are not directly employed by the vendor. This creates several complications since there is no continuity of supply and it becomes necessary to explain the background to a given issue on numerous separate occasions to new people because those you were dealing with have gone off to work on another assignment for someone else or a project the vendor considers more deserving.

Similar issues present themselves with support. Some of the staff know a given component better than others, whether you get the right one answering your ticket can be a case of pot-luck. Getting hold of the expert who holds the knowledge to the component you are having problems with can be as difficult (or worse) than a smaller operation where the staff are merely over-worked rather than entirely absent. I do not think the arguments about the scale of a business operation and their perceived benefits in terms of support resources bear up to closer analysis – quite the opposite in fact.

Conclusion
Software suites may be more effective in other subject domains like Finance or HR and represent a good way for end users to save costs. I do not know enough about those fields to be able to comment with any authority. With DAM, however, so many of the deliverables involved in a typical implementation are consultancy oriented. As a client, you need people who are willing (and able) to spend time first understanding your problem and then how to apply their skills and knowledge to it. For that reason, I am unable to recommend suites as good options for DAM as they over-simplify the nature of the task. If there are benefits available (including cost) they quickly get cancelled out by the suite vendor’s lack of focus and inability to properly get to grips with your unique requirements as they apply to Digital Asset Management.

Share this Article: