Reference Architectures and Industry Data Templates: When a Head Start Pays Off, and When It Costs You

An industry data template is a pre-built, governed data model and KPI set for one sector, such as consumer goods or utilities. A reference architecture is the agreed design the platform is built against. Templates shorten the first release when your data resembles the sector's; a blueprint should come first when the estate itself is still undecided.

Most enterprise data programmes rebuild the same foundations. Product, customer, channel, geography and time for a consumer goods company. Asset, network, outage, customer and crew for a utility. Each team models them again, argues about definitions again, and spends its first months on work that looks much like every other company's in the same sector.

That repetition is why templates and accelerators exist. They also fail in a recognisable way: a model built for the typical company is bent to fit an atypical one, and the bending costs more than starting fresh would have.

What follows sets out the three starting points, what each one settles, where each one breaks, and how to choose between them before money is spent.

#What Reference Architectures and Industry Templates Actually Are

The two terms are often used as if they meant the same thing. They solve different problems and are bought at different moments.

A reference architecture, delivered as an architecture blueprint, decides the structure of the platform. It names the systems, the boundaries between them, how data moves, who owns each domain and which standards engineers must follow. Its output is a set of diagrams, decisions and rules. It contains no data.

An industry data template decides the content of the platform for one sector. It provides the entities, relationships, KPI definitions and often the transformation logic that a typical company in that sector needs. Its output is a working data model that is loaded with your data and adjusted where yours differs.

What this means for you: a blueprint answers "how should our platform be built", and a template answers "what should it model first". Confusing the two is how teams buy a template to solve an architecture problem it cannot touch.

#Blueprint, Template or Custom Build at a Glance

The three starting points are not exclusive. Many programmes use a blueprint and then a template, and every template leaves some custom work. The final column is the one to read first.

#What an Architecture Blueprint Settles Before Anyone Builds

What this means for you: if two teams would draw your data platform differently today, a template will inherit that disagreement rather than resolve it.

A blueprint is the cheapest point at which to make expensive decisions. Our architecture blueprint sprint runs for four weeks and produces the artefacts engineering teams need to build without waiting on a central decision-maker.

#The views that make it buildable

The C4 model, set out by Simon Brown, describes software at four levels: system context, containers, components and code. Applied to a data platform, the first two levels are usually enough to settle which systems produce data, which consume it, and where the boundaries sit.

Beneath those views sit the decisions that most often cause rework later: the target platform, the integration pattern between operational systems and the analytics estate, and who owns each data domain. Recording each one as a short architecture decision record means the reasoning survives staff changes.

#Where it connects to the data

The blueprint also fixes how data moves between teams. Data contracts, agreed between the team that produces a dataset and the teams that consume it, turn those boundaries into something a build pipeline can check. Our data architecture service carries those designs into the platform itself.

#What the roadmap sequences

The last output of a blueprint is an order of work. Some foundations have to exist before anything above them can be trusted: agreed identifiers for products, assets or customers; a landing zone with access controls; and the first quality checks on the feeds that matter most. A roadmap that starts with dashboards before those exist is a roadmap for rework.

A blueprint is cheapest the week before anyone writes a pipeline.

The roadmap also tells you when a template can be introduced. Once the platform, the ownership model and the integration pattern are fixed, a template has something stable to land on, and its first release can be measured against a baseline.

#How a CPG Data Template Shortens the First Release

What this means for you: consumer goods data has a strongly shared shape, which is exactly why a template can save months here.

Almost every consumer goods company models the same core: products and their hierarchy, retailers and distributors, channels, geography, time and promotions. The arguments are also shared, especially over which sales number is true when shipments, sell-in and retailer point-of-sale data disagree.

Our CPG intelligence accelerator starts from that shared core. It provides governed product, channel, geography, promotion and inventory domains, with demand and supply signals and a semantic layer so commercial, supply and finance teams read the same KPIs. The target is a first release in 8 to 12 weeks, scoped to the domains your data supports.

The template's real value is the arguments it settles before your teams have them.

#Where the CPG template stops fitting

The template fits a branded manufacturer selling through retailers. It fits less well where most revenue is direct to consumer, where products are configured to order, or where the company is both manufacturer and retailer. In those cases the customer and order domains look more like a retailer's than a manufacturer's, and the bending starts.

A partial fit can still be worth taking. If the product, geography and time domains map cleanly but the customer domain does not, adopt the template for the domains that fit and design the customer model yourself, joined through the same identifiers. That keeps most of the time saving without forcing an unusual business into a typical shape.

Retail-side analytics follow different logic again; our account of big data analytics in retail covers the retailer's view of the same products.

#How a Utilities Template Handles SCADA, GIS, AMI and Outage Data

What this means for you: utilities have an international standard for describing their networks, which makes a template unusually reusable across companies.

