# Obtain/build

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/obtain-build

## Quick definition

Obtain/build is an ITIL process that handles getting the parts you need for a service and putting them together. It covers buying new hardware or software, building custom components, and testing everything before it goes live. Think of it as the manufacturing and procurement phase for IT services.

## Simple meaning

Imagine you are responsible for setting up a new coffee shop. The shop is your IT service, and you need everything from the espresso machine to the cups. Obtain/build is the process of getting all those items and putting them together. First, you figure out what you need: the coffee machine, the grinder, the cups, the milk, and the syrups. Then you decide whether to buy them off the shelf or have them custom built. For example, you might buy a standard espresso machine from a supplier, but you might have a custom sign built to match your brand. Once you have all the items, you set them up in your shop. You install the machine, stock the cups, and connect everything. Finally, you test the setup. You pull a few shots of espresso to make sure the machine works, check that the grinder is set correctly, and ensure the milk steamer reaches the right temperature. Only after testing are you ready to open for business. In IT, this process is critical because it ensures that the components of a service are procured or built correctly, integrated properly, and tested thoroughly before they are released to users. Without a structured obtain/build process, you risk deploying faulty components, missing parts, or incompatible systems that can cause outages or poor performance.

## Technical definition

In ITIL 4, the obtain/build process is part of the service value chain activity called 'Design and Transition' and specifically supports the 'Obtain/build' value chain activity. It is responsible for ensuring that service components are available when and where they are needed, and that they meet the agreed specifications. The process covers the procurement of new components, the development of custom components, and the assembly or integration of these components into a working service. It interacts closely with the 'Design and Transition' processes such as 'Change Enablement', 'Release Management', and 'Service Validation and Testing'. 

From a technical perspective, obtain/build involves several sub-activities: sourcing, where the organization identifies and selects suppliers for standard components; development, where custom software or hardware is created according to specifications; configuration, where components are assembled and configured according to the design; and testing, which verifies that the assembled service meets functional and non-functional requirements. For example, in a cloud migration project, obtain/build might involve provisioning virtual machines from a cloud provider, installing operating system images, deploying custom application code from a CI/CD pipeline, and configuring network security groups. 

Standards such as ITIL, COBIT, and ISO/IEC 20000 provide frameworks for this process. In practice, IT service management tools like ServiceNow or Jira Service Management are used to track requests for new components, manage procurement workflows, and link build activities to change requests. Compliance aspects are also important: the process must ensure that all components are licensed, that security patches are applied, and that the build follows organizational policies (e.g., baseline configurations, hardening guidelines). 

One key challenge in obtain/build is managing the dependencies and lead times of different components. A delay in a single component can ripple through the entire build, affecting the release schedule. Therefore, effective supply chain management and close collaboration with suppliers are essential. Version control and configuration management databases (CMDBs) are used to track which components are obtained or built, their versions, and where they are deployed. This ensures that the final service can be audited and that any issues can be traced back to specific components.

## Real-life example

Think about building a custom gaming PC. You have a budget and a list of requirements: you want a powerful graphics card for gaming, a fast processor for video editing, and plenty of RAM. The obtain/build process begins when you decide what components to get. You research and select a high-end graphics card from a manufacturer, a CPU from another brand, a motherboard, a power supply, and a case. You might buy some parts online (obtain) and decide to build a custom water cooling loop yourself (build). While waiting for parts, you receive the motherboard first. You install the CPU and RAM onto it. Then the graphics card arrives, and you install that. Finally, the custom water cooling kit arrives, and you assemble and install it. Once everything is physically in place, you connect all the cables, install the operating system, and run benchmark tests. You check temperatures, stability, and performance. Only after all tests pass do you consider the PC ready for use. This mirrors the ITIL obtain/build process exactly: defining requirements, procuring components, assembling them, and validating the final product. In an enterprise setting, the stakes are higher. A misconfigured server or a missing security patch could lead to a data breach or prolonged downtime. Therefore, the obtain/build process often includes automated deployment scripts, configuration management tools like Ansible or Puppet, and rigorous testing environments that mirror production. The goal is to ensure that every built component is predictable, repeatable, and auditable.

## Why it matters

In any IT organization, the ability to quickly and reliably obtain or build service components directly impacts the speed of innovation and the quality of services. Without a structured obtain/build process, IT teams would face chaos: components might be ordered but never arrive, custom software might be developed without proper testing, and integrations might fail because no one verified that parts work together. This can lead to project delays, budget overruns, and unhappy users. 

For example, consider a company rolling out a new customer relationship management (CRM) system. The obtain/build process ensures that the CRM software license is procured, the servers are provisioned, any custom modules are developed, and the system is configured according to business requirements. If any of these steps is skipped or done poorly, the CRM might go live with missing features, performance bottlenecks, or security vulnerabilities. 

