Build vs Buy Analysis Template

Capability need, differentiation test, sourcing options, knock-outs, fit, 5-year cost, time to market, lock-in and exit, skills, risk, weighted score, decision

架构完整ISO/IEC/IEEE 41062:2024; ISO/IEC 25010:2023build buy analysis math更新于 2026年10月22日

在编辑器中打开下载 .md

使用方法: Use it when a capability could be built, bought, subscribed, assembled from open source, taken from an owned platform or outsourced. Fill the capability need and the differentiation test before naming products, then knock-outs and evidence-based fit. The main pitfall is pricing build as its first release only, ignoring years of run, change and people cost.

预览

Build vs Buy Analysis: [Capability name]

Sourcing analysis for one business capability: whether to build it, buy a commercial product, subscribe to SaaS, adopt open source, extend a platform the organisation already owns, or have a partner deliver it. It records the capability need, a differentiation test, knock-out screening, fit against functional and quality needs, five-year cost, time to market, lock-in and exit, skills and operating model, risks, a weighted evaluation with sensitivity, and the decision with its conditions. Structure aligned with the acquisition planning concerns of ISO/IEC/IEEE 41062:2024 (software acquisition) and the quality model of ISO/IEC 25010:2023. Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	[BVB-001]
Capability	[Capability name and ID from the capability map]
Business owner	[@business-owner]
Decision needed by	YYYY-MM-DD
Horizon for comparison	[Example: 5 years]
Version	[0.1]
Status	[Draft / In review / Decided / Superseded]
Owner	[@solution-architect]
Approvers/reviewers	[@cto], [@business-owner], [@procurement], [@security-architect], [@finance-partner]
Last updated	YYYY-MM-DD
Classification	[Internal / Confidential]
Related documents	[ADR-NNN], [TCO-NNN], [TS-NNN], [VES-NNN]

Approvals

Role	Name	Decision	Date
Business owner	[@name]	[Approve / Approve with conditions / Reject]	YYYY-MM-DD
Chief technology officer or architecture board	[@name]	[Decision]	YYYY-MM-DD
Finance	[@name]	[Decision]	YYYY-MM-DD
Procurement	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	First draft: need, differentiation test, long list
0.2	YYYY-MM-DD	[@name]	Example: Knock-out screening and TCO summary added
1.0	YYYY-MM-DD	[@name]	Example: Decided: hybrid (open-source engine plus custom rules)

Decision context
Capability need
Differentiation test
Sourcing options and knock-out screening
Fit assessment
Cost over the horizon
Time to market and delivery capacity
Lock-in, exit and portability
Skills and operating model
Risk comparison
Weighted evaluation and sensitivity
Recommendation and decision
Glossary and references

1. Decision context

Item	Value
Trigger	Example: The pricing logic inside the legacy e-commerce platform cannot run personalised promotions, and the platform is being replaced by a composable stack over the next 18 months
Current state	Example: Prices and promotions are maintained in spreadsheets and loaded nightly; 3 to 5 pricing errors reach customers each month
Cost of doing nothing	Example: Marketing estimates USD 1.2 million a year in promotions it cannot run, plus the manual effort of 2 full-time pricing analysts
Non-negotiable constraints	Example: Live before the peak season of YYYY, 9 months after the decision date; data stays in the EU; must expose APIs to the new storefront and the point-of-sale system
Strategy references	Example: Architecture principle AP-04 "Buy for parity, build for advantage"; cloud strategy CS-2 (managed services first)
Out of scope	Example: Supplier cost pricing and the ERP price master

2. Capability need

2.1 Outcomes

Example: Merchandisers create and schedule promotions without IT involvement, with approval workflow.
Example: Every price shown on web, app and in store comes from one service, so channels cannot disagree.
Example: Personalised offers can be targeted at customer segments in real time.

2.2 Key requirements

ID	Requirement	Type	Must or should
CAP-REQ-001 (Example)	Evaluate price and applicable promotions for a basket of up to 100 lines	Functional	Must
CAP-REQ-002 (Example)	p95 latency below 80 ms at 2,000 requests per second at peak	Performance efficiency	Must
CAP-REQ-003 (Example)	99.95% monthly availability for price evaluation	Reliability	Must
CAP-REQ-004 (Example)	Customer and order data processed and stored in the EU	Security and compliance	Must
CAP-REQ-005 (Example)	Promotion rules editable by business users with versioning and approval	Functional, interaction capability	Must
CAP-REQ-006 (Example)	Simulation of a promotion's margin impact before publishing	Functional	Should
CAP-REQ-007 (Example)	Rules and history exportable in an open format	Flexibility, maintainability	Should

3. Differentiation test

