How COTS became Australia's default software setting

Ever since enterprise resource planning suites started gaining in popularity during the 1990s, CIOs have been asking themselves whether they should build or buy the software required to solve a particular business problem.

There has been a gradual shift, accelerated in recent years by tough economic conditions, to buy commercial off-the-shelf (COTS) software wherever possible. For most organisations, the development of bespoke software is now reserved largely for customer-facing applications that deliver competitive advantage and differentiation.

Yet unless managed carefully, a naive approach to implementing COTS software can fail to deliver on its core promises of lower costs and reduced complexity. It can also stifle innovation.

Australian government departments were relatively late heading down the COTS path in comparison to their corporate counterparts but are rapidly catching up.

In recent years the concept has been driven aggressively by the Department of Finance, following a review of information technology spending conducted by British management expert Sir Peter Gershon in 2008.

As part of broader plans to cut $1 billion out of federal IT budgets, he recommended strengthening the governance of software customisation and bespoke development.

In 2009, the Secretaries ICT Governance Board approved a Customisation and Bespoke Development Policy. This was designed to reduce the percentage of bespoke and customised software used by government, forcing departmental CIOs into using existing government or COTS software. Wherever possible, business systems and business processes were to be standardised.

Department of Defence CIO, Peter Lawrence [pictured, left], says COTS packages are ideal for backend functions because many have matured to the point where they are delivered as pre-configured services.

“Organisations have standard practices at their core including finance, human capital and supply chain that don’t differentiate your business,” he says. “You want them to be as lean and effective as possible.”

For software that interfaces with customers, however, there is still a need to differentiate products and services: “If you look at the emergence of mobile applications, and some of the work that the Department of Human Services is doing, that’s where you’re able to change the service offering. That’s where you see the relevance of bespoke software.”

Although bespoke development still has a role to play, COTS has gradually become the default setting for public and private sector CIOs alike as boards tighten their grip on the purse strings.

Even within the insurance industry, where developing in-house software has long been a badge of honour, Wesfarmers Insurance CIO David Hackshall questions whether it still makes sense. 

This is because off-the-shelf packages for functions like policy administration and claims management have greatly improved and legacy in-house software is expensive to maintain.

He says the first port of call, whenever searching for software to solve a business problem, should be to look within. In larger organisations this will often mean talking to the CIO of other business units that might have already tackled the issue you are dealing with. If this fails to unearth a solution he advises going to market before even considering the development of bespoke software.  

“You should only build software when it gives you a distinct competitive advantage. If it exists in the marketplace, and fits the business problem you are trying to solve, you would be very foolish to build it yourself,” Hackshall says.

“Historically a lot of organisations, particularly those with a strong IT culture, have a propensity to build. IT staffers are typically engineers and code cutters want to cut code. It’s just how they’re wired but you have to temper that and ask whether it’s the right thing to do.”

The middle ground between buying readymade software and building bespoke solutions is to customise a COTS package. Yet as many CIOs have discovered at great cost to their budgets and mental health, this can be a painful experience.

Received wisdom is to operate an 80/20 model that says if a commercial software package is at least 80 percent fit for purpose, it’s worth taking on the customisation job needed to make it more closely aligned to business need. The trick is making sure that developers are restricted to customising as little as possible. Hackshall advises his peers to “govern the hell” out of any COTS customisation.

“A lot of businesses think they’re unique and have different problems to the rest of the world but I don’t subscribe to that,” he says. “Your default position should be to implement off-the-shelf software wherever possible but ... there’s always a bit of tweaking. Where organisations get a bit lost when they buy an off-the-shelf package and customise it to 31 flavours so that the vendor no longer knows what they’ve done.

“You might as well have written it yourself because the vendor will no longer be in a position to support you or, if they are, it will come at substantial cost.”

Prior to taking up his role at the Department of Defence in November 2012, Lawrence spent two decades in the corporate IT world with Shell, Australia and New Zealand Banking Group and, most recently, Origin Energy. One of the tricks he learned along the way was never to mess with the core code when customising COTS software.

This is especially true within large ecosystems like Oracle and SAP, where the vendor is continuously buying start-ups and adding new functionality. As these companies invest billions of dollars in improving their service offerings, Lawrence says, it becomes increasingly important for customers to stay on the upgrade path. The simplest way to do that is by avoiding customisation wherever possible and he advises other CIOs to make sure effective governance structures are protecting this principle, especially for large implementations.

“If you restrict customisation to the add-ons it doesn’t prevent you from doing upgrades to the core product but you can still create differentiation,” he explains. “Keeping the core product as standard as possible allows you to go down the upgrade path and simplifies the addition of maintenance releases.”

Although COTS is now firmly ingrained as the default setting for government CIOs, some industry watchers have become alarmed by the trend. Jorn Bettin, an adviser with IT management consultancy IBRS [pictured, right], says federal adoption of COTS software is “too simplistic” and threatens to deliver inferior services to business and citizens alike.

Although there is a strong case to be made for COTS software in managing backend functions like HR and finance, or even for crisis management systems used by emergency services, Bettin argues that this approach runs into “severe limitations” when it comes to engaging with customers through digital channels.

He contends that every sizable and successful organisation has a competitive/collaborative edge, which by definition goes beyond industry best practice, and can easily be blunted or obliterated by a hasty shift to off-the-shelf IT solutions.

“There’s a huge learning curve ahead for most government organisations in realising that when it comes to the core mission of the organisation they will have to develop high-quality digital services,” he says. “If they attempt to provide those using off-the-shelf solutions they will find that they don’t live up to expectations.”