Build, buy, partner: how the decision tilts when the architecture is the wedge.

The build-buy-partner decision, in the enterprise software context, is the structured choice between owning the implementation, procuring it from a vendor, or commissioning it through a partner. The decision criteria written for the previous round of enterprise platform commitments do not, in our assessment, fit the architectural reality of the wedge-architecture portfolios that displaced them. This briefing describes how the decision has changed, where each of the three options is the correct answer in the current architectural posture, and how the wedge tilts the decision toward outcomes that the original framework did not contemplate.

01How the decision changed

The previous build-buy-partner framework, developed against the enterprise software estate of the 2010s, treated the workload as a stable target. The institution chose between writing the system, procuring it, or partnering on it, with the choice held against a five-to-seven-year horizon. The framework worked because the workload was stable enough that a five-to-seven-year horizon was a defensible analytical unit.

The current architectural posture does not support a five-to-seven-year horizon. The wedge architecture decouples the workload from the procurement cycle, and the workload composition itself shifts on a 12-to-24-month cadence. The decision you are now making is not the decision the previous framework was written for, and the criteria that previously distinguished build from buy from partner no longer carry the same weight.

02When build is the right answer

Build, in the wedge architecture, is the right answer in two specific cases. The first is when the orchestration layer encodes a business rule that is competitively distinguishing and that you have reason to expect will remain so across the planning horizon. The orchestration layer, in the wedge architecture, sits above the routing decision and is the place where your specific workflow logic lives. If the workflow logic is your competitive position, you should own the artifact that encodes it.

The second case is when you operate inside a regulatory perimeter that requires the audit artifact to be generated by an asset on your own balance sheet. This case is narrower than it is sometimes assumed to be. Most regulated institutions can satisfy the audit requirement with a vendor-generated artifact retained on your own infrastructure, and the genuine balance-sheet ownership requirement applies to a small number of workload classes inside a small number of jurisdictions.

03When buy is the right answer

Buy, in the wedge architecture, is the right answer for any component below the wedge. The model providers, the inference substrates, the retrieval indices when they are bounded and not competitively distinguishing, the policy enforcement engines: all of these are commodities in the wedge architecture, and you should buy them on the cycle the procurement organization can run.

The criterion that distinguishes a buy from a build below the wedge is straightforward. If the component can be replaced inside the wedge with a routing-policy rewrite, and if the routing-policy rewrite is a contained engineering exercise that the operating model can absorb, the component is a buy. If replacement requires a structural change to the orchestration layer, the component is closer to a build, and the build-versus-buy criteria should be applied to it directly.

04When partner is the right answer

Partner is the right answer for the layer you does not have the talent to build and the procurement model does not have a vendor to buy. In the current architectural posture, that layer is most often the wedge itself: the routing layer, the instrumentation, and the policy enforcement engine, taken as a single integrated system, with a partner who has built it before and who will operate it on your infrastructure.

The partnership structure that has emerged as the modal pattern across the engagements we have run is the commission-and-operate structure described in our December 2025 article. The partner builds the wedge to your specifications, transfers the artifact to your balance sheet, and retains an operating mandate on the artifact for a defined period. The institution owns the wedge. The partner runs it.

05How the wedge tilts the decision

The wedge tilts the decision in three specific ways that the previous framework did not contemplate. First, the wedge collapses a class of historically build-or-buy decisions into a routing-policy rewrite, and removes them from the decision space entirely. Second, the wedge narrows the set of components for which build is the right answer to the orchestration layer and a small number of competitively distinguishing components in the workflow above it. Third, the wedge expands the set of components for which a partner is the right answer, because the wedge itself is a category of asset that does not fit the build-or-buy framing cleanly and is best commissioned from a partner who has built it before.

06Practical sequencing

For an institution facing the next round of platform commitments under the wedge architecture, the sequence we recommend is the following. The first decision is whether the orchestration layer is a build or a partner. If it is a build, you staffs to build it. If it is a partner, you selects a partner with a track record of building orchestration above the wedge. The second decision is whether the wedge itself is a build or a partner. In our experience the answer is partner, and the partner should be selected against the criterion of having built and operated wedges in production at scale. The third decision is the buy decisions below the wedge, which the procurement organization can run on its own cycle once the wedge is in place.

The decisions are sequential, and the sequencing matters. Buying below the wedge before the wedge is in place commits you to a routing posture that the wedge will then have to absorb. Building the orchestration layer before the wedge is in place commits the orchestration to a routing layer that may not be the routing layer you ultimately wants. The wedge is the architectural decision that, taken first, makes the subsequent decisions cleanly separable.