Shared waters

Composing open systems

Open systems emblem with the floating-power scenario as its stamp

Familiar waters.
Open systems.

An offshore depot needs power. A floating SMR barge could supply it. But the service also depends on people, information, access and several organisations.

Design and installation can agree on the power-link specification and still book the same team for the same slot. Try that distinction first: what must agree, and what cannot be shared?

Try agreeing versions and a double-booked team →
An SMR barge powers an offshore depot, with an operator, customer and marine provider linked above them.

Three different questions

What changes when we put the parts together?

Try a shared observation, a joined boundary or an organisational comparison. Each uses a different construction; none derives a complete delivery plan.

01

Join at a boundary

Two local diagrams name the same handover. Identify that interface and see the composed graph.

From the open-graphs drawing.

Explore joining →
02

Compare an organisation

Make the current and intended arrangement visible. Separate what stays, what changes and what is added.

From the BAU / TOM drawing.

Explore the comparison →
03

Make sharing explicit

Leave all versions at A, then let installation request the team too. Agreement survives; the capacity rule fails.

From the open-process drawing.

Explore the interfaces →
The three source drawings and the wider question

Each trial reconstructs one of Lawrence’s 2022 GraphML attempts, retaining what holds up or can be corrected directly. The original drawings and the reasoning behind each correction remain linked from the individual trials.

The wider question is what open-system composition helps us define: work, capability, scope, resources or services. Deriving useful project work remains an ambition, not a result of these three constructions.

Sources, corrected meanings and unresolved claims →

The organisational part matters

More than equipment.

The depot customer expresses a need. The operator offers a service. Designers and procurers coordinate a specification. A marine provider supplies access. These parties can retain their own internal workings while exposing an interface to others.

“Design” names a process; “a design capability” names what an organisation can do; “an approved specification” records a decision about a particular version. A useful boundary keeps those meanings distinct.

How to read these attempts

  1. Start with the concrete situation.
  2. Look at the actual structure being used.
  3. Change one thing and read the consequence.
  4. Open the source note to see what was retained, corrected or left unresolved.

No attempt needs to solve the whole project. A clear distinction can be a useful result.

Read the End, methods and sources →