10.2 Buy vs. Build Decision Framework

10.2 Buy vs. Build Decision Framework

Quick Summary: In ITIL 4 Create, Deliver and Support (CDS), deciding whether to buy commercial off-the-shelf (COTS) software / SaaS or build bespoke custom software is a pivotal strategic determination. This decision balances competitive differentiation and customization requirements against Total Cost of Ownership (TCO), speed-to-market, and ongoing maintenance. Organizations must avoid the perilous 'customization trap' by adopting standard vendor workflows and actively mitigating vendor lock-in.

Modern digital organizations operate as hybrid integrators. When a business requirement emerges, technology leaders must evaluate whether to allocate engineering capacity toward building bespoke software or procuring commercial software packages. Making this choice objectively requires a disciplined decision framework.

---

Strategic Context: Buy (COTS/SaaS) vs. Build (Custom Software)

The foundation of the Buy vs. Build evaluation rests on capability positioning:

• Build (Bespoke In-House Software): Custom engineering tailored specifically to unique enterprise requirements.
  • When to Build: When the capability represents the organization's core intellectual property, provides direct competitive advantage, or when no commercial product satisfies specialized operational demands.
• Buy (Commercial Off-The-Shelf / SaaS): Procuring existing commercial software licenses or cloud subscriptions.
  • When to Buy: When business processes represent standard industry practices (e.g., CRM, general ledger accounting, standard ITSM ticketing) where commercial vendors amortize development across thousands of customers.

---

The Official Build-vs-Buy Conditions

Before applying any commercial model, memorize the two condition lists CDS provides, because scenario questions are built by picking one item from each.

Building service components using existing resources works better when:

• the service component heavily relies on knowledge of the organization and its business
• compliance to standards and policies is a high priority
• service components lack mass-market adoption
• the service provider is undergoing rapid growth — organically or through acquisitions or transformations — which can lead to inconsistent or frequently changing requirements

Buying (or otherwise acquiring) service components from partners and suppliers works well when:

• in-house resources are scarce or highly utilized in other areas
• the skills or competencies needed are highly specialized and would take time to build (most organizations do not manufacture their own computing equipment)
• the processes to build products and services are immature and need to be developed and implemented
• components or services are highly commoditized
• demand for the component is low or subject to significant fluctuation (seasonal demand, or demand triggered by rare events)
• the component is not core to the strategy, brand, or competitive differentiation of the service provider
• creating the component is predictable and repetitive work
• the ecosystem is stable and generally not subject to volatility

[!WARNING] Exam Trap: Immature Processes "Our build processes are immature" feels like a reason to keep the work in-house and mature it. In CDS it is a reason to buy — you acquire the component from a supplier whose processes are already mature, rather than paying to develop the capability while the business waits.

Commodification

As technology adoption increases, higher-order tools emerge to manage that technology more efficiently: virtualization tools appeared to manage growing data centres and computing power; falling compute and storage costs plus mature virtualization produced infrastructure-as-a-service; mature cloud models produced platform-as-a-service, software-as-a-service, and more recently functions-as-a-service. When deciding whether to build or buy, therefore, you must weigh not only today's level of commodification but the ongoing industry trend to commodify that component. Building something the market is about to commoditize is a predictable write-off.

---

Defining Requirements for Service Components

A build-versus-buy decision is only as good as the requirements it is evaluated against. CDS warns that requirements should reflect the needs of all relevant stakeholders and must not be limited to the functional needs articulated by users. Other stakeholders typically raise:

• maintainability and supportability of the component
• geographic location of vendor resources
• cultural alignment between the organization and the vendor
• cost of service consumption — skills needed in-house, and financial outflow over time
• alignment with the organization's business, technical, and information architecture
• vendor brand and public image
• interchangeability of vendors

A common approach is to focus on the technical, functional and non-functional features of a product. It is frequently better to define requirements as outcomes: a technical requirement to "use email" is better phrased as "communicate with users"; "check out and check in code" is better phrased as "version control code". Outcome-framed requirements keep more candidate solutions in play and stop the requirement from silently pre-selecting a product.

