The 5 Types of Data Centre — and Why Each One Has a Different Asset Normalisation Challenge
Enterprise, colocation, hyperscale, edge, and modular data centres all share one problem: inconsistent asset records. But the shape of that problem is different in every environment.
A data centre is a specialised facility designed to house critical IT infrastructure. But not all data centres are the same — and the asset normalisation challenge looks very different depending on whether you run an enterprise DC, a colo, a hyperscale fleet, an edge node, or a modular deployment.
Key Takeaways
- Each of the five data centre types produces a structurally different asset inventory problem — not just a messy spreadsheet.
- Colocation environments are the hardest to normalise because asset records come from multiple tenants with different naming conventions.
- Hyperscale inventories suffer from vendor abbreviation drift at scale — a single inconsistency multiplied across 100,000 rows.
- Edge and modular deployments often lack site context entirely, making location-based normalisation impossible without a site name baseline.
- A normalisation tool that handles all five types must resolve vendor names, classify device roles, parse rack locations, and score data quality — not just reformat columns.
What Is a Data Centre?
A data centre is a specialised facility designed to house critical IT infrastructure — servers, storage systems, networking equipment, and the supporting systems required to process, store, and distribute digital data. These facilities form the backbone of modern digital services: cloud computing, artificial intelligence, financial systems, telecommunications, and enterprise applications.
As demand for data centres continues to grow, their types and technologies continue to evolve. But from an asset management perspective, the most important thing to understand is that each type of data centre produces a structurally different asset inventory problem.
This post covers the five main types of data centre, what makes each one distinct, and what the asset normalisation challenge looks like in each environment.
1. Enterprise Data Centres
What they are: Owned and operated by a single organisation to support internal IT systems, applications, and data processing. The organisation controls the entire facility — power, cooling, network, and every asset inside it.
The asset normalisation challenge: Enterprise data centres typically have one internal naming standard — but that standard has usually evolved over years, with different teams, different procurement cycles, and different CMDB or DCIM platforms leaving traces in the data. The result is a single spreadsheet with three different spellings of "Cisco", rack location strings that changed format when the building was expanded, and status values that mean different things depending on who entered them.
The good news: because there is only one tenant, there is only one set of conventions to resolve. A normalisation pass can establish a clean baseline relatively quickly.
Key normalisation tasks: Vendor alias resolution, model name standardisation, rack location string parsing, status value normalisation, quality scoring.
2. Colocation Data Centres
What they are: Facilities where multiple organisations rent space — racks, cages, or rooms — to host their own IT equipment, while sharing common infrastructure such as power, cooling, and network connectivity.
The asset normalisation challenge: Colocation environments are the hardest to normalise. Asset records come from multiple tenants, each with their own naming conventions, abbreviation styles, and data entry habits. A single export from a colo operator might contain equipment from a bank, a media company, and a logistics firm — each recorded completely differently.
The deeper problem is site context. Without a clear site name or tenant identifier on each row, it is impossible to establish a deterministic baseline. Records that look identical might belong to different tenants and should not be deduplicated.
Key normalisation tasks: Multi-tenant vendor resolution, site name baseline establishment, cross-tenant deduplication with tenant boundary preservation, location string parsing across multiple cage and rack formats.
3. Hyperscale Data Centres
What they are: Large-scale facilities designed to support massive computing workloads, typically operated by global cloud providers. Hyperscale data centres can contain hundreds of thousands of physical assets across multiple buildings, often in multiple countries.
The asset normalisation challenge: At hyperscale, small inconsistencies become large problems. A single vendor abbreviation variant — "Cisco" vs "CISCO" vs "Cisco Systems" — multiplied across 100,000 rows produces a vendor dimension that is effectively unusable for reporting or DCIM import without a normalisation pass.
Hyperscale inventories also tend to have model name drift caused by procurement at scale: the same physical device might be recorded as a model number, a marketing name, a part number, or a combination of all three, depending on which procurement system the record originated from.
Key normalisation tasks: Vendor alias resolution at scale, model name-to-classification mapping, part number resolution, automated quality scoring with exception flagging.
Try Struktive on your own data
Upload a raw asset CSV and get back a normalised, DCIM-ready file in minutes. No account required.
4. Edge Data Centres
What they are: Smaller facilities located closer to end-users to reduce latency and improve performance for applications such as IoT, AI inference, and real-time digital services. Edge data centres are typically unmanned or lightly staffed, with remote management.
The asset normalisation challenge: Edge data centres often have the thinnest asset records of any environment. Because they are remote and lightly staffed, asset data is frequently entered by field engineers rather than dedicated DCIM administrators — which means naming conventions are inconsistent, rack locations are often missing or informal, and device classifications may not exist at all.
The most common issue is missing site context. An edge deployment might have 50 nodes across 50 locations, each with a handful of assets. Without a site name on each record, it is impossible to know which assets belong to which node — making location-based normalisation and baseline diffing impossible.
Key normalisation tasks: Site name baseline establishment, device classification from partial model data, rack location inference, quality scoring with missing-field flagging.
5. Modular Data Centres
What they are: Prefabricated or containerised data centre modules designed for rapid deployment and scalable expansion. Used for temporary deployments, remote locations, and capacity expansion without full facility construction.
The asset normalisation challenge: Modular data centres share many of the same challenges as edge deployments — thin records, inconsistent naming, missing site context — but with an additional complication: asset records are often created at the point of manufacture or deployment, not at the point of operation. This means the records may reflect the factory configuration rather than the actual deployed state.
Modular deployments also tend to be expanded incrementally, with each expansion bringing a new set of records from a different procurement or deployment team, creating version drift in the asset data.
Key normalisation tasks: Factory-to-deployed state reconciliation, incremental expansion baseline diffing, site name and module identifier establishment, vendor and model resolution.
The Common Thread
Across all five types, the asset normalisation challenge comes down to the same set of problems: vendor names that are inconsistent or abbreviated across procurement systems; model names that mix marketing names, part numbers, and abbreviations; device classification that is missing or non-standard; rack location strings entered by different people in different formats; status values that mean different things depending on who entered them; and missing context — site name, tenant identifier, or module ID — that makes deterministic normalisation impossible without a baseline.
A normalisation tool that handles all five types must resolve all six dimensions — not just reformat columns.
Normalising Your DC Asset Data
Regardless of which type of data centre you operate, the normalisation workflow is the same: export your asset inventory from your DCIM, CMDB, ITSM, or spreadsheet — however it came out. Upload it to Struktive, adding a site name if you are working with edge or modular deployments or need a deterministic baseline for colocation. Review the normalised output — vendor names resolved, models classified, rack locations parsed, quality scores assigned. Download the compliance audit pack — SHA-256 fingerprinted, WORM-equivalent storage, ready for your auditor or DCIM import.
For a deeper look at the compliance requirements that apply to each DC type, see How to Make Your Data Centre Inventory Audit-Proof. For the technical detail on the normalisation dimensions, see What Is DCIM Data Normalisation.