by Gregor Hohpe, Enterprise Strategist, AWS
Should you buy your core software applications or build them? Traditionally, executives answered this question with a simple rule: build what differentiates the business; buy the rest. In a world of rapidly-shifting customer expectations, IT decisions are no longer quite so simple--today’s differentiator is bound to be tomorrow’s commodity. Learn how cloud technology opens up new choices for your IT architecture and might even make asking the buy-vs-build question unnecessary.
The limitations of building
When smart executives face difficult IT decisions, they employ heuristics—simple strategies or mental processes that help them form judgments, make decisions, and find solutions to complex problems. Many organizations use a heuristic to answer this critical question: Should we buy our core software applications or build them? The simple rule they use is: If the functionality will differentiate our business, we should build it. But if it doesn’t, we should buy it.
This is a good starting point, but IT isn’t that simple. Self-built software is subject to three limitations that are often ignored:
There is an opportunity cost.
The time your developers spend building a custom project is time they could have invested into generating business value elsewhere, for instance, by working on another product. That’s why you’ll have to account for both their actual costs, such as compensation and equipment, and their opportunity cost, which can be several times as big. The economics of selling commercial software to a broad customer base stacks the odds of building a system cheaper in-house against you. The exception might be commercial software that includes a lot of functionality you don’t need. Fortunately, those kinds of systems are rare.
Software is one link in the chain.
Business value isn’t generated by software development alone. Custom software based on a feature list is only the first link in your value chain. You’ll also need a matching ecosystem of transparency, support systems, and agile processes. Imagine you’ve built a custom front end, but your back-end system has a much slower rate of change. In this scenario, your software engineers will be spinning their wheels as they wait for new features to be delivered. Or that your feature list leaves gaps in areas most valuable to users. To even realize that your list is incomplete, you’ll need a high degree of transparency. And to update the list with more useful features, you’ll need an equally high level of agility.
You’re still invested in it.
Many organizations consider building their own software to gain freedom—if you built it, you can do whatever you please, right? Not quite; you’re still bound by the complexity and asset value of a system, just one of your own making. For example, porting your system to new technology might be more difficult than for commercial software. And resource constraints will likely limit the features you can implement.
The simple buy-or-build decision isn’t so simple after all. Like every IT decision, it is subject to careful interpretation and nuance. To make a good decision takes a lot more than a simple rule or heuristic. That’s why thinking is an IT activity with one of the highest returns on investment.
Enterprise Strategist, AWS
In his role as Enterprise Strategist at Amazon Web Services, Gregor Hohpe advises technology leaders in the transformation of both their technology platform and their organization. Drawing on his experience as Smart Nation Fellow to the Singapore government and as Chief Architect at Allianz SE, he connects the corporate strategy with technical decision making and vice versa. He enjoys sharing his thoughts on architecture and architects in his books, including The Software Architect Elevator and Cloud Strategy.