There are two different kinds of need for information technology in the typical enterprise.
Unfortunately, most of us have implemented three kinds — and that is the source of more value destruction than any other thing we do in IT.
The first type is that which is common to any organization.
Accounting and auditing standards, for instance, make the way we keep financial records dead common. Regardless of the content, everyone uses position descriptions, keeps records of performance evaluations, administers pay and benefits, and the like. There’s nothing special about any organization’s corporate legal needs, or its means of handling procurements. A call centre is a call centre is a call centre. So too email, document handling and the other records functions.
For some enterprises — some secondary and all tertiary players in an industry, and a large number of public sector agencies and ministries — everything could be treated as common needs for standard practices. But most enterprises have something that differentiates them in the market.
Competitive needs often lead to some elements of differentiation. These require different IT solutions than the common needs require.
Let’s take an example. Retail banks all have systems for handling demand deposit accounts, time deposit accounts, investment accounts and loans of various types. Their elements represent common needs.
A few years ago, a bank created a new product: a loan account that offered better terms depending on the number and size of deposits held in the various account types offered. That was a differentiation.
This idea was seized upon by a financial institution across the Pacific almost immediately.
Avoiding the Differentiated Common
The originator of this idea implemented it as a separate system that merely used data from the common task systems it already owned. This small piece of custom code was easy to create as a bridge providing the unique function while leaving the common parts alone. They had avoided the middle zone between what’s differentiated and what’s common.
The cross-ocean copier, on the other hand, modified its existing loans system to handle its new product. This not only took eight times as long to come to market as the original bank’s efforts had, it created a liability in the portfolio: a differentiated common system.
This system loses the qualities of both types of solution. It is not cost efficient and easily replaced in the package market, as a common needs system should be. On the other hand, the differentiation (which costs more to own) is compromised by being fitted into an old framework. It requires more effort for every change (and differentiated solutions have much more rapid change cycles), thanks to the need to test all the elements of the combined system.
But We Didn’t Build New Products
Most enterprises, even when they’re not creating new systems for new products in this way, have nevertheless allowed differentiated common services to emerge.
When you modify a package (as opposed to simply setting a configuration option) rather than make a change in the way your organization works, you are differentiating a common service.
This burdens the enterprise with having to pay to retrofit these changes repeatedly, at every release update. Unsurprisingly, most new releases from the vendor of the product are bypassed. Maintenance of the old is extended for years — in many cases, requiring that other elements of the configuration are also held back. (It was understandable when enterprises chose to remain on Windows XP rather than go to Windows Vista; all those staying on Windows XP rather than go to Windows 7 — with 8 in the wings — are generally doing so because some other package can’t be upgraded, and won’t run on the newer client operating system.)
From a governance point of view, the business principle in play is that “everything is either a common need, or a differentiated need, but not ever something in the middle ground between the two”.
Every project should be tested for this before being released. If the business must change to deal with a common need as it can be provided, then the business must change — and the Governance Board should make that stick.
There is, by the way, nothing wrong with choosing to write your own applications (or retain previously-written ones) for common needs: the only question should be about the cost of the home-grown version versus alternatives to it. But that evaluation must follow the principle that the business changes, not what it would cost to modify the package to “fit” the home-grown world.
Enterprises that apply this principle, and clean up their portfolios to match it, find that they are far faster to provide differentiation in the future — thereby creating more value.
Watch the market for differentiation gone common
Finally, a word about the life-span of differentiations.
As differentiations are copied by others, there eventually becomes enough of an implementation consensus that the solution becomes progressively more common. Package vendors will then implement a “standardised version” within their package offerings.
At that point, the enterprise needs to start to apply the cost test, to judge whether switching makes sense. Whatever the outcome of that, the differentiated solution has become a common needs solution, whether it remains as home-grown code or shifts to a package at that point.