An ecosystem that grows with you

From one partnership to a network of organisations and providers, one relationship at a time, without anyone having to own the whole. Today that means organisations working together through agreed case roles; a commons that independent organisations run together is where we are heading.

Why ecosystems usually end up with one owner

Networks of organisations often end up either on one party’s platform, on its terms, or as a web of separate integrations where every new relationship is a new project. The first makes everyone dependent on one owner; the second doesn’t grow.

There are other ways: federated networks and open standards have long shown that working together doesn’t need a single owner. CaseFlows is one concrete way to do that for the work itself: autonomous organisations that work together through responsibilities they agree on, one case role at a time.

Who takes part, and how

Not everyone in the ecosystem takes part in the same way. There are three kinds of relationship:

Working in the case. The owner runs the case on its own platform. A partner holds a role in it. A customer or applicant takes part without a platform of their own.
Supplying capabilities. A service provider delivers data or a calculation that a role uses. It doesn’t hold a role; it is connected as a service.
Helping others build. An implementation partner helps an organisation describe its work and build its first caseflows. It works on the development environment, not in the running cases.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#FFFBF3","primaryBorderColor":"#211D18","primaryTextColor":"#211D18","lineColor":"#211D18","secondaryColor":"#FCE3D2","secondaryBorderColor":"#EC6A22","tertiaryColor":"#ffffff","tertiaryBorderColor":"#D9CFBE","clusterBkg":"#F5EFE4","clusterBorder":"#D9CFBE","fontFamily":"Instrument Sans, system-ui, sans-serif","fontSize":"15px"},"flowchart":{"padding":18,"nodeSpacing":40,"rankSpacing":45}}}%%
flowchart TB
  subgraph work["Working in the case"]
    direction LR
    O["Owner"] --- C["Case"]
    P["Partner<br/>holds a role"] --- C
    A["Customer or applicant"] --- C
  end
  subgraph support["Supporting the work"]
    direction LR
    S["Service provider<br/>data, calculations"]
    I["Implementation partner<br/>helps build"]
  end
  S -->|"a service a role uses"| work
  I -.->|"on the development environment"| work
  classDef now fill:#FCE3D2,stroke:#EC6A22,stroke-width:2px
  class C now

Scroll sideways to see the whole diagram.

Who needs a platform of their own

A customer or applicant: no. Taking part in a case is free.
A partner that holds a role: not necessarily. It can take part in your case through the role, without a platform of its own and at no cost.
A partner that wants to assign the role to its own people and manage it itself: yes, from its own CaseFlows platform.
An organisation that builds its own caseflows: yes, a platform with its own development environment.
A service provider: no; it is connected as a service.

Running your own platform is a subscription, and building your own caseflows is the higher one. During the private beta we agree the terms with each organisation before anything is committed.

It grows one relationship at a time

You don’t start with an ecosystem. You start with one case and one partner. The partner takes on a role, the two organisations agree what it may see and do, and the work runs.

The next partner is not a new integration project. Between CaseFlows platforms, handing a role to another organisation is an agreement both sides confirm, not code that has to be written. A second firm can take on the same role; a firm that already works for one organisation can take on a role for another. Each relationship is added on its own, and none of them changes the others. How two organisations work together on one case is told in Working across organisations.

Every connection can make the network more useful

An ecosystem is more than a set of connections. It becomes valuable when each new participant makes the next one easier.

A new partnership does more than connect two organisations. It can produce something others could reuse: a case role, a collaboration agreement, a connection to a service, a better way of organising the work. With the participants’ permission, those building blocks could become discoverable to others: a new partner wouldn’t have to invent its agreement from scratch, and a service provider one organisation connected could be found and used by the next, together with what others learned working with it.

That is how we want the ecosystem to grow: from actual work, one useful connection at a time. Today each relationship is set up on its own; a shared place where such building blocks can be found is our direction.

Each controls its own environment

Growing together doesn’t mean moving into one shared platform. Each organisation controls its own platform environment: its caseflows, its data, its services, its way of working. Those environments may run on shared infrastructure or on separate servers. Autonomy comes from the boundaries between organisations, not from having a separate machine for each one.

What is shared stays small: a register that helps organisations find and identify each other, and where their platform lives. It doesn’t own their cases or control their agreements; each organisation stays responsible for the relationships and roles it accepts.

