Data as a strategic asset: governance, quality and architecture

Dr. Marchetti begins the fourth session by asking a simple question about Cedarline: how many customers does it have? The cohort has seen Cedarline's financial statements, its store list and its online sales, and nobody can answer. The store tills record about 1.9 million transactions a year, many of them without a customer name. The web shop has 640,000 accounts, some of them duplicates and many inactive. The repair desk keeps its own list of about 85,000 people who have sent in gear. The loyalty program, launched three years ago, has 310,000 members, who may or may not also have web accounts. Cedarline's marketing team estimates somewhere between 700,000 and 1.1 million distinct active customers, which is the same as saying it does not know.

The question matters because almost everything in Cedarline's strategy depends on the answer. A repair membership needs to know who owns which product. A resale marketplace needs to know where a used item came from and what was done to it. A single view of inventory needs product codes that mean the same thing in the design system, the warehouse, the stores and the website. Personalized offers need a single record of each customer's purchases across channels. This lesson treats data as a strategic asset: something that can create advantage if it is accurate, connected and governed, and that is worth little or even harmful if it is not.

What makes data an asset

Data differ from most assets in a few ways that matter for strategy. They are non-rival: many people and systems can use the same data at once without using them up. Their value usually comes from combination, because a purchase record is modestly useful on its own but much more useful when linked to the customer's repairs, returns and responses to marketing. They decay, because customers move, products change and records go stale. And their value depends on use: a data set that no one uses for a decision has no value at all, however large it is.

Barbara Wixom and Jeanne Ross of the MIT Center for Information Systems Research distinguished three ways firms earn value from data. Improving uses data to make operations and decisions better, as when a retailer uses sales data to allocate stock. Wrapping adds data and analytics to an existing product to make it more valuable to customers, as when a bank adds spending insights to its app. Selling offers data or information products to others, such as Fairway's retail media business or Kestrel's aggregated forecasts for suppliers. Their research suggests that most firms should start with improving and wrapping, because selling requires capabilities and legal care that few firms have, and because the internal uses usually create more value.

Data can also become a source of competitive advantage, but less often than is claimed. The argument that more data lead to better products, which attract more users, who generate more data, sounds like a network effect. Andrei Hagiu and Julian Wright, in a 2020 Harvard Business Review article, argued that such data-enabled learning creates a lasting advantage only in particular conditions: when the value added by customer data is high and lasts, when the data are proprietary, when improvements from the data are hard to copy, and when the learning continues rather than reaching a plateau after a modest amount of data. In many applications the value of extra data falls quickly, and rivals can buy similar data or train on public sources.

For Cedarline, the data that pass this test are the product-life records its strategy would create: which products last, how they fail, what repairs cost and what used gear sells for. No rival has them, they improve design and pricing over time, and they are hard to copy because they depend on Cedarline's repair workshops and customer relationships. Its general sales and web data, by contrast, are useful for running the business but give no special advantage.

Data governance

Data governance is the set of decision rights, roles, policies and processes that determine how an organization's data are defined, collected, stored, protected and used. It sounds bureaucratic, and badly designed governance is. But without it, each system and team defines a customer, a product or a sale in its own way, and nobody is responsible for fixing errors. The DAMA Data Management Body of Knowledge, a widely used professional reference, describes governance alongside data architecture, modelling, storage, security, integration, quality, master data and metadata.

Dr. Marchetti recommends a light structure that most organizations can adopt. Each major data domain, such as customer, product, inventory, sales and repairs, has a data owner, a senior business leader accountable for the domain's definitions, quality and use. Data stewards, usually experienced staff within the business, maintain the definitions and resolve quality problems day to day. A small central data office sets common standards, runs the shared tools and keeps a catalogue of data sets and their meanings. A council of data owners meets regularly to settle disputes and set priorities. The key word is owner: someone in the business, not the IT department, must care whether the customer data are right.

Master data management is the part of governance concerned with the core entities that the whole business shares, chiefly customers, products, locations and suppliers. Its aim is a single trusted record for each, often called a golden record, built by matching and merging records from different systems and kept up to date as those systems change. For Cedarline, the two master data problems are a customer identity that links tills, web accounts, loyalty members and repair customers, and a product identity that follows each item from the design system through manufacturing to stores, repairs and resale.

Data quality

Data quality is usually described along several dimensions. Completeness asks whether required values are present. Validity asks whether values follow the expected format and rules. Accuracy asks whether values are true, which often requires checking against the real world. Uniqueness asks whether each entity is recorded once. Consistency asks whether the same fact is recorded the same way in different systems. Timeliness asks whether data are current enough for their use. Different uses need different levels: a monthly sales report can tolerate a few missing records, while a ship-from-store system that promises a customer a jacket in a particular store cannot tolerate wrong stock counts.

Dr. Marchetti shows the cohort a sample of Cedarline customer records drawn from three systems and asks them to score it.