the process supports compliance and governance. By having a documented process for obtaining and building components, an organization can demonstrate that it follows security protocols, uses approved suppliers, and maintains a clear chain of custody for all service components. This is especially important in regulated industries like healthcare or finance. 

From a cost perspective, a well-run obtain/build process reduces waste. It prevents over-ordering, ensures that only necessary components are purchased, and minimizes rework by catching issues early during testing. It also enables better vendor management by consolidating purchases and negotiating better terms. Ultimately, the obtain/build process is a cornerstone of service management because it bridges the gap between design and deployment, ensuring that what was planned actually becomes a working reality.

## Why it matters in exams

For general IT certifications such as CompTIA IT Fundamentals (ITF+), CompTIA A+, and ITIL Foundation, the concept of obtain/build is assessed in terms of basic lifecycle understanding and the importance of procurement and testing. In ITIL Foundation, obtain/build is one of the 34 management practices and appears in the 'Service Value System' context. You may see questions about the order of activities in the service value chain, where obtain/build sits between 'Design and Transition' and 'Release Management'. 

In CompTIA A+ (Core 1 and Core 2), the concept appears in the context of building a PC from components. Exam objectives such as '1.4 Given a scenario, install and configure PC components' and '1.5 Given a scenario, install and configure storage devices' are directly related. Questions might ask about the order of installation, the importance of testing, or compatibility checks. For example, you might need to know that you should install the CPU and RAM on the motherboard before mounting it in the case, and that you should test POST (Power-On Self-Test) before closing the case. 

For CompTIA ITF+, the concept is more basic, covering the idea that components must be acquired and assembled before a system can be used. Questions may be scenario-based, asking what step comes after procuring parts: the answer is assembly and testing. 

In more advanced certifications like the ITIL Managing Professional (MP) stream, the obtain/build process is examined in detail, including its inputs, outputs, activities, and relationships with other processes. You might be asked to identify which role is responsible for obtaining components (supply chain, procurement, or project manager) or to distinguish between obtaining a standard component and building a custom one. 

Overall, exam questions on obtain/build test your understanding of the sequence of activities, the importance of validation, and the integration with change and release management. The key is to remember that obtaining and building is not just about acquisition but also about assembly and verification.

## How it appears in exam questions

Exam questions on obtain/build typically fall into scenario-based, configuration, or troubleshooting categories. In scenario-based questions, you are given a business need and asked to identify the correct order of activities. For example: 'An organization wants to deploy a new web server. After the design is approved, what is the next step?' The correct answer involves obtaining the hardware or cloud instances, building the server according to the design, and testing it. Distractors might include directly releasing to production or skipping testing. 

In configuration questions, you may be asked about the correct sequence of installing components inside a computer case. For instance: 'Which component should be installed first when building a PC?' The answer is the CPU and RAM on the motherboard before mounting the motherboard in the case. Another question might ask about the purpose of testing during the build: 'Why should you perform a POST test before installing the motherboard into the case?' The answer is to verify that the motherboard and key components are functional, avoiding troubleshooting difficulties later. 

Troubleshooting questions may present a built system that does not work and ask you to identify a missing step. For example: 'A technician built a new PC, but it does not power on. The technician did not install the standoffs before mounting the motherboard. What is the most likely result?' The answer is a short circuit. This tests your understanding that proper assembly includes using standoffs to prevent contact with the case. 

In ITIL exams, questions might be more process-oriented: 'Which process ensures that service components are available and meet specifications before release?' The answer is obtain/build. Or: 'What is an input to the obtain/build process?' Inputs include design specifications, supplier contracts, and change requests. 

Some questions combine obtain/build with change management: 'A change request to add a new feature requires a new software module. Which process is responsible for developing and testing this module?' The answer is obtain/build. The key is to recognize that obtain/build is the execution arm of the change process. 

Finally, you might see questions about outsourcing: 'If an organization uses a third-party vendor to develop a custom application, which part of obtain/build is outsourced?' The answer is the 'build' activity, while the organization still retains responsibility for acceptance testing and integration.

## Example scenario