Question	Answer	Evidence
Do customers choose us because of how this capability works?	Example: Partly: promotions drive 30% of revenue, but competitors offer similar mechanics	Marketing analysis MA-17
Does our way of doing it differ from industry practice in ways we want to keep?	Example: Yes for personalised bundles; no for standard discounts	Workshop notes WS-3
Would a standard product force us to change a process we consider an advantage?	Example: Only for bundle logic	Fit-gap FG-2
How often does the capability change?	Example: Weekly rule changes; quarterly new mechanics	Change log
Is there a mature market of products for it?	Example: Yes, several SaaS and packaged products	RFI responses RFI-04
Do we hold, or can we hire, the skills to build and run it?	Example: Partly; rule engine skills are scarce	Skills review

Classification:

Class	Meaning	Default sourcing stance
Differentiating	Sets the organisation apart and changes often	Build or assemble, keep control of the core logic
Parity	Must be done well, but the way it is done is not an advantage	Buy or subscribe, configure rather than customise
Commodity	Standard, stable, widely available	Subscribe or use the platform already owned

Result: [Example: Mixed. Standard price and discount evaluation is parity; personalised bundle logic is differentiating. Options that combine a standard engine with custom rules are therefore in scope.]

4. Sourcing options and knock-out screening

4.1 Options

ID	Option	Description
O1 (Example)	Build	Custom pricing service developed and run by the in-house platform team
O2 (Example)	Subscribe (SaaS)	Commercial pricing and promotions SaaS, configured and integrated
O3 (Example)	Buy (packaged, self-hosted)	Commercial product licensed and run in our cloud account
O4 (Example)	Open source plus custom (hybrid)	Open-source rule engine, custom bundle logic and business UI built in house
O5 (Example)	Extend existing platform	Pricing module of the ERP already licensed
O6 (Example)	Partner delivers and runs	Systems integrator builds and operates a custom service under a managed service contract

4.2 Knock-out criteria

Knock-out	O1	O2	O3	O4	O5	O6
KO-1 Meets CAP-REQ-002 latency at peak (evidence: benchmark or reference)	Pass	Pass	Pass	Pass	Fail	Pass
KO-2 Data stays in the EU (CAP-REQ-004)	Pass	Pass	Pass	Pass	Pass	Pass
KO-3 Live before peak season	Pass	Pass	Fail	Pass	Pass	Fail
KO-4 Within budget ceiling over the horizon	Pass	Pass	Pass	Pass	Pass	Pass
Result	Continue	Continue	Excluded	Continue	Excluded	Excluded

Example notes: O5 failed KO-1 because the ERP module evaluates prices in batch and its synchronous API was measured at p95 410 ms. O3 and O6 failed KO-3: the vendor's earliest installation slot and the partner's mobilisation plan both end after the peak season start. O1 passes KO-3 on plan only (9 months against a 9-month window, zero float); that residual exposure is carried as BVB-RSK-001 and scored in C4 and C6, not hidden by the pass.

5. Fit assessment

5.1 Functional fit

Requirement	O1 Build	O2 SaaS	O4 Hybrid	Evidence
CAP-REQ-001 Basket evaluation	Full (to be built)	Full	Full	SaaS demo D-2; engine PoC P-1
CAP-REQ-005 Business rule editing	Full (to be built)	Full	Partial: UI to be built	Demo D-2
CAP-REQ-006 Margin simulation	Full (to be built)	Partial: no bundle simulation	Full (to be built)	Demo D-2
Personalised bundles (differentiating)	Full	Partial: fixed bundle types	Full	Fit-gap FG-2
Fit summary	All needs met, all to be built	2 partial	1 partial, closed by planned build

5.2 Quality fit

Characteristic	Key concern	O1 Build	O2 SaaS	O4 Hybrid
Performance efficiency	p95 below 80 ms at 2,000 rps	Unproven until built	45 ms at 3,000 rps in vendor test, verified at reference	38 ms at 2,500 rps in PoC P-1
Reliability	99.95% availability	Depends on our operations	Contractual 99.9% only	Depends on our operations
Security	EU data, access control, audit	Under our control	Certified; EU hosting and EU-based support confirmed in the draft contract	Under our control
Flexibility	Add new mechanics quickly	High	Limited to vendor roadmap	High
Maintainability	Long-term change cost	Whole codebase ours	Vendor maintains	Engine maintained by community; custom code ours

Example finding: O2's contractual availability (99.9%) is below CAP-REQ-003 (99.95%). It is not a knock-out because the vendor offers a premium tier at extra cost, which is included in section 6.

5.3 Integration and data fit

[Describe how each option connects to the storefront, point of sale, customer data platform and ERP, and who owns the price data.] Example: all three options expose REST APIs. O2 needs a nightly product catalogue export to the vendor and holds a copy of promotion history; O1 and O4 read the catalogue from the existing event stream.

6. Cost over the horizon

All figures in USD thousand, undiscounted, Example values from TCO-007.

