Skip to content
Pisarn BoonnukภาษาไทยGet in touch

Enterprise architecture, part 3: master data in one place, with an owner

Data management principles, TOGAF, DMBOK and COBIT, the enterprise data model, hybrid data placement, and five starting steps for a factory.

Published

Subject areasProductionQualityWarehouseMachinesConceptualLotWork orderMachineEmployeeLogicalAll fieldsRelationshipsKeysSupporting rulesData ownersStandard codesQuality rulesLife cycles

If a factory could do only one layer of enterprise architecture first, I would pick data. Apps can change and technology can change, but if three systems use three different codes for the same machine, every report built on that data is wrong too.

Before: every system has its own machine codeMESM-01MaintenanceMachine 1ReportsLine1-ANumbers cannot be joined; someone matches them by hand every monthAfter: one master record with a clear ownerMachine registerowner: engineeringCentral APIsends one codeMES, maintenance,reports share it

Data is an asset, and assets need owners

The course treats data as an organizational asset that needs the same care as machines and raw material, with responsibility shared between data owners on the business side and specialists on the IT side. Managing data is therefore a business job, not a job for IT alone.

Data as a by-productNobody owns itEach system edits its own copyBroad access by defaultNo one knows if it is rightData as an assetEvery set has a business ownerFixed once, at the sourceRole-based access, loggedData quality measured

Data ownership is what most plants are still missing. The machine register should belong to engineering. Product codes should belong to planning or sales. IT makes sure systems store and pass the data on correctly, but should not be the one deciding which code is right.

Start with data governance

The course compares three standards: TOGAF for the architecture as a whole, DMBOK for the detail of each area of data management, and COBIT for IT governance. They overlap at data governance, so that is where I suggest a plant starts, without waiting to adopt any standard in full.

Define what the business cares about before designing the database

Data architecture says which data the organization needs, where it comes from, and makes sure everyone means the same thing by it. The point I find most important: do not think about database tables yet. Define what the business cares about first, such as lots, work orders, machines and employees.

The TOGAF way is to describe the data as it is and as it should be, find the gap between the two, and plan to close it in stages, with a formal review with the people involved before it is finalized.

The enterprise data model (the drawing at the top of this article) goes from broad to detailed: the big topics (production, quality, warehouse), what the business cares about and how it relates (one work order has several lots), and every field. The bottom layer is the supporting rules: who looks after the data, the allowed codes, quality rules and the life cycle of each record.

That bottom layer is often forgotten, yet it is the part used every day. A lot's life cycle might be: released → running → on hold for inspection → complete → passed on. If every system uses the same states, the work-in-progress report matches on every screen.

Where to keep the data

The course notes that current designs are hybrid: sensitive data stays inside the organization, less sensitive data can live outside, because keeping everything in-house has a cost.

I use this rule on the farm and in the factory. At Baan Rak Phak, raw readings every 10 seconds stay on the edge computer at home, and the cloud keeps only what needs to be seen from outside. In the factory, production data stays on internal servers and the AI runs on internal machines.

Five starting steps in a factory

  1. List the master data that several systems share, usually no more than ten topics, such as machines, products, processes, employees and customers.
  2. Name an owner for each topic, as a person or a position, not a department.
  3. Fix data in one place, at the source. Other systems read it through an API or on a schedule.
  4. Measure data quality as numbers, such as codes missing from the register, and report them monthly.
  5. Migrate from old systems one data set at a time, checking quality before and after.

My research on sequencing work orders with Random Forest started from almost 18 million rows, and about 4 million remained after removing incomplete or abnormal rows. Cleaning was the heaviest part of the project. With data rules in place at the source, that part gets much lighter.

Part 4 covers the technology layer, change management and governance, with a first-year plan for a factory.

References

ดนัยรัฐ ธนบดีธรรมจารี and วรัญญา ปุณณวัฒน์. (2022). Enterprise architecture design [in Thai]. In Strategic Digital Technology Management. Sukhothai Thammathirat Open University Press. ISBN 978-616-16-2818-5

DAMA International. DAMA-DMBOK: Data Management Body of Knowledge. https://www.dama.org

The Open Group. The TOGAF Standard. https://www.opengroup.org/togaf

This article is my own summary and interpretation from practice. The drawings are new, and the machine-code example is illustrative, not company data.

Back to home