Enterprise architecture, part 1: a map so factory systems stop growing apart

Most factories do not lack systems. They have so many that nobody sees the whole. Production runs its own program, the warehouse another, maintenance lives in Excel, and someone assembles the management report by hand at the end of every month. Enterprise architecture (EA) is a way to draw a map of all of this, then use the map to decide what to build, buy, connect or retire.

This five-part series summarizes a course in strategic digital technology management from my master's degree, and shows how I have applied each part in a factory. This first part is the overview.

The problem enterprise architecture solves

The textbooks call it IT silos: systems built by people working alone. The symptoms I have seen on the shop floor match the textbook list almost point for point.

• Departments report different numbers for the same thing, because they read from different systems.
• The same data is keyed into several places, so it is error-prone and later than decision makers need.
• A new system arrives and turns out to duplicate an old one.
• IT becomes the bottleneck and every request waits in a queue.

Enterprise architecture fixes this by lining up what the business wants with how IT is used. The tangible result is an enterprise blueprint, a map and plan for the digital transformation.

Four layers to look at together

Enterprise architecture has two sides. Business leads; IT follows.

Layer	Question it answers	Factory example
Business	What do we need, who does it, how?	On-time delivery goal, department structure, steps from plan to shipment
Application	Which software supports each step?	MES on web and mobile, warehouse system, repair requests
Data	What data, where, and who owns it?	Lot numbers, work orders, the machine register
Technology	What does it run on and how is it connected?	Servers, the plant network, backups

All four layers sit inside change management and governance, the part that keeps the blueprint from being drawn once and filed away. Part 4 covers it.

The idea I like most here: technology does not have to cover every step. If a job has 20 steps, it may pay to support only the first five and leave the rest until they are ready.

The four steps

1. Study the vision, mission, values and structure to see the whole before going into detail.
2. Survey the current state (as-is): which jobs exist, who owns them, which apps they use, where the data lives and what goes wrong.
3. Design the target state (to-be): a list of all solutions and a blueprint that shows core and supporting work, infrastructure and every application on one page.
4. Summarize, present and keep improving: project documents with scope, timeline, expected results and the technology standards involved.

The survey table: the tool I use most

Step 2 uses a business and IT alignment worksheet, one row per job. I adapt the columns for a factory like this:

Job	Goal	Owner	System used	Data used	Problems and needs
Record production output	Know output within the shift	Production	Paper form, keyed in later	Lot, machine, quantity	Data a day late, frequent typos
Report a machine breakdown	Fast repair	Maintenance	Phone and logbook	Machine code, symptom	No history, repeat faults go unnoticed
Issue spare parts	Enough stock, none stuck	Warehouse	Old stock system	Part code, quantity	Machine codes differ from the repair records

Even three rows point to the next work. The first row is the form to move to mobile first. Rows two and three show the plant needs one shared machine register that every system uses. Part 3 picks this up.

The course estimates 25–35 design sheets of this kind for a typical organization; each one becomes a box on the blueprint.

What I learned using it

• Start from the business every time. Whenever I jumped to systems first, the work came back to "so what does the plant need?"
• Fill in the survey on the floor. Answers in a meeting room and what people actually do at the machine rarely match.
• A one-page blueprint works better with management than a 50-page document. Managers want to see what to invest in first and what it buys.
• You do not have to cover the whole organization in round one. Pick one line or one process, show results, then widen.

Part 2 goes into the business and application layers: how to choose the right kind of app for the job, and why work at the machine should be a mobile app that keeps working on a weak signal.

References

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

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 example table is illustrative, not company data.