The MoSCoW Prioritization Method

Once requirements are gathered, they must be prioritized. CDS names MoSCoW for this purpose:

The MoSCoW method is a simple prioritization technique for managing requirements. It relies on cooperation, and often negotiation, between all relevant stakeholders. As a result, it allows stakeholders to explicitly agree on priorities.

The exam value of MoSCoW is the phrase "explicitly agree". Its purpose is not speed or arithmetic — it is producing a shared, negotiated, unambiguous statement of what matters, so that stakeholders cannot later claim their requirement was silently dropped.

[!WARNING] Exam Trap: MoSCoW vs. WSJF vs. Impact/Urgency Three prioritization techniques appear in CDS and they are not interchangeable. MoSCoW prioritizes requirements by negotiated agreement among stakeholders. WSJF sequences work items economically, dividing Cost of Delay by job duration (section 9.2). Impact × Urgency prioritizes incidents and tickets operationally (sections 7.1 and 9.2). Match the technique to the object being prioritized.

---

Comprehensive Total Cost of Ownership (TCO) Analysis

Flexibility vs. Standardization: The Customization Trap

Modifying commercial software to mimic legacy internal workflows is a notorious enterprise anti-pattern:

[Commercial Software] ──+── Standard Adoption ──> Seamless Upgrades, Lower TCO
                        │
                        └── Heavy Customization ──> [Forked Codebase]
                                                          │
                                Vendor Releases Patch ───▼
                                         [Upgrade Breaks Custom Logic]
                                                          │
                                         [Trapped on Legacy Version]

Hazards of Customizing COTS:

• Broken Upgrade Paths: Vendor patches and feature releases overwrite custom code or trigger extensive regression failures, stranding the enterprise on obsolete, vulnerable versions.
• Support Invalidation: Software vendors routinely refuse to troubleshoot issues if underlying database schemas or core code execution scripts have been altered.
• Compounding Technical Debt: Custom modifications must be maintained entirely by the customer, combining commercial licensing expenses with the maintenance overhead of bespoke software.

The ITIL CDS Principle: "Vanilla Adoption"

• Adapt the Business Process, Not the Software: Organizations should alter internal workflows to match the out-of-the-box, industry-standard practices designed into commercial software.
• Extend Externally via Clean APIs: If extension is unavoidable, build modular microservices or middleware connecting through official REST/GraphQL APIs—never alter core vendor code directly.
• The Decision Rule: If an organization cannot adapt its business processes because those processes represent a proprietary, competitive advantage, do not buy COTS—build custom software instead.

---

Mitigating Vendor Lock-In, Data Portability, and Escrow

Commercial software introduces vendor lock-in, where high switching costs and proprietary dependencies trap the organization. Enterprises must establish contractual safeguards:

• Open API Standards: Select solutions with documented REST/GraphQL APIs to ensure interoperability and prevent data silos.
• Data Portability Guarantees: Mandate contractual rights to export all transactional and master data in structured, non-proprietary formats (e.g., JSON, CSV, standard SQL).
• Software Escrow Agreements: An arrangement where vendor source code and build artifacts are held by an independent trustee, released to the customer if the vendor becomes insolvent or breaches maintenance contracts.
• Sunset and Exit Clauses: Explicit contractual terms defining vendor transition support, parallel run assistance, and certified data destruction upon contract termination.

---

Six-Factor Enterprise Decision Matrix

Cross-functional teams should evaluate Buy vs. Build decisions across six enterprise criteria:

---

Critical Exam Traps & Practical Takeaways

[!WARNING] Exam Trap: The Illusion of Zero Maintenance in Commercial Software
Buying software does not eliminate ongoing IT effort. Integration maintenance, identity governance, data pipelines, user onboarding, and upgrade regression testing require sustained operational capacity.

[!TIP] Practical Rule: The Customization Red Line
Adopt commercial packages 'vanilla.' If business units insist on extensive customizations to support non-standard processes, treat this as a signal to build bespoke software rather than corrupting a commercial package.