Architecture and integration decisions

An architecture decision needs a specific subject

Talbahn compares two integration offers for its diagnostic application. Offer A bundles several functions on one platform; offer B distributes them across components. Neither is better for that reason alone. The architecture decision concerns the required exchange, its boundaries and lifecycle changes.

An architecture decision records the selected alternative and why it was chosen, including assumptions, consequences and open issues. Interface responsibility identifies who specifies and implements boundary behaviour and investigates faults. This remains necessary even when one supplier provides both sides.

From use case to comparison

Talbahn first reuses the partners and states from 2.22. It then draws applications, client functions, gateways, service platform and transport. Each alternative answers the same questions. The applicable application profile remains a constraint: a coupling type prescribed there is not a freely interchangeable design option. [S06; S10; S42]

A worked example

Offer A has a shared operations organisation and fewer organisational handovers. Talbahn sees a potential advantage for incident leadership. It must also check whether a platform update affects voice and diagnostics together. Offer B may allow separate change cycles but introduces additional interface coordination. These are consequences to verify for the implementation, not general judgements about suppliers.

The decision is therefore not “more components are safer”. It might be: “We choose the offered separation because independent diagnostic updates were demonstrated and the additional interface responsibility is assigned contractually and operationally.” Without that evidence, the claimed advantage would be an assumption.

How the decision will be checked

The case file includes a change scenario: replacing the trackside diagnostic application. Tests cover registration, existing and new sessions, address mapping, permissions and error feedback. A successful API request alone does not prove the full exchange. Rollback is the controlled return to the previously approved combination if specified criteria are violated.

Check your understanding

A supplier promises interchangeability because an interface is “open”. What additional information makes the promise testable?

Model answer

Identify the actual interface version, supported options, state and error behaviour, responsibilities and a replacement trial in the named combination. Open documentation assists integration but does not prove every replacement scenario. A return procedure limits the consequences of an unsuccessful change.

What to remember

Architecture quality depends on justified treatment of functions, dependencies and changes. A plausible diagram starts a decision; it does not prove it.

Your Talbahn case file

Write an architecture decision with the reason for change, two alternatives, selection, rationale, evidence and remaining assumption.