--- title: "Deploying a Multinational Holding - HMD Corp's Architecture" description: "How we structured HMD Corp across four divisions and the technical infrastructure that connects them" date: 2024-12-08 category: Business readingTime: "3 min read" --- In 2022, I founded HMD Corporation. By 2024, it had grown into a multinational holding company with headquarters in London and operations spanning four divisions. This post is not about the business strategy. It is about the technical infrastructure that makes a multi-division organisation actually function. ## The Division Structure HMD Corp operates four divisions, each with its own focus: - **HMD Developments** (Technology): software development, product engineering - **HMD Payments** (Finance): payment processing infrastructure (acquired 2022) - **HMD Entertainment**: media and content projects - **HMD Commercial**: commercial operations and partnerships Each division has its own tech stack, its own repositories, its own deployment pipelines. The challenge is maintaining cohesion across all of them without creating a monolithic infrastructure that slows everyone down. ## Shared Infrastructure vs. Division Autonomy The biggest architectural decision was how much infrastructure to share. Too much sharing creates coupling, where a deployment in one division can break another. Too little sharing creates duplication, where you end up maintaining four copies of everything. We settled on a model I call **shared platform, autonomous services**: ### Shared (Platform Level) - **Identity and authentication**: single SSO across all divisions - **DNS and domain management**: centralised under one registrar and DNS provider - **Monitoring and alerting**: unified observability stack - **CI/CD templates**: standardised pipeline templates (each division can extend) ### Autonomous (Division Level) - **Application code**: each division owns its entire codebase - **Databases**: separate database instances, no shared databases - **Deployment targets**: each division deploys to its own infrastructure - **Tech stack choices**: divisions can choose their own frameworks and languages ## The SSO Challenge Single Sign-On across four divisions sounds straightforward until you implement it. Each division has different user types, different permission models, and different security requirements. We built an internal identity provider using OAuth 2.0 with OpenID Connect: 1. **Central auth service**: issues tokens, manages user sessions 2. **Division-specific scopes**: each division defines its own permission scopes 3. **Role mapping**: a user can be an admin in one division and a viewer in another 4. **Audit trail**: every authentication event is logged centrally The key design decision was keeping authorisation division-specific while centralising authentication. The auth service verifies identity. Each division decides what that identity can do. ## Cloud Strategy: Multi-Provider The team does not go all-in on one cloud provider. Different workloads have different requirements: - **AWS** for compute-heavy workloads and services that benefit from the broadest service catalogue - **Google Cloud** for AI/ML workloads and BigQuery analytics - **Azure** for Microsoft-integrated enterprise clients - **Vercel** for frontend deployments and edge functions This is not about avoiding vendor lock-in as a principle. It is about using the best tool for each job. HMD Payments needs AWS's financial services infrastructure. HMD Developments benefits from Vercel's deployment pipeline for Next.js applications. ## Observability Across Divisions When something breaks at 2 AM, you need to know which division, which service, which deployment. Our observability stack is centralised: - **Structured logging**: JSON logs with consistent field names across all services - **Distributed tracing**: trace IDs propagate across division boundaries for cross-service debugging - **Centralised dashboards**: one dashboard per division, one executive dashboard for the holding level The executive dashboard shows high-level health: uptime per division, error rates, deployment frequency, and incidents. It does not show code-level details. That is for the division dashboards. ## Communication Between Divisions Divisions sometimes need to talk to each other. HMD Payments processes payments for services built by HMD Developments. HMD Entertainment uses identity services maintained at the platform level. We use asynchronous messaging for inter-division communication: - **Event-driven architecture**: divisions publish events, other divisions subscribe - **Schema registry**: all event schemas are versioned and validated - **No direct API calls between divisions**: this prevents coupling and cascading failures If HMD Payments processes a payment, it publishes a `payment.completed` event. HMD Developments' product can subscribe to that event. Neither division knows about the other's internal implementation. ## Repository Management With 50+ repositories across four divisions, repository management could be chaos. Our conventions: - **Naming:** `{division}-{project}-{component}` (e.g., `devs-chatguard-api`) - **Templates:** each division has a repository template with pre-configured CI/CD, linting, and testing - **Branch protection:** main branch requires review from at least one division lead - **Dependency management:** automated dependency updates with Dependabot, reviewed weekly ## Scaling the Organisation The technical architecture mirrors the organisational architecture. Autonomous divisions with shared platform services work because they respect Conway's Law: system design follows communication structure. When a new division is added, the playbook is clear: 1. Provision cloud accounts 2. Set up SSO integration 3. Clone the CI/CD template 4. Connect to the monitoring stack 5. Ship The infrastructure was built to make adding divisions cheap. When you are building a holding company, scaling the organisation is as important as scaling the technology.