
Converged Infrastructure as a Service: From Capex Blueprint to Partner-Sellable Platform
Competitors already had consumption services and we had none. The architecture turned out to be the easy half, because every component I needed belonged to a different team in a business where those teams did not talk to each other.
- Replaced a Capex-only legacy blueprint with a full consumption service, where previously every enterprise deal was configured and supported from scratch
- Hundreds of possible configurations reduced to five sizes a partner could quote without the vendor in the room
- Became the main value driver in the portfolio, with Storage-as-a-Service repositioned as the follow-on upsell once customers said they wanted the full stack
- Opened a partner channel motion the previous Capex-only model could not support
- Layered the service so revenue could start before it was finished, infrastructure first, then support and managed services, then hypervisor, then observability
- Wrote the 38-page PRD covering high, mid and low level design in one document, because four component teams and a partner channel only work from the same requirements if there is one set of them
- Set the margin, cost, discount tiering and pricing, then loaded it into the partner quote-to-cash portal so partners could sell without us pricing every deal
- Fixed the dependency problem by insisting roadmap conversations covered deprecations, not just releases. The shared tracker that came out of it caught live products still selling unsupported hardware
- Blocked the hypervisor layer rather than ship it on bring-your-own licensing, which would have broken the managed support that made the whole service worth buying
- Two roadmap items needed the business convinced before a customer ever saw them, both written up separately: Bare Metal as a Service and Network as a Service
- Fully scoped at departure, with PRDs validated, reference architectures, consumption model and pricing in place, and partners in pilot
Contents
The Context / Challenge
The "Why", what problem needed solving?
I joined an enterprise data infrastructure and hybrid cloud vendor as a Technical Product Manager, owning Converged Infrastructure as a Service end to end within the XaaS portfolio and reporting to the Director of Services Product Management. CIaaS packaged the business's converged compute, networking and storage stack as a subscription service rather than a capital purchase, managed through the platform management plane and taken to market through the partner channel.
Two buyers wanted it. Partners wanted a full-stack service to resell as their own cloud offering, without carrying the capital cost or building the operational capability. Large enterprises wanted the same internally, serving multiple business units from one multi-tenant platform. Dell APEX, HPE GreenLake, NetApp Keystone and Pure were already offering this shape of thing, so demand was proven and the business had no credible answer to it.
What existed was a legacy converged infrastructure blueprint that was not fit for purpose as a service. Capex only, no partner portal, no managed support. Enterprise deals were built from scratch every time out of a large configuration list in Salesforce, with bespoke support arranged alongside. Hundreds of valid configurations existed on paper, which sounds like flexibility and in practice meant nothing could be quoted quickly or handed to a partner to sell.
Underneath all of it sat a structural problem. CIaaS was assembled entirely from components owned by other teams, compute, networking, storage and the management plane, in an organisation that was heavily siloed. That is a dependency problem before it is an engineering one.
The Solution / Process
The "What", what did you design and build?
Built CIaaS to ship in slices rather than all at once, infrastructure first, then support and managed services, then the hypervisor layer, then observability, then the application layer, so each one proved itself with real partners before the next was committed to and income arrived well before the whole thing was finished. That last layer was deliberately left undefined, since it was custom professional and managed services work that could never carry fixed pricing, and naming it honestly on the roadmap beat forcing it into a shape it did not fit.
Built validated reference architectures mapped to S, M, L, XL and XXL sizes, driven mainly by core count and RAM, with storage sized through alignment to the STaaS mid-tier. The design work was as much subtraction as addition: hundreds of configurations were possible, and the deliberate call was to carry only those partners' customers actually bought. Put it all in a single 38-page document, from executive summary and business case through target operating model, consumption costs and node-level sizing, high, mid and low level design together rather than split by team, because four component teams and a partner channel cannot work from the same requirements if there isn't one set of them.
Compute started on the vendor's own branded HPE servers and moved to Supermicro during the product release. Cisco was the networking layer, after an Arista build was scoped and conceptually validated then removed from the supported set once research showed Cisco was what the partner base actually used. Storage was mostly the enterprise-tier array, with the lower tiers including the mid-range tier ruled out on performance and buyer profile. Multi-tenancy did not need designing, since the underlying converged infrastructure stack already had a reference architecture handling it through VLANs and VXLANs, with NSX where VMware Cloud Foundation was in play. The work there was validating that it held up against both buyer profiles and the t-shirt sizes rather than building a separation model from scratch.
Set minimum commit against a financial figure and a term length rather than a fixed hardware footprint, with modular storage add-on tiers carrying burst capability and averaging applied to overage rather than charging on peak. Set the margin, cost structure, discount tiering and pricing myself and had it loaded into the partner quote-to-cash portal as SKU entries, so a partner could price a deal without us in the room. That portal, built with a third party, ran quoting, ordering, procurement, logistics and implementation end to end. It began as a storage-only tool for STaaS, until the business found customers wanted the full stack rather than storage alone. That discovery is what shifted the weight of the portfolio onto CIaaS and left STaaS as the follow-on upsell.
Almost none of this was directive, since no component team reported into this role. Mapped every touchpoint component, approached the principal product managers behind each one directly, moved them from biweekly to weekly one-to-ones, brought colleagues in, and added a quarterly session across the whole group. The more valuable return came from insisting those conversations covered what was being retired as well as what was shipping, which produced a shared tracker covering both. It caught a real problem quickly: a couple of products already on sale turned out to be selling hardware that was no longer supported, and that was closed as a direct result.
The hypervisor layer was blocked by licensing rather than engineering, and the obvious workaround was the wrong answer. This was before Broadcom acquired VMware, and the only subscription route available required the customer to bring their own licences, which would have stopped the business cleanly supporting and managing the platform on their behalf, undermining the exact layer that made CIaaS worth buying. What the product needed was subscription licensing the business could resell in its own right. Owned and drove that requirement internally while the partner manager took it to the vendor, then widened the case to other teams who would benefit from the same structure. It was approaching sign-off at departure. Two more items on the roadmap, Bare Metal as a Service (an upsell layer in the PRD) and Network as a Service with NetFoundry, needed internal buy-in before they could reach a customer. Each was argued through its own Business Model Canvas and has its own entry.
The Artifacts / Deliverables
The "Proof", what tangible things came out of the work?
- One document carrying the high, mid and low level design together, not split by team, running to 38 pages
- Validated reference architectures mapped to S, M, L, XL and XXL sizes, plus bills of materials across the supported configuration set
- Consumption and commercial model: minimum commit by financial value and term, modular storage add-on tiers, burst capability with averaging applied to overage
- The commercial model itself, margin, cost, discount tiers and pricing, built as SKU entries partners could quote from directly
- Product input into the partner quote-to-cash portal, built with a third party and covering quoting, ordering, procurement, logistics and implementation end to end
- Two-year net new roadmap, layered from infrastructure through support and managed services, hypervisor, observability and a deliberately undefined application layer
- Cross-team stakeholder governance across the compute, networking, storage and management plane product teams, with a quarterly all-team session
- A shared tracker covering both new releases and deprecations, which is how unsupported hardware still being sold got caught
- Business Model Canvas for Bare Metal as a Service and for Network as a Service with NetFoundry, each with option research and stakeholder sessions
- Competitive analysis and deep research against Dell APEX, HPE GreenLake, NetApp Keystone and Pure
- Subscription licensing requirement for the hypervisor layer, owned and driven internally with the partner manager taking it to the vendor
- Sales and marketing material drafted for the marketing team, plus training material amendments worked through with the core product teams
The Outcome / Impact
The "So What", what measurable success followed?
- Every enterprise deal used to be configured and supported from a blank sheet. A partner portal, managed support and a repeatable reference architecture replaced that entirely
- What had been hundreds of theoretical configurations became five sizes a partner could actually quote
- Once it was clear customers wanted the whole stack, not just storage, this became the portfolio's main value driver and STaaS became the upsell rather than the product
- Gave the partner channel a motion the old Capex model had no way to support
- Bare Metal as a Service delivered as a billable customer feature, ready to buy and scheduled into the next platform release
- Got four previously siloed product teams reviewing a shared roadmap together, which is what surfaced live products still selling hardware that was no longer supported, and got it closed
Everything needed to sell it existed by the time I left: validated PRDs, reference architectures, a consumption model, pricing, and partners already piloting it.