Cost line	O1 Build	O2 SaaS	O4 Hybrid
Year 1 implementation (build or configure, integrate, migrate)	1,400	250	800
Year 1 run (licences or subscription, cloud, people)	100	500	80
Years 2 to 5 run, per year	380	500	300
Years 2 to 5 run, total	1,520	2,000	1,200
5-year total	3,020	2,750	2,080
Exit cost at year 5 (estimate, not in total)	50	300	80

Example arithmetic: O1 = 1,400 + 100 + 4 x 380 = 3,020. O2 = 250 + 5 x 500 = 2,750, where 500 per year is a subscription of 380 (premium availability tier) plus an internal team of 120. O4 = 800 + 80 + 4 x 300 = 2,080. For the net present value of each stream, use the TCO analysis; ranking by undiscounted total is enough here only when the spend profiles are similar.

7. Time to market and delivery capacity

Item	O1 Build	O2 SaaS	O4 Hybrid
First release (standard pricing and promotions)	Example: 9 months	Example: 4 months	Example: 6 months
Differentiating bundle logic	Example: 12 months	Example: Not available; depends on vendor roadmap	Example: 9 months
Team needed	Example: 8 engineers, 1 product owner	Example: 2 integration engineers, 1 configuration specialist	Example: 5 engineers, 1 product owner
Capacity available	Example: Platform team fully booked until Q2; hiring needed	Example: Available	Example: 3 engineers available, 2 to hire
Fits the peak season date?	Example: Only with no slippage	Example: Yes, with margin	Example: Yes, with 3 months float

8. Lock-in, exit and portability

Concern	O1 Build	O2 SaaS	O4 Hybrid
What is locked in	Example: Nothing external; knowledge locked in the team	Example: Rule definitions in a proprietary format, promotion history	Example: Engine-specific rule syntax for standard rules
Data export	Full	Example: CSV export of promotions; history via API only, rate limited	Full
Exit route	Rewrite or replace	Migrate rules to a new product; 6 months parallel run	Swap engine behind the service interface
Contract protections needed	Not applicable	Example: Data return in an agreed format, 12-month exit assistance, price cap on renewal	Not applicable
Open-source licence	Not applicable	Not applicable	Example: Apache-2.0 engine; no copyleft obligations; licence review LR-12
Project health (open source)	Not applicable	Not applicable	Example: OpenSSF Scorecard checks reviewed; 3 active maintainers from 2 organisations

9. Skills and operating model

Activity	O1 Build	O2 SaaS	O4 Hybrid
Product ownership	Internal	Internal	Internal
Engineering of core logic	Internal team	Vendor	Internal team on top of community engine
Configuration of rules	Business users through custom UI	Business users through vendor UI	Business users through custom UI
24x7 operations	Internal SRE rota	Vendor, with internal on-call for integration	Internal SRE rota
Vendor management	Not applicable	Required: 0.2 full-time equivalent	Not required
Skills gap	Rule engine design, high-throughput services	Vendor configuration certification	Engine internals, 2 engineers to hire

10. Risk comparison

ID	Risk	Option	Likelihood	Impact	Response
BVB-RSK-001 (Example)	Build overruns and misses the peak season	O1	High	High	Phase the scope; fall back to manual pricing for one season
BVB-RSK-002 (Example)	Vendor roadmap never delivers bundle types	O2	Medium	High	Contractual roadmap commitment, or accept the gap
BVB-RSK-003 (Example)	Vendor price rises sharply at renewal	O2	Medium	Medium	Renewal cap in the contract
BVB-RSK-004 (Example)	Open-source engine loses maintainers	O4	Low	Medium	Engine isolated behind an internal interface; budget for a fork if needed
BVB-RSK-005 (Example)	Hiring the 2 engine engineers takes longer than planned	O4	Medium	Medium	Short-term contractors from a specialist partner
[BVB-RSK-NNN]	[Risk]	[Option]	[L / M / H]	[L / M / H]	[Response]

11. Weighted evaluation and sensitivity

The weighted score of option $j$ is $S_j = \sum_i w_i s_{ij}$ , with the weights $w_i$ summing to 1 and scores $s_{ij}$ from 1 (poor) to 5 (excellent).

Criterion	Weight	O1 Build	O2 SaaS	O4 Hybrid	Evidence
C1 Functional fit	0.25	5	4	4	Section 5.1; O4 partial closed by its own planned build, O2 partials depend on the vendor roadmap (BVB-RSK-002), and its bundle gap is scored again under C2, so C1 is not lowered twice
C2 Control of differentiating logic	0.15	5	2	4	Sections 3, 5.2
C3 5-year cost	0.20	2	3	4	Section 6
C4 Time to market	0.15	2	5	3	Section 7
C5 Lock-in and exit	0.10	5	2	4	Section 8
C6 Delivery and skills risk	0.15	2	4	3	Sections 9, 10
Weighted score	1.00	3.50	3.45	3.70

