Practical guidance · Prime Arch ·
Same machine part, new carrier – from a concrete flow to traceable information
A machine part arrives in a transport box. It is received, inspected and transferred to an assembly cart. The box is emptied and restored for its next journey.
For the people doing the work, this is a concrete sequence of events. For an information architect, it raises several questions: Are received machine part and transferred machine part two different information objects? What do we need to know about the box once it is empty? And how can we establish afterwards which cart received the part?
Prime Arch helps us describe the same business logic from two perspectives: what the business actually handles, and what information it needs. GS1 traceability standards provide a complementary reference language for events and relationships over time.
Start with what the business recognises
Our example is a fictional logistics centre preparing machine parts for assembly. Each part, transport box and assembly cart can be identified. This lets us follow the particular part and carriers involved.
The service transfers a machine part to an assembly cart. To deliver it, the business needs to receive the part, position and open the box, inspect the part, approve the transfer and carry it out. Two paths continue afterwards: the part moves towards assembly, while the empty box proceeds to inspection and restoration.
Both paths matter. A description that stops at the part’s new location loses the work needed to manage the reusable carrier.
Fictional example. Read the flows from left to right. Open the image separately to see the details.
One service flow, two perspectives
A Service Flow Model, TFM, can show what the components of a service receive and deliver. A Service Component, T41, describes part of the business logic needed to deliver the service.
We start with concrete inputs and results. In Prime Arch these are Artefacts, I42. An artefact need not be a document: it can also be a tangible thing that matters in the flow. Here, the machine part in its transport box is a concrete input, while the inspection result and transfer decision are other significant results.
We then describe the information needs using Information Objects, I31. We ask what information the next component needs, independently of today’s form, screen or document format. The linked metaobject pages are in Swedish.
| Perspective in the example | What does it describe? | Input and output in TFM |
|---|---|---|
| AS-IS: concrete realisation | The inputs and results actually handled. | I42 is input for T41; T41 has output I42. |
| TO-BE: information needs | The information needed and passed on. | I31 is input for T41; T41 has output I31. |
AS-IS and TO-BE define the scope of these examples. They do not mean that I42 may only be used for a current state or I31 only for a target state. The same T41 can be examined from both perspectives.
Normalise the description without losing the real distinctions
Here, normalisation means an analytical task: separating stable information needs from status words, document names and temporary circumstances. It is not database normalisation, nor an automatic change of object type from I42 to I31.
One artefact may reveal several information needs. Conversely, the same information need may recur across several artefacts. Start with four questions.
1. Is this the same object in a new state?
Received machine part, inspected machine part and transferred machine part may refer to the same identified part. The status words alone do not justify three different information objects.
A candidate is Machine Part, with the status information and history the business needs. If identity actually changes, for example through processing that creates a new product, that requires a separate analysis.
2. Is there a separate carrier or assembly of objects?
The transport box and assembly cart have their own identities and life cycles. They need to be described even when empty.
Retain Transport Box and Assembly Cart as separate information candidates. Also describe which part is in each carrier. Moving a part does not mean that its box has ceased to exist.
3. Is there an inspection or decision that must be retained?
Inspected says less than an inspection result. Who performed the inspection? What was inspected? When did it happen, and what was the outcome?
Machine Part Inspection and Transfer Decision may therefore carry information value of their own. Test this against the need to use, review and follow up the information. Not every document needs to become a separate information object.
4. Do we need to know when a relationship began and ended?
After a transfer, the business may need to establish both where the part is now and where it was before.
In our example, the relationship between the part and its transport box ends. A relationship with the assembly cart begins. The Transfer needs to be linked to the correct part, previous carrier, new carrier and time. A single current-status field is insufficient if the history is needed.
Normalisation is the architect’s analysis between two perspectives. It is not a service component in the business flow.
Test the information needs against the next recipient
We can now return to the service components and ask what each one needs to know.
| Concrete input or result | Candidates for information needs |
|---|---|
| Received machine part in a transport box | Machine Part, Transport Box, Receipt and the relationship between part and box. |
| Inspection result for the part | Machine Part Inspection, referring to the part, time and outcome. |
| Decision to transfer the part | Transfer Decision, including conditions and a reference to its supporting information. |
| Machine part on an assembly cart | Machine Part, Assembly Cart and Transfer; the ended and newly established carrier relationships. |
| Empty transport box | The same Transport Box, its state and its ended relationship with the part. |
| Inspection result for the box | Box Inspection, supporting restoration and continued use. |
These are analytical candidates, not an established information model. They must be tested against the business’s language, responsibilities and uses.
For example, Approve transfer needs a relevant inspection result. Transfer machine part needs both the decision and information identifying the correct part and destination. An arrow between two steps therefore does not necessarily show all the information a step needs. Outstanding needs must be made visible, including information supplied by another part of the business.
The TO-BE perspective describes information needs. The names in the illustration are proposals to test, not a finished system design.
GS1 provides a reference language for traceability
GS1 develops standards for identifying objects and capturing and sharing information in supply chains. GS1 Sweden describes traceability in terms of following objects’ history, events and locations. This is a useful starting point for our example: we need to follow what has happened to the same machine part over time. GS1 Sweden: Traceability.
EPCIS is GS1’s standard for capturing and sharing event data within and across organisations. We use it here as a reference for analysis. GS1: EPCIS and CBV.
EPCIS groups event information around five questions: what, when, where, why and how. Here, “how” concerns conditions described through sensor data, rather than instructions for performing the work. The standard also includes AggregationEvent, which can describe identified contents being added to, removed from or observed within an aggregation. EPCIS, sections 7.2.2 and 7.4.3.
Applied to our fictional case, the questions become concrete:
- Which machine part and carriers were involved?
- When did the transfer take place?
- From which location and carrier was the part moved, and to which ones?
- Which assignment and decision provided the context for the transfer?
- Which observations need to accompany it, if temperature or impacts are relevant?
These questions are our application to the example. They do not, by themselves, determine which EPCIS event type or technical implementation should be chosen.
Distinguish the carrier from the logistics unit
GS1 describes a logistics unit as objects brought together for transport or storage, for example in a case or on a pallet. GS1: What is a Logistics Unit?.
In our analysis, we need to distinguish the reusable box, its contents and the combination handled together. They may have different identities and change at different times. We therefore do not prescribe a particular GS1 identifier for the box, cart or machine part. Identification choices and any adoption of EPCIS are separate architecture decisions.
What the architect gains
The method produces three connected results: a concrete flow the business recognises, tested information needs for each service component, and a traceable connection between those two descriptions.
The test is practical: Can the next recipient do their work with the information passed on? Can we follow the same object as its state and carrier change? Can an inspection or decision be understood afterwards?
Once this works, we can examine which business logic is reusable. Inspect machine part, for example, can inform an analysis of the ability to inspect an object. This is a new modelling step that requires its own decisions about scope and level, not a mechanical renaming of the service component.
Start with what the business handles. Then free the information needs from today’s solution while retaining the connection back to it. The architecture can then change without losing what the business needs to do and trace.