This mini-series of blog posts has highlighted the nuances of one of the most common and seemingly straightforward IT decisions: whether to build or buy a piece of software. We learned that common notions of cost and lock-in can be misplaced (Part 1), that differentiators are by no means static and can be found in unsuspecting corners (Part 2), and how enterprise architecture can be instrumental in devising a plan to move from a bought environment to include some self-built parts (Part 3). For the final post in this series, I want to show how cloud computing has impacted our IT environment to the extent that the original question might actually no longer be applicable.
Having spent over a decade in professional services, I have heard many consulting jokes, including the one that the answer to any question will be “it depends.” To show that even friendly jabs from colleagues can be insightful, I jested that the pinnacle of a consulting career isn’t avoiding an answer by resorting to “it depends,” but that it’s convincing the customer that they are asking the wrong question in the first place. This tongue-in-cheek advice has actually a good bit of truth behind it. It also leads us to realize that asking “buy or build?” might indeed be the wrong question. But like any good advisor, we owe an explanation to this point of view.
Cloud Computing Platforms
Cloud computing has dramatically changed the way modern IT operates. Rather than wait several weeks for someone to provision a single piece of hardware, self-service portals, automation, and elastic scaling enable a way of working that treats infrastructure as code. Provisioning new infrastructure components has become as simple as deploying a piece of software or calling an application programming interface (API).
However, cloud computing is much more than just infrastructure automation. Modern cloud platforms include numerous services to speed up software delivery, ranging from continuous integration (CI) to serverless platforms and operational tools supporting a DevOps mindset. On top of all this, cloud platforms provide ready-made software components such as databases, event buses, and workflow engines ready to be used and fully operated by the provider. In summary, cloud computing has taken much of the friction out of software delivery.
From Foundation to Modular Platform
When enterprises decided to build software in the past, they would not actually build an application entirely from scratch. They would use a standard operating system, and develop in common programming languages and frameworks. They would also use commercial databases and application servers. However, all these components comprised not much more than a foundation, comparable to a solid concrete slab that you build your house on. From thereon, developers were largely on their own.
Cloud platforms bring much more than just a foundation. The availability of building blocks offered in a serverless model makes developing software similar to building a house from modular, prefabricated components. The past decades have seen prefab buildings evolve from cost-cutting vehicles in low-cost construction to sophisticated, customizable creations that allow for faster builds at high quality. Similarly, building software with prefab components is a great way to speed up software delivery while retaining freedom and high quality.
The availability of a modular platform allows for a new “buy or build” decision that’s not really “either or.” In the previous post we looked at the IT landscape in two dimensions, making the buy vs. build decision based on a top-down view of the functional system landscape.
With a powerful cloud platform underneath, we can now look at that decision from a whole new perspective—a third dimension. Software-intensive systems are routinely built as “vertical stacks,” with one technology built on top of more foundational ones (see diagram). For example, your application might be built on top of an application framework, integration middleware, and an operating system.
The vertical “stack” forms the third dimension of the IT landscape
The dividing lines along the vertical axis used to be fairly clearly drawn : you’d buy the operating system and middleware and build the application. Cloud platforms give you significantly more flexibility and allow you to make a more nuanced division.
Cloud platforms deliver much more than a traditional IT stack
Perhaps you will build your application on a serverless framework like AWS Lambda, orchestrate communication via Amazon EventBridge, and manage stateful interactions with AWS Step Functions. To round things off, you could have Amazon Rekognition analyze images uploaded by your users and use Amazon Fraud Detector to detect suspicious online activities.
In such a scenario, you’re still building differentiating application logic, but there are many pieces that you don’t need to build. So, in addition to asking whether to buy or build, you can also ask how much to build. You can have cloud providers like AWS do the “undifferentiated heavy lifting,” leaving you with a much smaller piece to build.
Instead of asking “buy or build?”, enterprises utilizing cloud platforms can now ask “build how much?”
Rent, Don’t Buy
The availability of cloud platforms makes building software in house more viable than ever before. We at AWS refer to this as “builder culture.” Whereas traditional IT sees itself merely as an integrator of commercial software (remember IBAR?), organizations that are successful in the digital world don’t see software as something deep down in the engine room but as a natural part of their business. So, it’s natural that they want to keep this part in-house—without building the whole stack from scratch.
Another major shift brought by cloud platforms is that you actually no longer “buy” the infrastructure. Rather, you “lease” or “rent” your infrastructure and application-level services. That’s made possible through elastic pricing models that allow you to pay only for what you use. Perhaps this’ll make the buy vs. build decision less difficult, as the upfront financial commitment is much lower.
Instead of buying infrastructure, enterprises now “lease” infrastructure and application services thanks to elastic pricing models.
Build, then Run
After changing “buy or build?” to “build how much?”, the cloud has highlighted yet another closely related decision. It’s no longer just about whether you build your own software but whether you should also run it. In the past, IT had no choice but to operate software on premises, whether it was built in-house or purchased from a vendor, as depicted in the bottom half of the following matrix.
Cloud technology offers two new important options in addition to running software on servers or virtual machines (see the top half of the matrix):
- Use fully operated third-party software in a software-as-a-service (SaaS) model, meaning you neither build nor operate the software.
- Develop software in house but run it in the cloud without worrying about infrastructure in a serverless model. This way, you can build software without having to run most of it.
In most cases, running software that you didn’t build doesn’t make a ton of sense (a chapter in my book Cloud Strategy is aptly titled “Don’t Run Software You Didn’t Build”), making the lower right quadrant of the illustration unattractive. Ironically, this is the quadrant where most IT resources have been spent in the past. This shift highlights the massive change and the associated opportunity that cloud computing brings.
Thanks to cloud computing, a new IT decision is now “to run or not to run?”
You might want to run some aspects of the software that you built, e.g., to monitor application-level performance and correct execution. However, most any development team would be happy to not have to receive a call in the middle of the night because of failed hardware or a false alarm. Therefore, you’ll probably want to run the software that you built in a shared responsibility model that assures secure and reliable operations across customer and AWS cloud platforms.
Asking New Questions
Cloud computing has brought enterprises entirely new options for managing their IT estate. This shift brings enormous opportunity, as long as enterprise are content with asking new questions. So, it’s no longer “buy or build?”, but “build how much?” and “to run or not to run?” We know that decisions make up the essence of a sound IT strategy, asking new questions is a great stepping stone to such a strategy
Buy vs. Build Revisited, Gregor Hohpe
Buy vs. Build Revisited, Part 2: Drawing the Line, Gregor Hohpe
Time to Rethink Build vs Buy, Ishit Vachhrajani