DSLCore
Menu

How networks work

An application does one job well. The trouble starts between applications: a result in one place has to become an order in another, a promise has to be checked by someone independent, a cost has to reach the ledger. Today that usually happens by email, by re-typing, or by a person remembering.

A network is a group of separate applications that cooperate, so that work crossing from one to another is carried out, recorded and checked. Each application keeps its own job, its own data and its own rules. What the network adds is the communication between them, and someone watching over it.

How applications talk to each other

The applications do not share a database and do not reach into each other. They talk in three simple ways, all over ordinary web requests:

  • Ask. One application asks another a question and gets an answer: where does this part stand? (a request for information, like a web GET).
  • Tell, or request. One application sends another a message: please raise this order, or this has happened (a message sent to the other application, like a web PUT).
  • Trigger. When something changes in an application — a record is created, a status moves — it announces that fact by itself, without being asked, and every application that cares hears about it.

Every message has the same simple envelope: what kind it is, who sent it, who it is for, which piece of work it belongs to, and its content. Because the envelope is the same everywhere, it does not matter what is on either side of it.

What watches over the network

Two kinds of application make the network accountable.

  • The orchestrator carries every message to the applications that need it — a little like a post office. It tries again when one is down, sets aside anything that cannot be delivered, and keeps a record of what was sent, to whom, and what came back.
  • Assurance applications decide what matters. They watch what happens and turn it into something a person is accountable for: an exception with an owner, a decision, an obligation with a date, an independent check, and a view for management of where each thing stands and why.

Applications from other vendors

Because the connection is only web requests carrying a standard envelope, applications from other vendors can be integrated into a network alongside DSLCore’s own. Any system that can send and receive those requests can take part, directly or through a small adapter that translates its own formats into the network’s. Each member of a network also publishes a short description of what it owns, what it announces, what it listens for and what it can be asked, so a new member can be checked against the others before it joins.

An honest note on where we are: so far the members are DSLCore reference applications, and the finance system in the Work & Supply Network is a simulator, not a connection to a real one. The design allows other vendors’ applications to join; we have not yet connected a real third-party product.

Why it matters in practice

  • Work crossing from one application to another happens without anyone re-typing it.
  • Every step leaves a record that shows who knew what, who decided, and who checked.
  • A claim is not a result: something marked “done” can be sent for an independent check before it closes.
  • When something goes wrong — a system is down, a check fails, a date is missed — the network handles it and shows it, instead of it disappearing.
  • Each application can change, or be replaced, without the others being rebuilt, as long as it keeps its side of the agreement.

Where this is going

Networks will grow to cover most of the standalone applications already built. They will follow the main groupings of the reference applications — mining, government and infrastructure, oil and gas, in-house counsel, solar and renewables, shipping and ports, and mineral exploration — so that applications that share work are connected into a network of their own.

Two networks exist today. The others are planned, not built. As more are added we will show more examples of how applications communicate, and how governance works in practice: how exceptions, decisions, obligations and independent checks behave when the work is real. The recorded simulations on this site are the start of that library.

Choose a network

Each network shows one idea. Start with the story, then watch it happen.

See all networks