A small business named 'GreenTech Solutions' decides to upgrade its file server. The current server is five years old and runs out of storage space daily. The IT manager, Sam, is tasked with the upgrade. Sam starts by defining the requirements: the new server needs at least 4 TB of storage, supports RAID 5, and must run Windows Server 2022. After the design is approved, Sam moves to the obtain/build phase. He orders a server from a vendor (obtain), which arrives in two days. He also purchases four 2 TB hard drives and a RAID controller card. Once the parts arrive, Sam begins building. He opens the server case, installs the RAID controller in an available PCIe slot, mounts the four hard drives into the drive bays, and connects them to the controller. Then he installs the operating system from a USB drive. After the OS is installed, he configures the RAID 5 array using the RAID controller's utility. Finally, he runs a series of tests: he checks disk performance with a benchmark tool, verifies that the RAID array is recognized correctly, and copies a large file to test read/write speeds. He also checks that the server shows up on the network and has the correct IP address. All tests pass. Only then does Sam decommission the old server and schedule a change window to replace it. In this scenario, the obtain/build process ensured that all components were procured, assembled, configured, and tested before deployment. Skipping any step could have led to issues: if the RAID controller was not compatible with the drives, the build would fail. If Sam did not test, a faulty drive might have gone unnoticed until after the old server was removed, causing data loss.

## Common mistakes

- **Mistake:** Skipping the testing phase and deploying immediately after assembly.
  - Why it is wrong: Without testing, you have no assurance that the built service will function correctly. Undetected faults can cause outages, data corruption, or security vulnerabilities.
  - Fix: Always allocate time for a formal test, such as POST, stress tests, or functional validation, before moving the component to the production environment.
- **Mistake:** Assuming that 'obtain' only means buying off-the-shelf products, ignoring the need for custom build activities.
  - Why it is wrong: Many IT services require custom configuration, integration, or development. Overlooking these can lead to incomplete or incompatible components.
  - Fix: During the design phase, clearly identify which components need to be built or customized, and plan the build activities accordingly.
- **Mistake:** Neglecting to check component compatibility before assembly.
  - Why it is wrong: Using incompatible parts (e.g., wrong RAM type, mismatched CPU socket) can physically damage components or prevent the system from booting.
  - Fix: Before purchasing or assembling, verify compatibility using the manufacturer's specifications. For example, consult the motherboard's QVL (Qualified Vendor List) for RAM compatibility.
- **Mistake:** Forgetting to update the configuration management database (CMDB) after building a new component.
  - Why it is wrong: Without recording the new component, it becomes an 'unknown' configuration item. This makes future troubleshooting, auditing, and change management difficult.
  - Fix: After the build is complete and tested, update the CMDB with the component's details, such as serial number, version, and location.
- **Mistake:** Relying solely on the supplier to perform testing without independent verification.
  - Why it is wrong: Supplier tests may not cover all integration scenarios or real-world loads that the component will face in your environment.
  - Fix: Conduct your own acceptance tests based on your specific requirements, including stress testing and security scanning.

## Exam trap

{"trap":"The exam might present a scenario where a change request is approved, and then ask what the next step is. Learners often choose 'implement the change' or 'release the service', forgetting the intermediate obtain/build phase.","why_learners_choose_it":"Learners confuse the change management process flow with the service value chain. They think that once a change is approved, it goes directly to release. In reality, after change approval, the obtain/build process must acquire or build the necessary components before release.","how_to_avoid_it":"Remember the ITIL service value chain order: Plan, Improve, Engage, Design and Transition, Obtain/build, Deliver and Support. Obtain/build comes after design and before release. Always look for the option that mentions procurement, development, or assembly before deployment."}

## Commonly confused with

- **Obtain/build vs Change Enablement:** Change enablement is about controlling the lifecycle of changes, including approval and scheduling. Obtain/build is about executing the hands-on work of acquiring or creating the components needed for a change. Change enablement decides if and when to do the work; obtain/build does the work. (Example: When adding a new hard drive, change enablement approves the request, while obtain/build involves buying the drive, installing it, and testing it.)
- **Obtain/build vs Release Management:** Release management focuses on making the built components available to users in a controlled manner. Obtain/build ends when the component is built and tested. Release management then takes over to deploy it. Release management handles the packaging, distribution, and deployment methods. (Example: After a software module is built and tested (obtain/build), release management creates a release package and deploys it to production servers.)
- **Obtain/build vs Design and Transition:** Design and Transition is a broader phase that includes activities like requirements analysis, solution design, and planning. Obtain/build is a specific process within that phase focused on execution. Design decides what to build; obtain/build builds it. (Example: During a cloud migration, design and transition decides to use AWS EC2 instances, while obtain/build provisions those instances and configures them.)

## Step-by-step breakdown

1. **Step 1: Requirements and Design Handoff** — The process starts with receiving the specifications from the design phase. This includes detailed technical requirements, component lists, integration points, and testing criteria. Without clear input, the build could deviate from what is needed.
2. **Step 2: Sourcing and Procurement** — Identify the best suppliers for standard components and initiate purchase orders. For custom components, development resources are allocated. This step ensures that all necessary items are available before assembly begins.
3. **Step 3: Assembly and Configuration** — Physically or logically put components together. For hardware, this means installing components inside the chassis. For software, this means installing applications, applying configurations, and establishing integrations. This is the core of the building activity.
4. **Step 4: Integration and System Level Testing** — After assembly, run functional tests to verify that the service works as designed. This includes unit tests for individual components and integration tests for the whole system. Testing catches defects early, reducing rework costs.
5. **Step 5: Validation and Acceptance** — The built service is validated against the original requirements and design specifications. Formal acceptance is documented. This may involve a review by a change advisory board or the service owner. Once accepted, the service is ready for release management.
6. **Step 6: Handover to Release Management** — All built and tested components are formally handed over to the release management process. Documentation, test results, and configuration records are transferred. This ensures a smooth transition to deployment.

