Enterprise architecture, part 4: technology, change and governance

The first three parts were about drawing the blueprint. This part is about what keeps the blueprint in use two years from now instead of forgotten after the first meeting: the technology layer, change management and governance.

Technology layer: share as much as possible

TOGAF splits technology into layers. At the top are applications: business applications specific to the organization, such as MES and warehouse systems, and infrastructure applications everyone uses, such as email and single sign-on (SSO). Below them are the platform services applications call, such as databases, security and monitoring, and at the bottom the network that connects it all.

The point that applies right away is purchasing. Without a technology architecture to guide it, each project buys its own database, backup system and monitoring tools, even though they could be shared. The course calls these shareable pieces "building blocks", and notes that an application used widely enough turns into infrastructure. SSO is a clear case: it often starts with a few systems and ends up as something every new system has to connect to.

Change management and governance

Once a blueprint exists, three jobs continue: build awareness so people see its value, monitor changes in technology, customers and regulations, and manage risk. Every change request takes the same loop: check it against the blueprint, let the architecture team decide, build it, then review it after use. The course admits that deciding whether a change only updates the blueprint or needs a new design cycle is hard to pin down; the threshold becomes clearer after a few rounds.

The main tool is the architecture contract, an agreement between the architecture team and the team doing the work. The course lists five things every project should state. I recommend using them as the first page of every project.

Heading	Example: moving a form to mobile
Name and purpose	Record production output on mobile instead of paper, so data reaches the supervisor within the shift
Scope and limits	One production line; the app works offline; uses the central machine register
How success is measured	Time for data to reach the supervisor; corrections per week
Acceptance conditions	Run beside paper for two weeks with matching numbers, then retire paper
Risks	Weak Wi-Fi in some spots; night-shift staff not yet trained

Changing the organization so the blueprint is used

The course's principles are sound but need scaling down for a mid-sized plant. My five recommendations:

1. Form a small architecture team of three to five people from production, engineering and IT, meeting once a month.
2. Write the principles on one page, for example "master data is fixed at the source, in one place" and "work at the machine must run offline". I wrote my own principles down as the jk framework and use them on every system I build.
3. Require the first-page table above for every new project before the budget is approved.
4. Review the blueprint every quarter; just color each box as new, changed or retired.
5. Pair quick wins with foundation work, as in the first-year plan above. People on the floor believe when their own work gets easier; managers believe when they see numbers.

The course cites MIT's enterprise architecture guide, whose current-state survey took 22 interviews with 25 representatives and 4 workshops. Even in a large organization, most of enterprise architecture is talking to people, not drawing diagrams.

The series in brief

• Part 1: enterprise architecture is a four-layer map that keeps business and IT pointed the same way.
• Part 2: design apps around capabilities and the real situations on the floor.
• Part 3: master data lives in one place and has a business owner.
• Part 4: share the technology, and have someone look after the blueprint every quarter.
• Part 5: hands-on, building the blueprint with the Design & Track worksheet.

If you can start only one thing this month, fill in the current-state survey table from part 1 for one production line. It will show you what to do next.

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: Technical Reference Model. https://www.opengroup.org/togaf

Sapient. (2004). The MIT Enterprise Architecture Guide. Massachusetts Institute of Technology. (Cited in the first source.)

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