How should a principal-level architect structure a build-vs-buy decision so the organization doesn't get stuck with a stale answer as the surrounding vendor market and the company's own strategy evolve over several years?

## The structural mistake The single biggest structural mistake in build-vs-buy decision-making at scale is treating the decision as a point-in-time judgment recorded once in an architecture document, rather than as an ongoing position that needs periodic re-evaluation against two independently moving variables: - how mature the surrounding vendor market has become for that capability - how the company's own strategy has shifted around it ## The evolution axis Simon Wardley's mapping technique gives useful vocabulary for the first variable: every component of a value chain sits somewhere on an evolution axis: | Stage | What it means | |---|---| | **genesis** | novel, uncertain, nobody does this well yet | | **custom-built** | a few organizations build bespoke versions | | **product** | rival, well-differentiated products exist | | **commodity/utility** | standardized, interchangeable, often consumed as a metered service | A capability that was correctly built in-house because it sat at genesis or custom-built five years ago may have drifted to product or commodity today as a market matured around it, meaning a decision that was right when made can become wrong purely through the market moving, without anything about the company itself changing. **The organization's own strategy** is the second variable: a capability that was commodity and rightly bought two years ago can become the company's new differentiator if strategy pivots toward it -- for instance, a company that bought a generic analytics dashboard may decide, once analytics becomes central to a new product line, that owning and deeply customizing that capability is now worth the investment. ## The recurring review The mechanism for making this tractable at organizational scale is a lightweight, recurring review: maintain an inventory of the company's significant build-vs-buy decisions (not every minor tool, but anything load-bearing or costly), and revisit each on a defined cadence -- commonly annually, or triggered by specific events like a major vendor price change, a vendor acquisition, or a strategy shift -- asking explicitly whether the original classification (commodity vs. differentiating, and market maturity) still holds. This turns build-vs-buy from a one-off project decision into a standing architectural governance practice, similar in spirit to how technology-radar or dependency-audit processes work. ## The trade-off The trade-off in running this discipline is the ongoing overhead of the review itself: someone has to maintain the inventory, schedule the reviews, and have the authority to act on the outcome (which sometimes means recommending a costly migration that wasn't originally planned). The payoff is avoiding two expensive failure modes: - continuing to pay a differentiating-capability price (a large internal engineering team) for something that quietly became commodity years ago and could be bought for a fraction of the cost - continuing to rent a now-strategic capability from a vendor whose product roadmap no longer serves the company's specific direction, ceding competitive ground slowly and invisibly because nobody re-asked the question ## Reversibility Reversibility is the architectural half of this discipline, without which the review is toothless -- if reversing a build-vs-buy decision requires a ground-up rewrite regardless of what the review concludes, the review's recommendation becomes theoretical. - **For bought capabilities**, this means the anti-corruption-layer pattern discussed for vendor lock-in: internal code depends on an interface the organization owns, with a thin adapter translating to the vendor's specific API, so the vendor can be swapped -- or the capability brought in-house -- by rewriting the adapter rather than every call site. - **For built capabilities**, this means keeping the capability behind clean module or service boundaries with a well-defined contract, so that if the capability commoditizes, replacing the internal implementation with a vendor's product behind the same interface is a contained change rather than an organization-wide refactor. ## Vendor-side risk A further dimension unique to the principal level is hedging against vendor-side risk that's independent of the company's own strategy: a vendor can be acquired and have its product discontinued, pivot its roadmap away from the company's use case, or dramatically change pricing at renewal, none of which the company controls. Mature practice treats this as a risk to actively monitor for capabilities the company has bet heavily on buying -- watching vendor financial health and market position, negotiating source-code escrow for critical on-premise software, or in extreme cases deliberately keeping a lightweight in-house fallback plan for a capability that is bought but business-critical. ## A concrete illustration **A concrete illustration of the full cycle.** a company built its own in-house background-job scheduling system in its early years because no mature vendor served its scale and reliability needs well (genesis/custom-built stage). Years later, several vendors now offer managed, highly reliable job-scheduling as a commodity service; a periodic review flags this, and because the original system was built behind a clean internal interface, the company migrates to a bought solution behind the same interface with contained effort, freeing the team that maintained it to work on the company's actual differentiator. This is the discipline working as intended: not a single correct answer to build-vs-buy, but a decision the organization keeps correctly current as both the market and its own strategy keep moving.