The market for enterprise applications has grown in leaps and bounds since the days when Wal-Mart deployed that data warehouse, and the applications themselves have become heavily commoditized. Vendors often offer a complete suite of solutions across a range of industries, and want to sell their application to as many customers as possible, competing aggressively in delivering new features and functions to attract these customers. Any advantage one application has over another is quickly eroded, while the high volume of vendor deployments have driven down the cost of installing and running these applications.

Wal-Mart now finds itself in the interesting position that the data warehouse it invested so heavily in can be bought today for 10% of the original cost, with operational costs and maintenance dropping by a similar amount. A number of early adopters—like Wal-Mart—are finding that these bespoke applications have become an albatross; providing a similar level of functionality to the best of breed solutions from vendors, but at a much higher cost.

So where can we find differentiation? I don’t see much point in ripping out large swaths of our current IT estate, replacing it with solutions from another vendor, as this will provide only a marginal improvement at best. Even if we’re migrating to a de facto standard in the industry—selecting the vendor that our industry seems to have consolidated around over the last decade—we’re likely to only see a marginal improvement at best. (And most of this improvement will be in the ability to easily source employees who are trained in the application, and who also have a sound knowledge of our industry.)

If applications are so cheap and plentiful that we can expect our competitors to have a similar capability to ourselves, then differentiation has moved from the application and into the gaps between them. The exceptions in a business process, the disruptions and how we manage them, will now determine how competitive we are. If we can deal with stock-outs more efficiently then we can keep less stock on hand and operate a leaner supply chain. Improving how we determine financial adequacy allows us to hold lower capital reserves, freeing up cash that we can put to other more productive uses. Extending our value-chain beyond the confines of our organisation to include partners, suppliers and channels, allows us to optimize end-to-end processes. Providing joined-up support for our mortgage product model allows us to put the model directly in the hands of our clients, letting them configure their own, personal, home loan.

Marco Iansiti brought this into sharp relief through his work at Harvard Business Review when he measured the efficiency of deployment of IT, and not cost, and correlated upper quartile efficiency with upper quartile sales revenue growth. Efficiently dealing with business exceptions, optimizing key decisions and ensuring end-to-end consistency and efficiency will have a greater impact than replacing an existing application.

But how do we do this? The one thing that we all have in common today is that we are resource constrained. No matter how large or small we are, or how cashed up, there will be some constraint that means we cannot achieve as much as we would like to. It’s like digging a hole. If the hole is one foot around then it’s hard to get more than two people digging at a time, irrespective how many workers with shovels we hire. Large scale business process and SOA efforts have a tendency to deliver enterprise IT blancmange. All process and/or service are considered equal in our great designs, and we tend to spread our investment evenly like thin cream over the pudding. We need a more focused approach.

One way is to break the value-chain into a suite of business capabilities (which we call a Business Services Architecture) and then colour each capability according to how we want to manage it. Is it something like electricity that we consider infrastructure, and which should be managed to a service level agreement (SLA)? Does it represent a non-business critical capability that should be managed to minimise cost? Is it a non-core capability, but one that will opportunistically improved if an ROI can be established? Or does the capability represent something that the business wants to differentiate in? Something that the organisation will aggressively invest in to improve.

Classifying our capabilities this way allows us to take a more nuanced approach. If the capability is something that we want to manage to SLA or cost, then we might consider simply adopting whatever business processes our platform vendor will provide out of the box. If we’re managing it to ROI, then we’ll consider boutique solutions if the business case stands up. If it is to be managed to value, then we’ll even consider creating a bespoke solution so that it meets our requirements perfectly.

By focusing on what really matters, and changing only what needs to be changed to meet our business goals, we can enable fast as possible delivery. We can also focus our investment where it will make the most difference. For example, if we want to differentiate around how we price (to offer globally consistent pricing, perhaps) then creating a standalone rating capability (a small service that simply rates transactions in accordance with our requirements) allows us to commoditize the rest of finance. We can also separate consolidation initiatives (based on cost reduction) from those that are intended to generate value, creating two simple business cases rather than one large, complex one.

What we’re striving for is the ability to find those few capabilities in the business that really matter—the knowledge rich exception management and planning functions that contain all our value—and focus our efforts on those. At the same time we can to aggressively commoditize the capabilities that we don’t want to differentiate in, preventing our competitors from using them to gain an advantage. The business logic that we capture and automate to support these capabilities provides us with the ability to differentiate, while the fact that it is hidden inside the organisation out of site, forcing our competitors to reinvent it from scratch, is our barrier to competition.