import re
from datetime import date
# A sample of Cedarline customer records from three systems (store tills, web shop, repair desk)
rows = [
    {"id": "C1001", "email": "amira.k@example.com", "postal": "M5V 2T6", "last_seen": date(2026, 9, 14), "source": "web"},
    {"id": "C1002", "email": "",                    "postal": "M4C 1B5", "last_seen": date(2026, 2, 3),  "source": "store"},
    {"id": "C1003", "email": "j.ross@example",      "postal": "L4Z1X9",  "last_seen": date(2025, 11, 20), "source": "store"},
    {"id": "C1004", "email": "amira.k@example.com", "postal": "M5V 2T6", "last_seen": date(2026, 10, 1), "source": "repair"},
    {"id": "C1005", "email": "pat.lee@example.com", "postal": "",        "last_seen": date(2024, 6, 30), "source": "store"},
    {"id": "C1006", "email": "sam.o@example.com",   "postal": "K1P 5J2", "last_seen": date(2026, 10, 12), "source": "web"},
]
today = date(2026, 11, 2)
email_ok = re.compile(r"[^@\s]+@[^@\s]+\.[a-z]{2,}")
postal_ok = re.compile(r"[A-Z]\d[A-Z] \d[A-Z]\d")
n = len(rows)
complete = sum(1 for r in rows if r["email"] and r["postal"]) / n
valid = sum(1 for r in rows if email_ok.fullmatch(r["email"]) and postal_ok.fullmatch(r["postal"])) / n
emails = [r["email"] for r in rows if r["email"]]
unique = len(set(emails)) / len(emails)
timely = sum(1 for r in rows if (today - r["last_seen"]).days <= 365) / n
scores = {"completeness": complete, "validity": valid, "uniqueness": unique, "timeliness": timely}
for k, v in scores.items():
    print(f"{k:12s} {v:.0%}")
print(f"overall (simple mean) {sum(scores.values()) / len(scores):.0%}")
dupes = {e for e in emails if emails.count(e) > 1}
print("probable duplicate customers:", [r["id"] for r in rows if r["email"] in dupes])

completeness 67%
validity     50%
uniqueness   80%
timeliness   83%
overall (simple mean) 70%
probable duplicate customers: ['C1001', 'C1004']

Only two thirds of the sample records are complete, half are valid, a fifth of the email addresses are duplicates, and one in six records has not been seen in more than a year. The simple average of 70 per cent sounds tolerable, but it hides the problem. Customer C1001, who bought online, and customer C1004, who sent in a repair, are probably the same person, Amira K., recorded twice; if Cedarline offered her a repair membership by email, its records would not know that she is already a repair customer. Customer C1003 has a mistyped email and a postal code without a space, so neither marketing nor shipping can rely on the record. These are not exotic problems; they are what most retailers find when they first look.

Quality improves mainly at the point of capture rather than through later cleanup. Store tills that look up a customer by phone number or email before creating a new record, web forms that validate postal codes as they are typed, and repair desks that scan a product code rather than writing it by hand prevent most errors. Cleanup is still needed for the existing records, often through matching software that compares names, addresses, emails and phone numbers and proposes merges for a person to review. And quality needs measuring continuously, with the data owner seeing a short set of scores each month, because data that are cleaned once and then neglected decay within a year or two.

Data architecture

Architecture describes how data move from the systems that create them to the people and applications that use them. For decades the dominant pattern was the data warehouse, a central database designed for reporting and analysis, into which data from operational systems were copied each night after being cleaned and reshaped. Bill Inmon and Ralph Kimball, who wrote the most influential books on warehouse design from the 1990s onward, disagreed about whether to build one integrated enterprise model first or a set of subject-specific data marts, but both assumed structured data and planned reports.

In the 2010s, as firms collected large volumes of semi-structured and unstructured data, such as web clickstreams, sensor readings, images and text, many built data lakes: large, inexpensive stores, usually in the cloud, where raw data could be kept in any format and processed later. Lakes were flexible but often became swamps, full of data that nobody could find, trust or understand. The lakehouse architecture, which became common in the early 2020s, combines a lake's inexpensive storage of all data types with the management features of a warehouse, such as tables with defined structures, transactions and access controls, so that the same data can serve both reporting and machine learning.

Architecture is also about organization. Zhamak Dehghani, writing from 2019 onward, proposed the data mesh, in which business domains own and publish their data as products for others to use, under common standards and a shared self-service platform, instead of sending everything to a central data team that becomes a bottleneck. The idea has been influential, though many firms find that it needs more data skills in the business than they have. Dr. Marchetti's advice for a company of Cedarline's size is pragmatic: a single cloud lakehouse run by a small central team, with business owners for each data domain, a shared catalogue, and a few well-defined data products, such as a customer table and a product-life table, that everyone uses.

A practical point about real time deserves emphasis. A nightly copy is fine for a sales report, but a ship-from-store promise or an inventory number on a product page needs data that are seconds or minutes old. Systems that stream events, such as a sale, a return or a stock transfer, as they happen allow those uses. They cost more and are harder to run, so they should be reserved for the decisions that need them.

Privacy, consent and responsible use

Customer data come with legal obligations and with the customer's trust, which is worth more than any data set. In Canada, the Personal Information Protection and Electronic Documents Act, known as PIPEDA, governs how private-sector organizations collect, use and disclose personal information in commercial activities, based on principles such as consent, limiting collection to what is needed, and safeguarding information. Quebec's Law 25, which took effect in stages from 2022 to 2024, added stronger requirements in that province, including privacy impact assessments, rules on automated decisions and significant penalties. A federal bill to replace PIPEDA, Bill C-27, died when Parliament was prorogued in January 2025; a new bill, Bill C-36, the Protecting Privacy and Consumer Data Act, was tabled in June 2026 and was still before Parliament in the fall. Cedarline should design its customer data program to meet the stricter of these standards, because it operates across provinces.

Beyond the law, Dr. Marchetti offers three principles. Collect what you will use, and explain why: a customer who registers a jacket for lifetime repairs understands why Cedarline needs her name and the product's serial number, but may not understand why it wants her date of birth. Separate identity from analysis: most analysis can be done on records where names and contact details have been replaced by codes, with access to identities restricted to those who need them. And keep a record of consent and purpose, so that data collected for repairs are not used for unrelated marketing without permission. These practices reduce legal risk, but their main value is that they keep customers willing to share.