“ Vendor risk “, not always where you expect it…

In the many years I’ve spent working as a developer, architect, consultant, CIO or head of an IT business unit, I’ve been confronted with customer choices that have taken me more or less by surprise.

The latest illustrates a relatively common scenario in the choices faced by CIOs.

The context is as follows: one of my clients was to provide an electronic document consultation service as part of a more global service contract to one of its customers (a large French group).

During the pre-sales phase, it was initially planned to include, in SaaS form, a “off-the-shelf” software package developed by one of my customer’s divisions and already sold to several companies.

This software, which we’ll call “X”, is an ECM (Enterprise Content Management platoform), like dozens of others on the market.

It embeds hundreds of functionalities for filing, indexing, searching, business workflows, etc.

In the course of the project, it became clear that the end-customer’s needs were relatively simple, but very specific.

So, instead of an off-the-shelf software package, the question arose of developing a small custom software package.

Like all complete software packages on the market, the latter was designed to meet the needs of as many people as possible, without having been conceived for the needs of any particular company.

In general, a software vendor designs software to address a business problem common to several potential customers (so as to make a return on its investment by selling it to several companies, the cost of “duplicating” the software being marginal if not non-existent).

To broaden this base of potential customers, he must identify the common functions that the panel will need, then add a slew of additional functions that only some of the customers will need, but which will enable him to stand out from the competition (and utter the magic phrase: “Yes, our software meets all your needs, it’s only parameterization”).

The result is often (if not always) obese software, of which the end customer will only use 10% (at best) of the functionalities (it being understood that he will pay for 100% of the latter).

When a company has a simple but fairly specific need, as in my example, they have two options:

• Take a commercial software package, use 2% of its “standard” functionalities and pay for the “parameterization” (in fact, the development) of the specific functionalities it really needs (a history recovery, an integration with the I.S., etc.).
• Opt for a specific development that will meet 100% of your needs, and only those needs.

In the first case, the customer has the perception of having made a prudent choice, since it’s the same as many other companies.

In the 70s, it was said that “a CIO will never get fired for choosing IBM”, in the 90s it was said that “a CIO will never get fired for choosing Microsoft”, and you can repeat these maxims ad infinitum with all today’s fashionable products.

The problem is that companies who make this type of choice are in fact taking on major risks:

• Firstly, they run the proven risk of paying twice too much: firstly, because they’re paying for features they don’t need, and secondly, because they’re paying for the specific development of features they do need.
• Then there’s the risk of facing stability problems: the specific developments required are often inserted like a wart on the “standard” software, since they were not foreseen during the initial design phase. What’s more, “standard” software embeds many functions that the customer doesn’t need, but which are also sources of “bugs” that he inherits in spite of himself (it’s commonly accepted in software engineering that “bugs” are more or less uniformly distributed throughout a source code; the more lines the latter contains, the more “bugs” there will be).
• Finally, it runs the risk of rapidly experiencing performance problems. For the same reasons as the stability risk, the many unnecessary (but very present) functionalities and the genericity with which “standard” software has been designed to meet the needs of a greater number of users (in its processing algorithms, data model, etc.) are all unnecessarily consuming CPU cycles and memory (or disk) bytes. In the best-case scenario, the customer will have to deploy a disproportionate infrastructure to achieve the desired level of performance; in the worst-case scenario (unfortunately the majority), he will reach a logical plateau beyond which adding infrastructure will no longer improve performance.

In the second case, that of 100% custom development, the customer feels he is taking an enormous risk: he will be the only one to use the resulting software.

In the event of problems, they will have to accept their choice with their service provider, and will not be able to take refuge behind the choices of their colleagues and/or competitors.

What’s more, the longevity of your solution will depend solely on the health of your service provider (at least, that’s how it’s often perceived — I’ll come back to that later).

From a technical point of view, however, this is often the optimum solution:

• The software will be designed on the basis of the customer’s needs and nothing else (the service provider has no interest in implementing functionalities for which he is not paid).
• It will therefore be more concise, lighter, certainly more powerful and statistically (for the same quality of development) more robust (fewer lines of code, fewer bugs).

There are therefore two classes of risk in this type of situation:

• A “technical” risk, often poorly characterized (since the customer wrongly attributes it to the second scenario)
• A “tactical” risk, which often boils down to a question of continuity: what will become of me if my service provider, the only one to master the software, disappears?

As you can see, the technical risk is not necessarily greater with a customized solution — quite the contrary.

As far as tactical risk is concerned, customers often forget to ask themselves the right question in the case of a software package: what will become of me if the publisher (of which I am not the only customer) continues to develop its software (without my specific developments) and ends up stopping official support for my version (which is bound to happen)?

Quite often, the answer to this question is a painful one: you have to go back to the drawing board to “port” (in fact, redevelop) your specific to the new version of the “standard” software (which has, of course, evolved so much that it is no longer compatible with the initial specific).

Worse still, what happens if the publisher decides to stop the product altogether and start again from a different base (a case often observed)?

Or, finally, what happens if the publisher disappears? After all, nobody is immune from bankruptcy.

Of course, a Microsoft, IBM or SAP is less likely to go under than a mid-sized service provider.

But it’s rare to find a Microsoft off-the-shelf software solution for a specific business need.

So, is vendor risk really a problem for this type of business solution?
My answer is clear: no.

Let’s imagine two scenarios:

• Company A chooses an off-the-shelf software package from publisher B, plus a specific development to meet its simple, but specific, needs.
• Company C chooses a totally specific development by company D to meet the same type of need.

Companies B and D disappear (or the product published by B leaves the publisher’s catalog).

Company A, which is just one of B’s many customers, will find it very difficult to recover the skills or even the source code for its software package, so that it can be supported by a company E (or by itself). B’s software is undoubtedly protected by patents, and no software publisher will cede you the intellectual property of its software package, even in the event of a mishap.

It will also be very difficult to influence B’s strategy to convince it to keep its software package in the catalog simply because it continues to use it (on the other hand, you can count on B’s sales force to convince A to buy the new version of the software).

Company C, on the other hand, having paid for software that only meets its needs, can easily negotiate the intellectual property of the latter, or a session of this property in a reversibility clause.

What’s more, since the software is, as mentioned, smaller, it was certainly designed by a smaller team of developers.

In the event of D’s disappearance, and in the event that company C does not have the in-house skills to take over the source code for which it has negotiated ownership, it can always identify the key resource(s) (developers) at D who have mastered its software (it certainly already knows them, as it was with them that B refined its specifications and carried out testing and integration) and then recruit them.

The illusion of security that Company A bought (at a high price) therefore backfires.

• The result is a less effective solution,
• More expensive,
• Probably less robust for its needs,
• Probably less suited to its needs,
• Ultimately, less sustainable in the event of a supplier accident.

However, this analysis can only be applied to small, specific functional areas (as I introduced in my example). Don’t go and have an OS or ERP custom-developed to reduce your risk…

But in this type of special situation, which is nonetheless quite common in the corporate world, ask yourself twice: does choosing to meet a specific need like everyone else protect me from problems?

In the software world, mass production is not (yet?) a guarantee of superior quality to “craftsmanship”.

So, when you can, choose a good craftsman.

To return to my anecdote, the large French group chose the first solution, and this surprised me all the more as both were offered by the same supplier, both in SaaS mode, both at the same price, and both within the framework of a contract with an obligation of result.

The tactical risk was therefore a priori the same, but the customer was under the illusion that choosing a product already used by other companies (who didn’t have the same needs as he did) was less risky than using a solution custom-developed for him, even though the original product would have to be “twisted” and functionalities added to meet his needs.

Originally published at https://www.linkedin.com.