## Practical mini-lesson

In practice, the obtain/build process is not a monolithic activity but a series of coordinated tasks that vary depending on the type of service component. For hardware components, such as a new server, the process involves procurement of standard hardware, assembly (installing RAM, CPUs, storage), firmware updates, and hardware health checks. For software components, it may involve cloning a repository, building from source, running automated unit tests, and packaging the artifact. 

Professionals need to be familiar with the tools and methods most commonly used in their organization. For example, DevOps teams use CI/CD pipelines to automate the build and test phases. A typical pipeline might have stages: code commit, build, unit test, integration test, security scan, and artifact publishing. This is a modern implementation of the obtain/build process for software. The pipeline ensures that every build is consistent and that only tested code becomes a release candidate. 

What can go wrong? One common issue is scope creep: during the build, stakeholders may request additional features not in the original design. Without strict change control, this can lead to unplanned work, delays, and quality problems. To mitigate this, any changes to the build should go through a formal change request process. Another issue is dependency management: if the build relies on a specific version of a library or a component that is discontinued, the build may fail. Using version pinning, dependency caching, and alternative suppliers can help. 

Another practical consideration is the environment where the build occurs. For software, using a dedicated build server that is isolated from development and production environments ensures that builds are repeatable and not affected by ad-hoc changes. For hardware, a staging area with proper tools, anti-static precautions, and documentation is essential. 

Finally, documentation is critical. A build book or runbook should be created as the build proceeds. This includes steps taken, configurations applied, and any deviations from the standard. This documentation serves as evidence for audits and as a reference for future maintenance. A well-executed obtain/build process is disciplined, automated where possible, and documented thoroughly.

## Memory tip

Remember 'OBTAIN' as the mnemonic: O - Order (procurement), B - Build (assembly), T - Test (validation), A - Accept (sign-off), I - Integrate (handoff), N - New service ready.

## FAQ

**What is the difference between 'obtain' and 'build' in ITIL?**

Obtain refers to acquiring already existing components, such as buying a licensed software or a ready-made server. Build refers to creating custom components, such as developing custom software or assembling a server from parts. Both activities are part of the same process.

**Is obtain/build a mandatory process in ITIL 4?**

Yes, it is one of the 34 management practices in ITIL 4. While organizations can adapt it to their needs, it is a fundamental process for ensuring that service components are available and ready for deployment.

**Who is responsible for the obtain/build process?**

Typically, a procurement manager handles obtaining standardized components, while a build team (e.g., system administrators, developers) handles the build. The overall process is often managed by a service transition manager or a release manager.

**What happens if testing fails during the obtain/build process?**

If testing fails, the component should not proceed to release. The build team must fix the defects and re-run testing. This may involve rework, returning faulty parts to suppliers, or changing the design. A failed test triggers a formal exception handling process.

**How does obtain/build relate to the configuration management database (CMDB)?**

Every component that is obtained or built should be recorded as a configuration item (CI) in the CMDB. This includes details like version, serial number, and location. Updating the CMDB ensures accurate asset tracking and supports incident and change management.

**Can obtain/build be automated?**

Yes, many aspects can be automated, especially for software. CI/CD pipelines automate the build, test, and packaging phases. For hardware, automation is more limited, but inventory management and ordering can be automated through procurement systems.

## Summary

The obtain/build process is a critical link between designing a service and making it operational. It ensures that all necessary components are acquired or created, assembled, configured, and thoroughly tested before they are handed over to release management. This process is not just about procurement; it involves careful planning, compatibility checks, integration, and validation. 

For IT professionals preparing for certification exams, understanding obtain/build helps you answer questions about the correct sequence of activities in the service lifecycle, the importance of testing, and the distinction between buying and building. In practical IT work, a structured obtain/build process reduces risks, saves costs, and improves service quality by catching defects early. 

The key takeaway for exams is to remember that obtain/build is the 'do' part of the design-to-release pipeline. It comes after design and before release. Always ensure that you associate this process with activities like ordering parts, assembling hardware or software, configuring settings, and conducting acceptance tests. By mastering this concept, you will be able to correctly sequence activities in scenario questions and avoid common pitfalls like skipping testing or confusing it with change enablement.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/obtain-build