A structured methodology for technology sourcing decisions. From strategic alignment scoring through TCO modeling, commonalization analysis, and vendor risk assessment — the complete playbook for enterprises that need data, not opinions.
A European industrial group built a custom PLM integration platform across 3 divisions over 18 months. Cost: €4.2M. Two years later, they discovered that a commercial solution could have served all three divisions at €800K total — but by then, three separate teams had built incompatible systems with no commonalization. The real cost wasn't the €4.2M. It was the 2 years of divergence that made consolidation nearly impossible.
This story is not unusual. In conversations with engineering leaders across European industrial groups, the same failure modes appear repeatedly. The root cause is almost never the technology. It is the absence of a structured decision process — and, critically, the absence of a commonalization assessment before anyone writes a line of code or signs a vendor contract.
Each entity builds independently. No central governance, no commonalization assessment. The same problem gets solved 5 times at 5x the cost. Division CTOs protect their autonomy, and group IT lacks the mandate to enforce portfolio-level decisions. The result: incompatible systems that cannot be consolidated without a multi-year migration.
Teams compare Year 1 build cost vs. Year 1 license fee. Real TCO includes 5 years of maintenance, talent retention, infrastructure, training, and opportunity cost. Build costs are front-loaded and visible. Maintenance costs are distributed, hidden in team budgets, and compounding. The build option looks cheap at Year 1 and expensive at Year 5.
Commodities get built because "we've always done it." Core differentiators get outsourced because "the vendor demo looked great." Without a framework, politics wins. The loudest voice in the room determines whether you build or buy — and the loudest voice is usually the one with the most to gain from the decision, not the most to lose.
Every make/buy decision should be evaluated across these six dimensions. The default weights below suit an enterprise industrial group with multiple business entities — adjust weights to match your specific context. A startup may weight Time to Value at 30%. A defense contractor may weight Risk & Dependency at 35%.
Weights must sum to 100. Sections 3, 4, 5, and 6 provide deep-dives on the four highest-weight dimensions.
Does building this create competitive advantage? Is it core to your differentiation, or a commodity that vendors do better? Includes opportunity cost of engineering talent.
5-year fully-loaded cost comparison: development, maintenance, infrastructure, talent, training, vendor fees, integration, migration, and hidden costs.
Can one solution serve multiple divisions, entities, or product lines? Reuse scoring, golden-path potential, and cross-entity standardization opportunity.
Vendor lock-in risk, IP ownership, supply chain dependency, key-person risk (build), technology obsolescence, and regulatory exposure.
How quickly does each option deliver production value? Build timelines vs. vendor deployment, integration complexity, and organizational readiness.
Do you have the talent to build and maintain? Hiring timeline, training investment, retention risk, and build vs. buy culture fit.
flowchart TD
A([Start: Technology Need]) --> B[Strategic Assessment]
B --> B1[Alignment with core competency?]
B --> B2[Competitive differentiation?]
B --> B3[Commonalization across entities?]
B1 & B2 & B3 --> C[Initial Classification]
C --> C1{Core to strategy?}
C1 -- Yes --> D[Build Track]
C1 -- No --> E[Buy Track]
D --> D1[Internal capability assessment]
D --> D2[TCO modeling: 5-year build cost]
D --> D3[IP & talent retention plan]
E --> E1[Vendor market scan]
E --> E2[TCO modeling: 5-year buy cost]
E --> E3[Integration & migration plan]
D1 & D2 & D3 --> F{Build TCO < 1.5x Buy TCO?}
E1 & E2 & E3 --> F
F -- Build wins --> G[Build Governance Gate]
F -- Buy wins --> H[Vendor Selection Process]
F -- Unclear --> I[PoC / Pilot Both]
I --> F
G --> J([Build Approved])
H --> K([Vendor Selected])
style A fill:#1a1a2e,stroke:#7c3aed,color:#e2e8f0
style B fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style B1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style C1 fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style D fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style D1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style E1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style G fill:#1e293b,stroke:#22c55e,color:#e2e8f0
style H fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style I fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style J fill:#0d1f12,stroke:#22c55e,color:#e2e8f0
style K fill:#0d1f12,stroke:#22c55e,color:#e2e8f0Default weight: 30%
Strategic alignment is the single most important dimension because it determines the direction of the entire analysis. A capability that is core to competitive differentiation should almost always be built. A commodity capability should almost always be bought. The hard part is classifying correctly.
| Classification | Definition | Default Action | Examples |
|---|---|---|---|
| Core Differentiator | Creates competitive advantage. Customers choose you because of this capability. | Build | Proprietary algorithms, unique manufacturing processes, core IP |
| Strategic Enabler | Required for strategy execution but not unique to your business. | Build or Partner | Data platform, MLOps pipeline, custom integrations |
| Operational Necessity | Must work reliably. No competitive advantage from doing it differently. | Buy | ERP, email, HR systems, standard MES |
| Commodity Utility | Standardized, interchangeable. Market provides mature solutions. | Buy (SaaS) | Cloud hosting, office tools, project management |
Every engineer building a commodity tool is an engineer not building your core product. The opportunity cost of engineering talent is the most undervalued factor in make/buy decisions.
Default weight: 25%
A 5-year TCO model is the minimum for any technology investment over €100K. Most teams only model Year 1 costs, which systematically favours the build option (low initial cost, high compounding maintenance) over the buy option (higher initial license, predictable annual cost).
Year 1 build cost is typically 40-50% of the 5-year total. The remaining 50-60% is maintenance, talent, and infrastructure.
Year 1 buy cost (license + implementation) is typically 50-70% of the 5-year total. Ongoing costs are more predictable than build.
Hidden costs typically add 15-30% to both build and buy TCO models. Include them in both to avoid bias.
Example: Manufacturing Execution System for 3 entities, 200 users total.
| Cost Category | Build (5-Year) | Buy (5-Year) |
|---|---|---|
| Initial Development / Implementation | €1,200K | €350K |
| Annual License / Hosting | €180K | €400K |
| Maintenance & Updates (5yr) | €900K | €150K |
| Team (dedicated FTEs, 5yr) | €1,500K | €300K |
| Training & Onboarding | €120K | €200K |
| Integration & Migration | €200K | €250K |
| Security & Compliance | €100K | €80K |
| 5-Year Total | €4,200K | €1,730K |
In this example, building costs 2.4x more than buying over 5 years. The build option only appears cheaper at Year 1 (€1,200K vs €1,200K including implementation + first year license). The divergence starts in Year 2 when maintenance and team costs compound.
Default weight: 15%
Commonalization is the most overlooked dimension in make/buy decisions — and the one with the highest ROI for multi-entity organizations. A solution that serves 4 entities instead of 1 doesn't just cut costs by 75%. It eliminates integration debt, enables knowledge sharing, and creates a golden path that accelerates future deployments.
Score each criterion 0-10. A total score above 35 indicates strong commonalization potential and justifies investing in a shared solution. Below 20 suggests entity-specific solutions are appropriate.
| Criterion | Score 0-3 (Low) | Score 4-6 (Medium) | Score 7-10 (High) |
|---|---|---|---|
| Cross-Entity Applicability | 1 entity needs this | 2-3 entities have similar needs | 4+ entities have identical core requirements |
| Interface Standardization | Completely different UX per entity | Similar workflows, different data models | Same workflows, same data models, minor config differences |
| Data Model Compatibility | Incompatible schemas, no shared taxonomy | Partial overlap, mappable with effort | Shared master data, common taxonomy, compatible schemas |
| Deployment Pattern Reuse | Different infrastructure per entity | Same cloud, different configurations | Single deployment serving all entities (multi-tenant) |
| Maintenance Consolidation | Separate teams, no shared code | Some shared libraries, separate deployments | Single team maintains shared platform for all entities |
Before any make/buy decision over €100K, complete this checklist. It forces cross-entity visibility and prevents the most expensive failure mode: building the same thing multiple times.
In every multi-entity organization we have worked with, entity leaders claim their requirements are "completely unique." In practice, 70-85% of functional requirements are identical across entities. The perceived uniqueness is usually in business rules that can be parameterized, not in fundamental architecture. The test: if you can describe the difference in a configuration file rather than a code change, it is not truly unique. Run this test before accepting any entity's claim that they need a separate system.
Default weight: 15%
Both building and buying carry risks. The goal is not to eliminate risk — it is to quantify it and price it into the TCO model. A €200K vendor lock-in exit cost is manageable. A €2M internal platform rebuild due to key-person departure is not.
A worked example comparing four sourcing options for an industrial OEM evaluating a manufacturing execution system. Score each option 1-10 per dimension, multiply by dimension weight, and sum for the weighted total.
| Dimension | Weight | Build In-HouseCustom development | Buy (SaaS)Cloud vendor | Buy (On-Prem)Licensed software | PartnerCo-develop |
|---|---|---|---|---|---|
| Strategic Alignment | 30% | 9/10(27.0) | 4/10(12.0) | 5/10(15.0) | 7/10(21.0) |
| Total Cost of Ownership | 25% | 4/10(10.0) | 8/10(20.0) | 6/10(15.0) | 7/10(17.5) |
| Commonalization Potential | 15% | 6/10(9.0) | 8/10(12.0) | 7/10(10.5) | 9/10(13.5) |
| Risk & Dependency | 15% | 8/10(12.0) | 4/10(6.0) | 6/10(9.0) | 5/10(7.5) |
| Time to Value | 10% | 3/10(3.0) | 9/10(9.0) | 6/10(6.0) | 7/10(7.0) |
| Organizational Capability | 5% | 5/10(2.5) | 9/10(4.5) | 7/10(3.5) | 8/10(4.0) |
| Weighted Total | 100% | 63.5 | 63.5Winner | 59.0 | 70.5 |
In this example, Buy (SaaS) wins for a manufacturing execution system at an industrial OEM. Building scores highest on Strategic Alignment (9/10) but loses on TCO, Time to Value, and Organizational Capability. The MES is operational infrastructure, not a competitive differentiator — the high strategic alignment score for "build" reflects the engineering team's preference, not an objective assessment.
Tiebreaker rule: If two options are within 5 points of each other, run a 6-week parallel pilot. For build vs. buy, this means a vendor PoC alongside a build sprint to validate both TCO models with real data.
Critical check: Before accepting scores, have the group CTO, entity CTOs, and CFO independently assign weights and scores. Different stakeholders produce different winners — the conversation about why is more valuable than the final number.
When you need a quick directional answer before running the full 6-dimension scoring, use this decision tree. It captures the most important branching questions and routes to a recommended approach. The full scoring matrix should then validate and refine the initial direction.
flowchart TD
A{Is this core to competitive advantage?} -- Yes --> B{Do we have the talent to build & maintain?}
A -- No --> C{Does a mature vendor solution exist?}
B -- Yes --> D{Can we build faster than buy+customize?}
B -- No --> E[Partner or Acqui-hire]
C -- Yes --> F{Can it serve multiple entities?}
C -- No --> G[Build with commonalization mandate]
D -- Yes --> H[Build In-House]
D -- No --> I[Buy & Customize]
F -- Yes --> J[Buy & Standardize]
F -- No --> K{Is customization >40% of solution?}
K -- Yes --> G
K -- No --> J
style A fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style B fill:#1e1b4b,stroke:#7c3aed,color:#e2e8f0
style C fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style D fill:#1e1b4b,stroke:#7c3aed,color:#e2e8f0
style E fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style F fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style G fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style H fill:#0d1f12,stroke:#22c55e,color:#e2e8f0
style I fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style J fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style K fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0These are the recurring patterns we see in technology sourcing decisions that go wrong. Critical anti-patterns are organizational failures that require governance changes. High anti-patterns are analytical failures that a framework can prevent. Medium anti-patterns are cognitive biases that awareness can mitigate.
| # | Anti-Pattern | Severity | What Happens |
|---|---|---|---|
| 1 | The Not-Invented-Here Syndrome | Critical | Building because "we know our business best" without evaluating market alternatives. Engineering teams default to building because it is what they do. Without a structured evaluation gate, the build option wins by inertia, not analysis. |
| 2 | The Demo Trap | High | Choosing to buy based on a polished vendor demo without domain-specific PoC. Vendors invest heavily in demo scenarios that showcase best-case performance. Your production workload, data quality, and integration requirements will surface problems that demos hide. |
| 3 | Division Fiefdom | Critical | Each entity makes independent build/buy decisions with no cross-portfolio visibility. Without a central technology investment board, the same problem gets solved 5 times at 5x the cost. Commonalization opportunities are invisible when decisions are siloed. |
| 4 | TCO Amnesia | High | Comparing build cost (Year 1 only) vs. vendor license (annual) — ignoring 5-year total. Build costs are front-loaded but maintenance, talent retention, and infrastructure compound annually. A fair comparison requires a minimum 5-year fully-loaded model. |
| 5 | The Sunk Cost Fallacy | High | Continuing to build because "we've already invested €2M" when buying would be cheaper going forward. Past spend is irrelevant to the forward-looking decision. The question is: what is the cheapest path from today to a working solution in 3 years? |
| 6 | Vendor Lock-in Panic | Medium | Avoiding all vendor solutions due to lock-in fear, even when build cost is 5x higher. Lock-in risk is real but quantifiable. A €200K exit cost is manageable; a €2M build premium to avoid it is not. Price the lock-in risk, don’t treat it as binary. |
| 7 | The Innovation Theater | Medium | Building custom solutions to appear innovative when standard tools would deliver faster. Leadership rewards visible engineering effort over boring but effective vendor implementations. The result is over-engineered internal tools that cost 3x and deliver 6 months late. |
| 8 | Platform Optimism | High | "We'll build a platform that serves everyone" without validating cross-entity requirements. Internal platform projects that attempt to serve all divisions simultaneously fail 70% of the time. Start with 2 entities, prove value, then expand. |
| 9 | The Skills Mirage | Medium | Assuming current team can build and maintain without assessing long-term talent needs. Building is a 1-year project. Maintaining is a 10-year commitment. Teams that can build v1 often cannot retain the talent to maintain and evolve the system. |
| 10 | Governance Vacuum | Critical | No formal decision rights, no commonalization gate, decisions made by whoever shouts loudest. Without a Technology Investment Board and defined thresholds, technology sourcing decisions are political, not analytical. This is the root cause of the other 9 anti-patterns. |
Organizational failures requiring governance changes. These cannot be solved by a better spreadsheet.
Analytical failures that a structured framework prevents. The 6-dimension model eliminates these.
Cognitive biases that awareness can mitigate. Training and decision checklists reduce occurrence.
A framework without governance is a suggestion. Governance without enforcement is theater. The organizations that avoid the €4.2M divergence pattern have four things in place: a Technology Investment Board, mandatory commonalization assessment, decision gates at spending thresholds, and annual portfolio review.
| Investment Size | Decision Authority | Required Artifacts | Review Process |
|---|---|---|---|
| < €100K | Division CTO | Commonalization checklist (self-certified) | Logged in portfolio tracker |
| €100K – €500K | Division CTO + Group Architecture Review | Full commonalization assessment + TCO model (3-year) | Architecture board sign-off required |
| €500K – €1M | Technology Investment Board | 6-dimension scoring + vendor shortlist + PoC plan | TIB vote with cross-entity representation |
| > €1M | Technology Investment Board + CFO | Full business case + 5-year TCO + risk assessment + exit plan | Board-level approval with quarterly progress gates |
Before any build decision is approved, the requesting entity must complete and submit the commonalization assessment. This is the single most effective governance control.
Once per year, the TIB reviews all major technology investments to identify new consolidation opportunities. Markets change, entities evolve, and new commonalization paths emerge.
6-month process • 5 business entities assessed • 4 consolidated to single platform
A European industrial OEM with 5 business entities discovered that 4 of them had independently built or purchased different solutions for the same manufacturing execution workflow. Total spend: €6.8M across the group. After implementing a structured Make/Buy framework with mandatory commonalization assessment, they consolidated to a single platform serving 4 entities, reducing annual IT spend by €1.2M and cutting integration maintenance from 12 FTEs to 4.
The consolidated platform went live for 2 entities within 6 months and for all 4 within 12 months. The 5th entity had a genuinely unique workflow (scored 18/50 on the commonalization assessment) and was correctly left on its existing solution. The key insight: the framework didn't force standardization — it revealed where standardization was warranted and where it wasn't.
The Technology Investment Board, established during this project, prevented 3 additional duplicate technology purchases in its first year of operation. Total first-year savings from the governance change alone: €1.8M (consolidation savings + prevented duplicates).
Key lesson: The commonalization assessment was the decisive factor. Without it, the scoring matrix would have produced a different answer for each entity in isolation. The cross-entity view changed the decision from "build for one" to "buy for all" — a fundamentally different and fundamentally better outcome.
The decision is the beginning, not the end. Technology investments degrade without active monitoring. The teams that get the best outcomes track TCO variance, adoption rates, and commonalization scores with the same rigor they apply to product metrics.
| Metric | Target | Measurement | Escalation Trigger |
|---|---|---|---|
| TCO Variance | Within 15% of approved model | Quarterly actual vs. projected cost comparison | Review if variance exceeds 20% for 2 consecutive quarters |
| Adoption Rate | ≥ 80% of target entities within 12 months | Entity-level deployment tracking and active user count | Escalate if adoption stalls below 50% after 6 months |
| Commonalization Score | ≥ 70% shared components across entities | Ratio of shared vs. entity-specific modules/configurations | Architecture review if customization exceeds 40% of codebase |
| Vendor SLA Compliance | ≥ 99.5% uptime, response times per contract | Monthly vendor scorecard with automated monitoring | Formal vendor review if any Critical SLA missed in quarter |
| Build Quality (if built) | < 5 P1 incidents per quarter | Incident tracking, mean time to resolution, deployment frequency | Review build decision if incidents exceed 3x industry benchmark |
| Annual Portfolio Review | Held every 12 months | Re-score all major technology investments against current market | Trigger consolidation review if new commonalization opportunities found |
These signals indicate the original decision may need revisiting. Don't wait for a crisis — the sunk cost fallacy is the enemy of good course correction.
When monitoring reveals the original decision is no longer optimal, follow this protocol. The goal is not to assign blame — it is to minimize forward-looking cost. The sunk cost is irrelevant.
I help CTOs and CIOs at industrial enterprises run structured make/buy evaluations — from commonalization assessment through TCO modeling, governance design, and vendor selection. You get an objective framework and someone who has seen the same expensive mistakes made across dozens of multi-entity organizations.