The Surgeon and the Operating Theatre
Imagine a hospital choosing between two operating theatres.
The evaluation team measures:
- Square footage
- Lighting intensity
- Equipment storage capacity
- Ventilation efficiency
Both theatres score equally.
Theatre A is chosen. It is technically superior.
Six months later, the surgical teams are struggling.
The scrub station is on the wrong side for left-handed surgeons.
The door opens inward, adding three seconds to every emergency entry.
The equipment trolley blocks the anaesthetist's line of sight.
None of these were in the evaluation criteria.
Now imagine a second hospital.
Before the evaluation begins, the surgical lead asks a different question.
Not: Which theatre has better specifications?
But: Which theatre fits how our teams actually operate under pressure?
They measure. They simulate. They test at 2am with a skeleton crew.
They choose Theatre B.
It scores lower on the technical benchmarks.
It performs better in every surgery that matters.
Most organizations evaluate private cloud and HCI platforms like the first hospital.
They measure what is easy to measure.
They miss what actually determines success.
The Wrong Starting Point
When organizations need to select a private cloud or HCI platform, they usually start the same way.
They issue an RFP.
They shortlist vendors.
They run a Proof of Concept.
The POC measures:
- Storage throughput
- VM density
- Workload performance
- Feature checklist completion
- Licensing cost per node
The platform with the best scores wins.
Leadership approves.
Migration begins.
Twelve months later, the same organizations say:
The platform works. But operations are harder than expected.
Upgrade cycles are disrupting delivery windows.
The support model does not match how our teams escalate incidents.
The licensing model changed. Nobody saw it coming.
The skills our team built on the old platform do not transfer.
These are not technical failures.
They are evaluation failures.
A POC cannot measure platform fit.
It is structurally incapable of doing so.
Why Platform Evaluations Fail
Platform evaluations fail for the same three reasons, repeatedly.
1. They Measure Day-One Capability
A POC tests how the platform performs when it is new.
Fully staffed. Expert attention. Optimal configuration.
It does not test how the platform performs at month fourteen.
Under normal team capacity. During a change freeze. At 3am.
2. They Optimize for the Boardroom, Not the Operations Floor
POC results are presented to leadership in slides.
Performance benchmarks. Cost comparisons. Feature matrices.
These are legible to executives.
They are not the variables that determine operational success.
3. They Treat Platform Selection as a Technical Decision
The team running the POC is usually infrastructure or operations.
They evaluate technical capability.
Nobody asks the architecture question:
Does this platform fit our operating model?
That question is not in the RFP.
It is not in the POC criteria.
It is the only question that determines whether the platform succeeds after the vendor leaves the building.
Platform Fitness Evaluation Model (PFEM)
Platform Fitness Evaluation Model (PFEM) is a five-layer evaluation framework for private cloud and HCI platform selection.
Its purpose is direct:
Evaluate not just what the platform does, but whether it fits how your organization operates.
The POC measures platform capability.
PFEM measures platform fitness.
Both are required. Only one is usually done.
Without evaluating all five PFEM layers, platform selection decisions are made on partial signal — regardless of how rigorous the POC appears.
The Five Evaluation Layers
Layer 1: Technical Capability — Can the platform do what we need?
Layer 2: Operational DNA Fit — Does it match how we run infrastructure?
Layer 3: Governance Compatibility — Does it fit how we make and govern decisions?
Layer 4: Migration Architecture — Can we move to it safely, and move off it if needed?
Layer 5: Commitment Risk Profile — What are we betting, and what does it cost to be wrong?
Layer 1: Technical Capability
This is what most POCs already measure.
It is necessary. It is not sufficient.
What to evaluate:
- Compute, storage, and networking performance under target workload profiles
- VM and container density at production scale
- Integration with existing monitoring, backup, and security tooling
- Upgrade path clarity across major versions
- Vendor roadmap alignment with your architecture direction
The trap here:
Technical capability comparisons are always close.
Mature HCI platforms — Nutanix, VMware VCF, Microsoft Azure Stack HCI, Dell VxRail — are technically comparable at enterprise scale.
If your evaluation ends at Layer 1, you are flipping a coin between well-matched options.
The decision is made in Layers 2 through 5.
Layer 2: Operational DNA Fit
This is the layer the POC never tests.
The core question:
Does this platform match how our team actually runs infrastructure — not in ideal conditions, but under real operational pressure?
What to evaluate:
- On-call complexity: How many people need to be available for a Severity 1 incident on this platform? Compare that to your current team structure.
- Upgrade cadence fit: How frequently does this platform require upgrades? Map that against your change management windows and release freeze periods.
- Skill transfer: How much of what your team knows today transfers? What is the retraining cost and the performance dip during transition?
- Failure behavior: What does this platform do when something breaks at scale? Is the failure mode familiar or foreign to your team?
- Day-2 tooling: What do teams actually use to manage this platform day-to-day? Are those tools compatible with your current operational workflow?
Evaluation method:
Do not ask the vendor.
Ask your most senior infrastructure engineer: "If you had to run this platform alone on a Saturday night during a storage failure, what would your experience be?"
That answer tells you more than any benchmark.
Layer 3: Governance Compatibility
Most organizations skip this layer entirely.
The core question:
Does this platform fit how we make architecture decisions, manage compliance, and maintain governance across our infrastructure?
What to evaluate:
- Decision traceability: Can you document and audit configuration decisions made on this platform? This matters for regulated industries and for internal architecture governance.
- Compliance posture: Does the platform's native security model align with your compliance requirements — data residency, encryption at rest, audit logging, access control?
- Multi-team governance: If multiple teams operate on this platform, does it support isolation, quota management, and access boundaries at the team level?
- Policy enforcement: Can platform-level standards be enforced programmatically, or does governance depend on manual review?
- Architecture alignment: Does this platform's model reinforce your enterprise architecture principles, or create exceptions to them?
The governance debt trap:
Organizations that select platforms without evaluating governance compatibility spend the first year retrofitting governance controls onto a platform not designed for them.
That cost never appears in the POC.
Layer 4: Migration Architecture
Every platform selection is also two migration projects.
Migration onto the platform. And eventual migration off it.
Most organizations evaluate only the first. That is the structural gap.
Migration onto the platform:
- What is the minimum viable migration unit — single workload, cluster, or data centre segment?
- What is the rollback procedure if migration fails midway?
- What is realistic migration velocity at team capacity — not vendor-quoted?
- Which dependencies require remediation before cutover, not after?
Migration off the platform:
- If this vendor raises prices by 300%, what does exit cost?
- Which workloads are most tightly coupled to platform-specific features?
- Is there a documented exit runbook, or is exit theoretical?
Organizations that could not answer the exit cost question in 2019 discovered the answer in 2024.
The Broadcom acquisition did not create their risk.
The absence of a Layer 4 evaluation created it.
Layer 5: Commitment Risk Profile
This is the layer that connects platform selection to architecture governance.
The core question:
What are we committing to, and what does it cost if that commitment turns out to be wrong?
What to evaluate:
- Licensing model risk: Is pricing subscription-based? Per-core? Per-node? What are the escalation clauses at renewal?
- Vendor concentration risk: What percentage of critical infrastructure depends on a single vendor? Is that acceptable given your risk tolerance?
- Support dependency: How deeply is your team's operational capability dependent on vendor support? What happens if support quality degrades or prices increase?
- Technology lock-in depth: Which platform-specific capabilities, if adopted, would make future migration significantly more expensive?
- Contract architecture: Who in your organization owns the renewal decision? Is there a governance checkpoint before automatic renewal, or does the contract roll forward by default?
Name the risk explicitly:
For each of the five risk dimensions above, write one sentence stating:
"If this goes wrong, the consequence is ___."
If you cannot complete that sentence, you have not evaluated that dimension.
The PFEM Scorecard
Evaluate each layer on a simple scale.
%% caption: The PFEM scorecard: five evaluation layers, each scored 1 to 5
flowchart LR
A["Layer 1\nTechnical Capability"] --> S1["Score 1–5"]
B["Layer 2\nOperational DNA Fit"] --> S2["Score 1–5"]
C["Layer 3\nGovernance Compatibility"] --> S3["Score 1–5"]
D["Layer 4\nMigration Architecture"] --> S4["Score 1–5"]
E["Layer 5\nCommitment Risk Profile"] --> S5["Score 1–5"]
| Layer | Weight | What a Low Score Looks Like | What a High Score Looks Like |
|---|---|---|---|
| Technical Capability | 20% | Platform cannot meet production workload requirements | Platform exceeds requirements with headroom |
| Operational DNA Fit | 30% | Operations team would need significant retraining and restructuring | Platform fits existing operational patterns with manageable change |
| Governance Compatibility | 20% | Significant governance retrofitting required post-migration | Platform reinforces existing governance model |
| Migration Architecture | 15% | No tested migration path; no documented exit procedure | Validated migration path with rollback; exit runbook exists |
| Commitment Risk Profile | 15% | High licensing risk; deep lock-in; no renewal governance | Predictable pricing; manageable lock-in; renewal checkpoint exists |
Why Operational DNA Fit is weighted highest:
Technical capability failures are visible early.
Operational DNA mismatches are invisible until they are expensive.
What PFEM Changes
PFEM shifts the platform evaluation from a technical exercise to an architecture decision.
From POC to Fitness Test
Instead of: Our POC showed Platform A outperforms Platform B by 12%.
The organization says: Platform A scores 4.1 on PFEM. Platform B scores 3.4.
The gap is in Operational DNA Fit. Platform A's upgrade model conflicts with our change freeze windows.
That conflict costs more than the 12% performance advantage.
From Feature Comparison to Operating Model Match
Instead of: Which platform has the better feature set?
The architecture question becomes: Which platform fits how we will operate it at scale, in two years, under real team constraints?
That question cannot be answered by a vendor datasheet.
It can only be answered by a structured evaluation of all five layers.
From Reactive to Governed
Instead of: The procurement team renews the contract.
The organization has a named governance checkpoint.
Platform Fitness is reviewed annually.
Not just at selection.
The Hidden Structural Gap
There is a structural reason most organizations do not evaluate this way.
Platform selection crosses three functional boundaries.
Infrastructure evaluates technical capability.
Procurement evaluates commercial terms.
Architecture evaluates structural fit.
Nobody evaluates operational DNA, governance compatibility, and commitment risk — because those questions live in the intersection of all three functions.
That intersection has no owner.
And what has no owner does not get evaluated.
%% caption: The hidden gap: each team evaluates one layer, and architecture is often not involved at all
flowchart TD
A["Infrastructure Team\nLayer 1: Technical Capability"] --> D["Platform Selection Decision"]
B["Procurement Team\nLayer 5: Licensing Terms Only"] --> D
C["Architecture Team\nOften not involved"] --> D
D --> E["Layers 2, 3, 4 — Not Evaluated\nOperational DNA | Governance | Migration"]
The result is a decision made on 20% of the available signal.
That is not a rigorous evaluation.
That is a well-documented guess.
What Breaks Without PFEM
When platform selection skips Layers 2 through 5:
Operational Mismatches Appear Late
The platform works.
The team cannot run it efficiently.
On-call procedures do not match the platform's failure model.
Upgrade windows conflict with delivery commitments.
These problems appear in month six.
Nobody designed the evaluation to catch them.
Governance Debt Accumulates
Compliance requirements are retrofitted onto a platform designed for a different control model.
Technical debt is visible.
Governance debt is invisible until an audit.
Exit Becomes a Crisis
The vendor raises prices.
The organization has no documented exit procedure.
No migration runbook.
No tested rollback path.
The exit that should take ninety days takes eighteen months.
The Broadcom shock was not a pricing crisis.
It was the consequence of a missing Layer 4 and Layer 5 evaluation.
The Pattern That Repeats
In multiple organizations, platforms that passed every POC benchmark increased operational escalation load within six to nine months.
Not because the platform failed.
Because the evaluation never tested how the team would run it under pressure.
The on-call load increased. Upgrade cycles missed windows. Engineers who knew the old platform deeply were now learning a new one mid-incident.
None of this appeared in the POC results.
All of it was predictable from a Layer 2 evaluation.
The POC was rigorous. The evaluation was incomplete.
Phase 1: Run PFEM Before the POC (Weeks 1–2)
Most organizations run the POC first and ask governance questions later.
Reverse the sequence.
Before any vendor demo or POC, complete a PFEM pre-assessment:
- Define your Layer 2 operational DNA: How do you currently run infrastructure? What are the patterns you need a new platform to match?
- Define your Layer 3 governance requirements: What compliance, audit, and policy controls are non-negotiable?
- Define your Layer 4 migration constraints: What is your maximum migration window? What workloads cannot tolerate downtime?
- Define your Layer 5 risk tolerance: What vendor concentration risk is acceptable? What is your maximum acceptable cost increase at renewal?
Deliverable: PFEM pre-assessment document for each candidate platform
Success Metric: All five layers scored before any vendor enters your building
Phase 2: Design the POC to Test All Five Layers (Weeks 3–4)
A PFEM-informed POC is different.
Layer 1 testing stays the same: performance, density, integration.
Layer 2 testing adds: simulate a 3am incident. Run an upgrade in a constrained window. Test with your actual team capacity, not vendor-supported capacity.
Layer 3 testing adds: implement your compliance controls natively. Measure the gap between the platform's native model and your governance requirements.
Layer 4 testing adds: run a partial rollback. Test the migration velocity at realistic team capacity. Ask the vendor for a reference customer who has migrated off the platform.
Layer 5 testing adds: model three licensing scenarios — flat renewal, 30% increase, 100% increase. For each scenario, what is the response?
Deliverable: PFEM-scored POC results for each candidate platform
Success Metric: All five layers have evidence, not assumptions
Phase 3: Name a Platform Fitness Owner (Weeks 5–8)
After platform selection, name a governance role.
Not a vendor manager.
An architecture function responsible for a single question:
Is this platform still the right fit for our operating model?
Reviewed annually.
Not just at crisis.
Deliverable: Named Platform Fitness Owner with an annual review checkpoint
Success Metric: Platform fitness is evaluated on a calendar, not in response to a price shock
Evidence from Practice
A financial services company I worked with was evaluating three hyperconverged infrastructure vendors. The PoC measured throughput, latency, and failover time — all technical metrics. The PoC passed. Six months into production, the operations team discovered that none of the three platforms integrated well with their existing monitoring toolchain, the vendor's support model did not match their incident response process, and the licensing model created cost unpredictability.
We rebuilt the PoC evaluation framework to include operational DNA fit — monitoring integration, support model alignment, licensing predictability — alongside technical capability. The vendor that scored highest on technical metrics scored lowest on operational fit. The company chose the vendor that scored highest overall. Eighteen months later, that platform was still running without operational surprises.
Action Plan
This Week
Ask three questions:
- In your last platform evaluation, which of the five PFEM layers were formally scored?
- Can your team describe what exit from your current platform would cost and how long it would take?
- Who in your organization owns the question: "Is our current platform still the right operating model fit?"
If the answers require guessing, you did not evaluate the platform.
You evaluated the vendor's demonstration.
Next 30 Days
- Run a PFEM retrospective on your current platform: score all five layers honestly
- Identify which layer reveals the highest risk or the largest unexamined assumption
- Define one governance action that closes the most critical gap
3–6 Months
- Establish PFEM as the standard evaluation framework for all future platform decisions
- Build Layer 2 operational simulation into every POC process
- Create a Platform Fitness Review checkpoint on the annual architecture governance calendar
- Produce an exit runbook for every platform currently in production
Final Thought
The second hospital chose Theatre B.
Not because it scored highest on the benchmark.
Because someone asked the right question before the contract was signed.
Not: Which theatre is technically superior?
But: Which theatre fits how our surgeons actually work?
Your HCI evaluation will produce a winner.
The POC guarantees it.
What it does not guarantee is that the winner fits how your team runs infrastructure at 3am, twelve months after the vendor left the building.
That answer requires a different evaluation.
Score all five layers.
Before you commit.
Evaluate Platform Fitness Before You Sign the Contract
If your last infrastructure platform evaluation measured performance benchmarks but not operational DNA…
if you cannot state what exit from your current platform costs and how long it takes…
or if platform selection decisions are made by infrastructure teams without architecture governance involvement —
then you are not evaluating platforms.
You are evaluating vendor demonstrations.
In a focused 30-minute Platform Fitness Diagnostic, we will:
- Score your current or candidate platform across all five PFEM layers
- Identify the evaluation gap that represents the highest unmitigated risk
- Define the governance checkpoint your organization needs before any platform commitment
- Produce a PFEM scorecard you can present to leadership alongside the technical POC results
No vendor preference.
No framework theater.
No consultant-speak.
Just a structured evaluation that tells you whether the platform fits — before the contract tells you it does not.
→ Book a Platform Fitness Strategy Session
or
The right platform is not the one that wins the POC.
It is the one that fits how you operate.
