Think back 30 years—if you’re old enough—and the world of software was very different. The vast majority of systems that I developed back then were custom-built, for one simple reason: there wasn’t much package or commercial software available on the market, so people generally built it themselves.

Today, the legacy from that era lives on. I still see many of those custom-built systems from the 80s and 90s running at our clients today. For some, these aging infrastructures remain at the core of their business and are performing very well. Others are struggling; legacy systems waiting to be modernized are holding them back, having incurred significant technical debt and consequently constraining innovation.

The shift to package systems…

But whatever the current state of those aging custom systems, the fact is the world moved on after they were built. From the late 90s there was a profound shift in preference for package systems—a move catalyzed by the rise of ERP providers like SAP and Oracle and supported by a burgeoning cottage industry of software players and products.

The result? From HCM to Finance, and from retail management to eCommerce, there was invariably a package available—and usually several competing packages—to meet every business need. And companies embraced them: after years of suffering schedule and cost overruns on big, complex custom builds, clients saw the package route as both lower-cost and lower-risk.

The attractiveness of packaged systems was boosted by custom systems’ complicated and largely custom plumbing, which often seemed to bear little relation to business value or processes. And updating the plumbing to keep pace with changes in the business was expensive and highly specialized work.

…then morphed into the PaaS revolution…

So, the era of the package arrived. Custom was still present, but generally for quite niche areas. But of course, the evolution of the market didn’t end there. Specifically, the past decade has seen the rise of ever more advanced platforms—including platform-as-a-service (PaaS) environments like Cloud Foundry and Red Hat’s OpenShift, alongside an expanding array of cloud platforms ranging from Google to Alibaba and from Amazon to Microsoft Azure.

These players have built rich architectures—sometimes referred to as serverless or cloud-native services—that companies can build custom applications on. A great strength of these architectures is that they take care of the plumbing, helping to make custom development more cost-effective by enabling it to focus on the business processes.

…triggering a return to custom-build

I see these changes heralding in a new era of custom—and moving the pendulum of buy vs build to a more neutral position.  This won’t happen for highly commoditized and common core systems: few clients would or should choose to write their own general ledger, for example. But for the “Class B” software one level down from traditional ERP-type systems—such as more specialized, industry-specific applications ranging from utility smart meter management to core banking—there’s a resurgence in demand for custom-build.

Take the Australian Bureau of Statistics. It has a plethora of package applications that it could choose from and tailor to use for its census. But it decided that the best option—both to meet its own unique needs and better serve the citizens across Australia—was to build the systems itself on AWS. 

Keeping pace with business expectations

What’s more, the drivers behind the revival in custom go beyond the availability of suitable platforms. One of the most powerful factors is that IT functions are struggling to keep pace with the rising expectations of their customers across the business.

Why? Well, as a banking client told me the other day, their business now expects IT performance to be similar to what they see when social media responds to a request—or a consumer application like Netflix delivers new features on a weekly, daily or even hourly basis. They increasingly expect IT to deliver features in a comparable way. If it can’t, they want to know why.

Most package systems—with updates usually no more than once a quarter—simply don’t have the flexibility to respond or add new features at such a pace. Of course, many packages allow for custom extensions; however, one must also consider the drawbacks of such customizations.  If the business wants to evolve an application rapidly to do new and different things, and to create unique and differentiated user experiences for employees, business partners and customers, then it needs to have access to the source code. Which means going for custom systems. 

An ongoing trend

Given these drivers, I think the renaissance of custom is here to stay. If anything, it’s going to accelerate, as more clients recognize that there are new ways of doing custom and new benefits from doing so. Custom is now far less risky than in the past, more responsive to change, and provides better, differentiated outcomes that companies have more fine-grained control over. Put simply, custom is back—and it’s not going away again any time soon.

Adam Burden

Chief Software Engineer

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog