Interpreting an architecture

Work in progress

This page is a work in progress. Content may change or be incomplete.

The scenario

Context

A regulated company must give its change board an impact analysis before the payload of an event changes.

What happens

Without ASL the agent reads a diagram drawn for the last audit and still has to read the code of every service to confirm it.

How ASL helps?

With ASL, it reads the system architecture. The company syncs ASL manifests on every CI/CD change, so the analysis reflects the current state and can be traced as evidence.

Today: Markdown as the harness

agent

> The change board needs the impact analysis for changing the payment-events payload.

● Read(architecture-review-q1.drawio)

⎿ architecture-review-q1.drawio · several KB of XML, arrows without a type

<mxCell id="9" value="tokenizer" style="rounded=1;fillColor=#dae8fc;" vertex="1" parent="1">
<mxCell id="14" style="endArrow=classic;html=1;" edge="1" parent="1" source="9" target="12"/>
<mxCell id="12" value="ledger-service" style="rounded=1;fillColor=#d5e8d4;" vertex="1" parent="1">

● The diagram shows tokenizer → ledger-service, drawn for the Q1 review. It does not say if the arrow is an event or a call, and it is 8 months old. To be sure I would have to read the code of every service. Provisional impact: ledger-service.

An analysis with gaps: fraud-scoring joined after the diagram. The board cannot approve what it cannot trace.

Architecture as Code with ASL

agent

> The change board needs the impact analysis for changing the payment-events payload.

● Read(architecture/payments.asl.yaml)

⎿ ~2.6 KB of YAML, typed relations

- from: {kind: Application, name: tokenizer}
  to: {kind: Topic, name: payment-events}
  type: produces
- from: {kind: Application, name: ledger-service}
  to: {kind: Topic, name: payment-events}
  type: consumes
- from: {kind: Application, name: fraud-scoring}
  to: {kind: Topic, name: payment-events}
  type: consumes

● payment-events is produced by tokenizer and consumed by ledger-service (team-ledger) and fraud-scoring (team-risk). It carries tokens, not card data: nothing labeled pci touches it, so no PCI review. The company syncs ASL manifests with every CI/CD change, so this is the current state.

An analysis the board can trace back to the manifests.