Infrastructure design method

Design starts with the company

The first step is a structured conversation with the CTO and relevant service owners. The goal is to understand business outcomes, constraints, risk appetite, decision rights and the current operating reality before discussing products. The discovery is a conversation rather than a prefilled vendor questionnaire.

Ten discovery dimensions

The team scores ten dimensions on a five-level maturity scale so strengths, gaps and dependencies are visible. The dimensions cover the enterprise rather than only its server estate.

• Business and strategy; people and organization.
• Governance, finance and compliance; applications and workloads.
• Platform and infrastructure; data; security and identity.
• Operations and reliability; financial and FinOps maturity; vendors and sourcing.

Discovery outputs

Discovery produces a current-state inventory, a maturity heat map, a company-specific function shortlist, decision-axis positions and the priority signal that matters most to the customer. These outputs become controlled inputs to assessment; discovery captures the problem and does not preselect the answer.

Function taxonomy

Infrastructure is decomposed into function slots such as hosting, network, identity, observability, service management, security, resilience and FinOps. Core functions are verified for every estate. Conditional functions are included only when a business, technical, security or compliance trigger makes them necessary.

Assess what you already own

Each existing product or service is evaluated for fit, operations, security, portability, support, cost, integration and exit risk. The recommendation is expressed as keep, augment or migrate. A working customer-owned capability is not replaced merely to make the architecture look uniform.

Decision axes

The design records where the company is today, where it wants to be and why across five axes. These positions shape the roadmap and prevent architecture decisions from drifting away from operating reality.

• Enterprise-supported, upstream open source or a hybrid by function.
• Public cloud, datacenter or hybrid deployment context.
• Build versus buy for each differentiating capability.
• In-house versus managed operations and coverage expectations.
• Capital versus consumption economics and predictability needs.

Reference patterns without lock-in

Patterns cover cloud, datacenter and hybrid estates, including multi-provider, multi-region and multi-site scenarios when the requirements justify them. Portable layers run on standard compute and open interfaces. Provider-specific capabilities may still be assessed as customer-owned function choices, but the core design does not depend on a proprietary managed primitive.

The design package

An approved design package contains the target architecture, options considered, decision records, risk register, control model, capacity and resilience targets, implementation roadmap, migration waves, business case, acceptance criteria and the human approval boundary for deployment.