Enterprise architecture, part 2: business and applications, fitted to the job

Part 1 drew enterprise architecture as four layers. This part covers the top two, business and application. They answer the question people in a factory ask most: "which systems should we have, and what should each one be like?"

Business layer: separate "what" from "how"

Business architecture is the organization's formal blueprint. It shows two things that need to be kept apart:

• Capabilities: what the organization does, such as planning production or controlling quality.
• Processes: how it uses those capabilities, such as receiving the plan at the machine, scanning the lot and recording the result.

This split helps me a lot with managers. Capabilities change slowly; the plant will still be planning production years from now. Processes change whenever a new machine or customer arrives. Systems designed around capabilities last, while screens and steps inside the app follow the process.

The course makes a point that matches my experience: business architecture is about clarity and transparency of the work, not financial figures. Once the work is clear, where to invest becomes obvious.

Four things decide whether this layer succeeds: management sees its value and takes part, the goal and scope are clear, real people and time are assigned, and every stakeholder group is considered. The third is the one most often skipped. If department heads have to do it on top of their normal job, with nothing taken off their plate, the work stalls halfway.

Application layer: five design activities

The course follows the Microsoft Application Architecture Guide, which splits design into five activities that repeat:

1. Set the goals for this round of design and when it should be done.
2. Pick the key scenarios, the ones where failure means the system has failed.
3. Draw the application overview: which type of app and which architectural style.
4. Find the hot spots where designs usually go wrong, such as authentication, error handling and connectivity.
5. Propose candidate solutions and test them against the scenarios from step 2.

In a factory, a good scenario for step 2 looks like this: "An operator at the machine, gloves dirty, Wi-Fi gone, still has to record the result." That one scenario rules out most of the options that would not work.

User, business, system: find the balance

A good design looks at three sides at once. Users want convenience, the business wants correct and timely data, and the people running the system want it easy to maintain and affordable. These often pull against each other.

The course's example is responsiveness. Users want 100%, but the hardware to deliver that may not pay off, so the balance might be 80%. The same thing comes up on the factory floor: supervisors want to see every field, while operators at the machine need only a few buttons. Separate screens for each group usually solve it.

Choose the app type for the place it is used

The course lists five application types. I added a last column with the factory jobs where I use each one.

Type	Strength	Used in the plant for
Mobile app	Works with on-and-off connections and on limited devices	Recording output at the machine, stock counts, label printing
Rich client	Uses the local machine, no constant connection needed	Stations wired directly to a machine or scale
Rich internet app	Heavy graphics and media, runs in the browser	Line status boards on a TV
Service	Called by other systems; parts can be separated	Central master-data API, the production scheduler
Web application	Any browser; runs on the server; needs a connection	Office work, approvals, reports

The mistake I see most is choosing a web app for work at the machine because it is the easiest to build, then finding it fails every time the plant Wi-Fi drops. That is why my research produced an Android app that works offline and sends its data once it is back online.

Architectural styles that come up often

The course summarizes nine styles. In practice I combine a few:

• Layered: screens, logic and data kept apart, so changing one layer does not break another.
• Service-oriented (SOA): each job is a service other systems call through an API, such as a machine-data service.
• Message bus: for data from devices, such as MQTT on my farm; the sender does not need to know who is listening.

Evaluate before building

Before building, test the design with the use cases that matter most to success, and with quality scenarios such as "200 people using it at once". The course names formal methods such as ATAM and SAAM. In a mid-sized plant I use something simpler: write 5–10 scenarios on paper and ask whether the design handles every one.

For anyone about to start

1. Write down the plant's capabilities first, no more than 10–15, then go into processes.
2. Use the hardest scenario on the floor as the test for the design.
3. Choose the app type for the actual place and network, not for the development team's comfort.
4. Split screens by group of people; do not give everyone everything.

Part 3 is the topic I think matters most in the whole series: data architecture, why a plant needs one set of master data, and why each set needs an owner on the business side.

References

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

Meier, J. D., et al. (2008). Application Architecture Guide 2.0: Designing Applications on the .NET Platform. Microsoft Patterns & Practices. (Cited in the source above.)

This article is my own summary and interpretation from practice. The drawings are new.