The Obtain/Build Divorce: Why the new ITIL finally split them up
I’ve sat through enough Service Value Chain workshops to know that every time a framework changes a word, a consultant somewhere gets a new boat. Usually, these updates feel like rearranging deck chairs on the Titanic. But with the shift toward the ITIL Product and Service Lifecycle Model, there is one change that actually feels like it was written by someone who has worked in a real office: the Obtain/Build divorce.In ITIL 4, these two were lumped into one awkward middle management cube. It was a catch-all for "getting the stuff we need." But in the new ITIL, they’ve officially moved into separate apartments. Acquire and Build are now two distinct activities. It’s for the best. They were tired of pretending they had anything in common anyway.
The All-in-One Fallacy of the past
To understand why this split matters, we must look at what was wrong with the old way. In the previous version, "Obtain/Build" was treated like a single step in a recipe. It assumed that the process of getting a resource was essentially the same, regardless of whether you were coding a proprietary algorithm or buying a bulk license for a cloud office suite.
This led to what I call the ‘Procurement Blind Spot’. Because the framework didn't differentiate between the two, organizations didn't either. You’d have engineering teams trying to handle vendor contracts (a disaster) or procurement departments trying to manage sprint velocities (an even bigger disaster). By separating them, the new ITIL finally acknowledges that these are two different professional worlds with two different heartbeat rates.
1. Ending the Build Trap and the Hero Complex
Every Product Manager eventually faces the "Buy vs. Build" demon. It usually happens on a Tuesday, during a roadmap meeting where everyone is caffeinated and overconfident. Someone suggests a custom feature, let’s say, a bespoke internal messaging system and the lead dev says: ‘We could probably whip that up in a weekend.’Six months later, you’re still debugging the emoji picker, and your core product hasn't been updated in a quarter. That is the Build Trap.
The new ITIL structure forces you to look at Build and Acquire as two separate strategic paths. It stops treating "Build" as the default and "Acquire" as the backup plan. When you separate them, you’re forced to ask: Is this our core value proposition?But what is this "core"? Think of a Michelin-starred restaurant. The secret sauce is the core. It is reduced, tasted, and guarded like a treasure (Build). But the chef doesn't build his own stove, and he probably doesn't grow his own tomatoes. Those are vital resources, but they don't make him a star chef (Acquire). If a bank builds an app, the interest logic is the core. The system that sends the password reset emails is not. Anyone who builds that themselves is wasting time they should be spending on the sauce.
Sometimes the most heroic thing a team can do is realize the best code is the stuff they never have to write.
2. Acquire is a Paperwork Jungle (And why engineers hate it)
Let’s be real: Acquire is where the fun goes to die. It’s the realm of 47-page Terms of Service, security audits, and negotiating with sales reps who use the word synergy without a hint of irony.
In most decent-sized organizations, this is handled by procurement or legal. These are people who speak the language of payment terms and indemnification clauses. These people are vital, but they are not technical. In the old ITIL model, their work was often invisible, buried under the Obtain label as if it were just a minor side task for the engineers.
But Acquire is high stakes. If you let an engineer "acquire" a platform without oversight, you usually end up with a massive bill because someone left a high-performance instance running over the weekend just to see what happened. I've seen it happen. I've also seen companies get sued because a dev "acquired" an open-source library with a license that basically signed over the company’s firstborn child to a developer across the world. By isolating Acquire, the new ITIL admits that signing a contract is a completely different stress level than debugging a container.
3. Build is for the Makers (The Velocity Problem)
Once the lawyers have stopped arguing and the resources are secured, Build takes over. This is the engineering heart: CI/CD pipelines, automated testing, and the inevitable shrug that comes with the phrase: It worked on my machine.
The reason the split is so vital is the difference in speed. Acquire moves at the speed of a legal department’s lunch break. It is gated by human negotiation and budget approvals. Build moves at the speed of a deployment pipeline. It is gated by logic and coffee.
Mapping them as one activity was like trying to run a marathon while simultaneously filling out a mortgage application. It made the diagrams messy and the people frustrated. When you separate them, you can measure them differently. You don't judge your Build team by how quickly a contract is signed, and you don't judge procurement by engineering metrics.
4. The Symbiosis: Living Side by Side
To see how this works in the real world, look at a modern mobile banking app. The engineering team spends their days in the Build activity, crafting the user interface, the slick animations, and the unique logic that calculates your spending habits. That is their "secret sauce."
But to make that app work, they need a way to verify your identity and a way to host the data. Instead of building a global server network or a facial recognition engine from scratch, the company enters the Acquire activity. They sign a contract with a cloud provider for hosting and a specialized security firm for the ID checks.
Now, Acquire and Build are living side by side. The developers are "Building" the integration layers that connect their custom code to these acquired services. If the cloud provider changes their pricing, it’s an Acquire problem. If the app crashes when you tap "send," it’s a Build problem. By keeping them separate in the lifecycle, the organization knows exactly which lever to pull when something goes wrong.
5. Choose Your Own Adventure
The beauty of this split is that it reflects the reality of modern digital work. Not every company is a software shop, even if every CEO likes to claim they are.For a SaaS heavy company, life happens 90 percent in Acquire. They are buying and configuring tools for their departments. They skip Build almost entirely. They aren't writing code; they are orchestrating service providers. For a custom software house, it’s the opposite. They acquire raw infrastructure and spend their entire life in Build.
Under the old rules, there were endless debates about whether "configuring a plugin" counted as building. The new ITIL settles it: If you are pulling out a credit card or signing a contract, you are in Acquire. If you are committing code to Git or refactoring databases, you are in Build.
The Verdict: Why we should care
Grocery shopping and cooking are both necessary for dinner, but one happens in a parking lot and the other happens at the stove. You wouldn't use a spatula to drive to the store, and you wouldn't use a credit card to flip an egg. And if you do use a credit card to flip an egg: Kudos, my friend, Kudos.
By treating these as distinct stages, the new ITIL helps us regain intentionality. We stop accidentally building things we should have bought, and we start respecting that getting the ingredients is just as important as the cooking itself.
In a world where everyone thinks they can just vibe code their way out of problems, knowing when to just buy the damn tool is a superpower. ITIL (Version 5) doesn't just give us new words; it gives us a language for the friction we've all been feeling for years. It’s about time we let Acquire and Build see other people.