The Common Information Model, published by the International Electrotechnical Commission as IEC 61970 and IEC 61968, defines how network assets, topology and distribution operations are described. Systems from different vendors can map to the same entities, so a model aligned to it survives vendor upgrades.

Our utilities intelligence accelerator is built on a model aligned to that standard. It brings asset, network, outage, customer and crew data from SCADA, GIS, smart-meter and outage-management systems into one governed layer. The target is a first release in 10 to 14 weeks.

#Reliability reporting with lineage

Utilities report network reliability through SAIDI, SAIFI and CAIDI, the indices defined in IEEE Std 1366. The arithmetic is simple; the exclusions are not. Which events count as major, and why, has to be traceable from the published figure back to the outage records.

A template that codifies those exclusion rules once, with data lineage from source system to KPI, saves the reconciliation work that otherwise repeats before every regulatory submission.

#Keeping operational systems untouched

Grid operators rightly protect their operational technology. A sound template reads from SCADA historians, GIS, smart-meter head-ends and outage-management systems; it does not write to them or install tooling inside the protected network. Data leaves through the outbound paths the security boundary already permits, so the analytics layer can change without changing the operational estate.

#The data volume nobody budgets for

Smart-meter data changes the scale of the platform. A meter read every 15 minutes produces 96 readings a day, so a million meters produce 96 million a day. Partitioning, late-arriving reads and multi-year retention have to be designed in from the first release rather than added after the first storage bill.

#Signs a Template Will Fit Your Estate

Four checks predict whether a template will save time or cost it. Each can be run on a sample of your data before any contract is signed.

#When a Template Is the Wrong Starting Point

A template is the wrong first purchase in three situations.

The first is an atypical business. If a sample of your data maps poorly to the template's model, every week saved at the start is spent later on workarounds. A custom model is slower to begin with and faster to maintain.

The second is an unsettled architecture. A template lands on a platform; it does not choose one. Buying a template while the target platform, integration pattern and data ownership are still open moves the architecture argument into the template project, where it is more expensive.

Even where a template fits, plan for how it will change. Templates are revised as standards and sector practice move on. Keep your own extensions in a separate layer from the template's core model, with their own owner and tests, so that adopting a newer version of the template does not overwrite the parts that make the model yours.

The third is where the model is the product. If the way you describe your products, assets or customers is itself your advantage, a shared industry model will flatten exactly what makes you different. In that case, design the model yourself and use the template only as a checklist of what not to forget.

#How to Choose a Starting Point

The sequence matters more than the starting point you pick. A first release scoped to one domain moves in weeks; extending it across the estate is the multi-quarter work.

1. Check whether the architecture is agreed. Ask two senior engineers to sketch the data platform separately. If the sketches differ, start with a blueprint.
2. Run the fit test on a sample. Map one representative extract to the template's model and count what maps directly.
3. Name the owner of each domain. A template or a custom model both fail without someone accountable for each definition.
4. Scope the first release to one domain. Pick the domain where a named team will act on the output.
5. Publish the definitions through one layer. Use a semantic layer so every report reads the same KPIs.
6. Extend only after the first release is used. The second domain should cost less than the first; if it does not, revisit the foundations.

Whichever starting point you choose, the platform underneath follows the same build order described in our data platform engineering work, and the wider sequencing in the autonomous enterprise architecture explains why the foundation layers come first.

#Frequently Asked Questions

#What is an industry data template?

An industry data template is a pre-built data model, set of KPI definitions and transformation logic designed for one sector, such as consumer goods or utilities. Instead of modelling common entities like products, assets or customers from scratch, a team loads its own data into the template and adjusts the parts where its business differs from the sector's typical shape.

#What is the difference between a reference architecture and a template?

A reference architecture, or architecture blueprint, decides how a data platform is structured: which systems exist, where boundaries sit, who owns each domain and which standards apply. An industry template decides what the platform models for one sector. A blueprint contains no data, while a template is a working model loaded with the company's own data.

#When should a company build a custom data model?

A custom data model makes sense when a sample of the company's data maps poorly to the available industry templates, or when the way it models its products, assets or customers is itself a competitive advantage. In both cases a template's shared assumptions cost more to work around than a model designed for the business from the start.

#How long does an industry template take to deploy?

A first release scoped to a few core domains typically takes weeks rather than quarters, depending on data quality and access. Unolabs targets 8 to 12 weeks for its consumer goods accelerator and 10 to 14 weeks for its utilities accelerator. Extending a template across the full estate and every business unit is multi-quarter work.

#Why do utilities data models use the IEC CIM?

The Common Information Model, published as IEC 61970 and IEC 61968, gives utilities a shared, vendor-neutral way to describe network assets, topology and distribution operations. A data model aligned to it can map systems from different vendors to the same entities, so analytics and reporting survive changes to SCADA, GIS or outage-management software.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing whether to start from a template, a blueprint or a custom model, book a discovery call and we will work through it with you.