Example arithmetic, criterion by criterion from C1 to C6:

\begin{aligned} S_{O4} &= 0.25(4) + 0.15(4) + 0.20(4) + 0.15(3) + 0.10(4) + 0.15(3) = 3.70 \\ S_{O1} &= 1.25 + 0.75 + 0.40 + 0.30 + 0.50 + 0.30 = 3.50 \\ S_{O2} &= 1.00 + 0.30 + 0.60 + 0.75 + 0.20 + 0.60 = 3.45 \end{aligned}

Scenario	Weight change	O1	O2	O4	Leader
Baseline	As above	3.50	3.45	3.70	O4
Example: Urgency dominates	C4 0.25, C2 0.05	3.20	3.75	3.60	O2
Example: Cost pressure	C3 0.30, C1 0.15	3.20	3.35	3.70	O4
[Scenario]	[Change]	[ ]	[ ]	[ ]	[ ]

Example reading: moving 0.10 of weight from C2 to C4 changes O2 by $-0.10(2) + 0.10(5) = +0.30$ and O4 by $-0.10(4) + 0.10(3) = -0.10$ , so the leader changes. The baseline lead of O4 over O1 (0.20) is also inside the rule-of-thumb noise band, so the score alone does not decide. Two facts do: O4 has the lowest 5-year cost by USD 0.67 million (section 6) and meets the peak season date with float (section 7). The business owner confirmed that the date is firm but that a one-season fallback to manual pricing is acceptable, which keeps the baseline weights.

12. Recommendation and decision

Item	Value
Recommendation	Example: O4 Hybrid: open-source rule engine behind an internal pricing service, with custom bundle logic and business UI
Main reasons	Example: Lowest 5-year cost (USD 2.08 million), keeps control of the differentiating bundle logic, meets the peak date with 3 months float
Runner-up and why it lost	Example: O1 Build: highest cost and the peak date only without slippage. O2 SaaS leads only if time to market is weighted above control
Conditions	Example: Two engine engineers hired or contracted by YYYY-MM-DD; PoC P-1 load test repeated at 3,000 rps; licence review LR-12 closed
Next steps	Example: Technology selection of the engine version and hosting (TS-021); ADR-045; update the capability map sourcing column
Review trigger	Example: Revisit if hiring fails by YYYY-MM-DD, if a SaaS vendor adds bundle simulation, or at the 2-year architecture review
Decision	[Approved / Approved with conditions / Rejected], [@decision-maker], YYYY-MM-DD
ADR	[ADR-NNN]

12.1 Decision roles

Activity	Solution architect	Business owner	CTO or board	Finance	Procurement
Capability need and differentiation test	R	A	C	I	I
Options and knock-outs	R	C	A	I	C
Cost summary	R	I	I	A	C
Weighted evaluation	R	C	A	C	C
Decision	C	R	A	C	I

R = responsible, A = accountable, C = consulted, I = informed.

13. Glossary and references

13.1 Glossary

Term	Meaning in this template
Build	The organisation designs, develops and runs the capability itself
Buy	The organisation licenses a commercial product and runs it
Subscribe (SaaS)	The organisation uses a product the vendor runs as a service
Hybrid	A standard component, commercial or open source, extended with custom parts
Differentiating capability	One that sets the organisation apart from competitors and changes often
Parity capability	One that must be done well but is not a source of advantage
Knock-out criterion	Must-have condition; an option that fails it is excluded before scoring
Lock-in	Cost and effort of moving away from an option once adopted
Exit plan	Agreed route, time and cost to leave an option, including data return

13.2 References

Reference	Version or date checked	Use
ISO/IEC/IEEE 41062:2024, Software engineering, Life cycle processes, Software acquisition, iso.org and standards.ieee.org	Edition 2, published October 2024	Acquisition planning concerns (structure only)
ISO/IEC 25010:2023, Product quality model, iso.org	Edition 2, November 2023	Quality characteristics in section 5.2
ISO/IEC/IEEE 12207:2026, Software life cycle processes, iso.org	Edition 2, 2026	Acquisition and supply processes as context
OpenSSF Scorecard, scorecard.dev	Checked at date of analysis	Open-source project health signals
[TCO analysis TCO-NNN]	[Version]	Section 6
[PoC report, demo notes, RFI responses]	[IDs]	Evidence for scores

Standard and licence note

Structure aligned with the acquisition planning concerns of ISO/IEC/IEEE 41062:2024 and the product quality model of ISO/IEC 25010:2023. These are copyrighted standards: only their numbers, titles and the names of quality characteristics are used, and no clause text, tables or definitions are reproduced. The differentiation test, scoring method and all other text are original and follow common industry practice; figures in the worked example are illustrative. Check the current editions at iso.org and obtain the standards for their normative content. Template licence: MIT.