How trust works between platforms. Each platform has its own address and its own key, and signs what it asks for itself. The platform it asks checks that signature against the agreement between them. No secret is shared between installations.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#FFFBF3","primaryBorderColor":"#211D18","primaryTextColor":"#211D18","lineColor":"#211D18","secondaryColor":"#FCE3D2","secondaryBorderColor":"#EC6A22","tertiaryColor":"#ffffff","tertiaryBorderColor":"#D9CFBE","clusterBkg":"#F5EFE4","clusterBorder":"#D9CFBE","fontFamily":"Instrument Sans, system-ui, sans-serif","fontSize":"15px"},"flowchart":{"padding":18,"nodeSpacing":40,"rankSpacing":45}}}%%
flowchart TB
  A["Organisation A<br/>its own cases"] <-->|"case role,<br/>agreed by both"| B["Organisation B<br/>its own cases"]
  B <-->|"case role,<br/>agreed by both"| C["Organisation C<br/>its own cases"]

Scroll sideways to see the whole diagram.

Design the collaboration together, before going live

Two organisations should be able to explore a new collaboration before real cases depend on it. In CaseFlows they do that on the development environment: they agree on the responsibilities, walk through test cases, see what each participant may see and do, and find where the process needs adjusting, before any real application with real personal data runs through it.

Only when both organisations accept the arrangement does it move into production; production only runs a collaboration both sides have promoted. People from a partner sign in with the account of their own organisation, so nobody has to manage the other side’s users.

Where we’re heading: a test case that crosses the boundary and continues on the partner’s side as its own test case, so both organisations can experience the whole collaboration, inside and out, before it exists.

From a network to a commons

Some collaborations are too important to depend on the rules of a single organisation. A group of participants can choose to maintain shared specifications together: the roles, responsibilities and agreements that make their collaboration work. That doesn’t have to wait until many organisations happen to work the same way; municipalities and care providers, or a group of energy cooperatives, can decide to do it deliberately.

Each organisation stays responsible for its own cases and systems. The shared specification is governed collectively, and that raises its own question: who may change a shared specification, and how do participants on different versions keep working while a new one is adopted? That is a different question from who may change one organisation’s caseflow, and the participants answer it together.

A way to picture the growth:

Partnership: two organisations agree on a case role and work together.
Network: more organisations form relationships, reusing roles, services and specifications.
Commons: a group of organisations jointly maintains the specifications and agreements that govern their collaboration.

The first runs today. The building blocks for the others exist: a shared layer that several platforms follow, which is how our own platforms already share their concepts, and agreements each platform confirms for itself. The first commons that independent organisations actually run together is the next step. More on shared stewardship in Open specifications, portable processes.

And what CaseFlows itself holds

If nobody owns the whole ecosystem, it is fair to ask what CaseFlows does own and manage. Today:

We run the register in which organisations and their platforms find each other.
We maintain the protocol by which platforms hand roles to each other, and decide how it evolves.
We provide the only runtime for the specifications, and we host the platforms.

What stays yours regardless is your specifications, as open files you can read and keep, and your agreements with your partners. A federated design is not yet independence from the supplier who built it; we would rather say so than imply it. Our direction is to hand more of this over: governance of the shared rules to the participants of a commons, and a second runtime for the same open formats.

Partners who help organisations get going

An ecosystem also needs people who help others join. Implementation partners do that: a consultancy that knows a sector works with an organisation’s process owner, helps describe the work, and builds the first caseflows with them on the development environment. Taking something to production stays the customer’s decision. We are setting up that partner model now, with our first partners. More in Implementation partners.

What runs today, and where we’re heading

Runs today

A case role held by another organisation, with an agreement both platforms confirm.
Collaborations designed and tried on the development environment first; production only runs what both sides promoted.
Platforms with their own address and key, on shared or separate servers, sharing no secret.
People from a partner signing in with their own organisation’s account.
Customers, applicants and partners taking part in a case without a platform, at no cost.
A shared layer of concepts that several of our own platforms follow.

Where we’re heading

A place where reusable roles, agreements and services can be found, with the participants’ permission.
A test case that crosses the boundary and continues as the partner’s own test case.
Chains of organisations that hand roles on, measured end to end.
The first commons that independent organisations run together, and governance of shared rules handed to its participants.
The partner model, with the first implementation partners.

Want to grow a network around your work?

Start with one case and one partner, on the systems both of you already have.

Request early access