Blueprints to delivery¶

Every project produces a design. It is usually drawn in a diagramming tool, presented to stakeholders, agreed - and then left behind, because the implementation moves on and nobody can afford to keep the picture up to date. A year later the only accurate description of the solution is the code, and the only people who understand it are the ones who wrote it.

A solution blueprint is that design held as metadata instead, so that it can be linked to the implementation as it is built and to the operational picture once it is running.

What a blueprint describes¶

A blueprint collects the solution components that together deliver a business solution, along with the roles of the people involved and the flow of data between components.

It deliberately stays above the level of a UML or entity-relationship model. It does not carry data types or cardinality; its purpose is to support a conversation - to tell the story of how the solution works to the people who need to agree on it. An element such as a project or a governance definition can have several blueprints, each showing a different aspect or level of detail.

The pieces are:

The blueprint below describes what happens when someone subscribes to a digital product. Notice how much of it is about people: the subscriber and the consumer appear alongside the pipeline and the delivery location, because a design that omits the roles does not explain how the solution actually operates.

---
title: Components and Roles for Solution Blueprint - Creating a new Subscription to a Digital Product [8d0d525d-d058-491e-8d96-801505900bf8]
---
flowchart TD
%%{init: {"flowchart": {"htmlLabels": false}} }%%

subgraph 1 [Components and Actors]
2@{ shape: lin-cyl, label: "*Solution Component*
**Digital Product Delivery Location**"}
3@{ shape: subproc, label: "*Solution Component*
**Create New Product Subscription**"}
4@{ shape: das, label: "*Solution Component*
**Digital Product Provisioning Pipeline**"}
5@{ shape: lin-cyl, label: "*Solution Component*
**Open Metadata Product**"}
6@{ shape: trap-t, label: "*Solution Actor Role*
**Open Metadata Product Consumer**"}
6==>|"Consume data,
[Solution Component Actor]"|2
4==>|"maintain data,
[Solution Linking Wire]"|2
7@{ shape: trap-t, label: "*Solution Actor Role*
**Open Metadata Product Subscriber**"}
7==>|"Subscribe to product,
[Solution Component Actor]"|3
3==>|"read subscription requirements,
[Solution Linking Wire]"|5
4==>|"retrieve data,
[Solution Linking Wire]"|5
8@{ shape: trap-t, label: "*Digital Product Manager*
**Open Metadata Product Manager**"}
8==>|"Develops,
[Solution Component Actor]"|5
end
style 1 color:#FFFFFF, fill:#3079ab, stroke:#000000
style 2 color:#000000, fill:#DDA0DD, stroke:#000000
style 3 color:#000000, fill:#DDA0DD, stroke:#000000
style 4 color:#000000, fill:#DDA0DD, stroke:#000000
style 5 color:#000000, fill:#DDA0DD, stroke:#000000
style 6 color:#000000, fill:#FFE599, stroke:#000000
style 7 color:#000000, fill:#FFE599, stroke:#000000
style 8 color:#000000, fill:#FFE599, stroke:#000000

Creating a new Subscription to a Digital Product: Description of the processing when a consumer creates a new subscription to an Open Metadata Digital Product. (Extracted from 6.0-SNAPSHOT)

Each component can also be viewed in its own right, showing the blueprint it belongs to, the roles that act on it and the components it exchanges data with. This is one component from Coco Pharmaceuticals' clinical trial solution:

---
title: SolutionComponent - Analyse Patient Data [b5c8da4c-f925-4cf1-8294-e43cd2c1a584]
---
flowchart TD
%%{init: {"flowchart": {"htmlLabels": false}} }%%

1@{ shape: rounded, label: "*Solution Component*
**Analyse Patient Data**"}
2@{ shape: rect, label: "*Solution Blueprint*
**Clinical Trial Management Solution Blueprint**"}
2==>|"Collection Membership"|1
3@{ shape: trap-t, label: "*Actor Role*
**New Treatment Data Scientist**"}
3==>|"Data Analyser [Solution Component Actor]"|1
4@{ shape: trap-t, label: "*Actor Role*
**New Treatment Researcher**"}
4==>|"Results Interpreter [Solution Component Actor]"|1
5@{ shape: rect, label: "*Solution Component*
**Treatment Validation Sandbox**"}
5==>|"retrieve patient data [Solution Linking Wire]"|1
6@{ shape: rect, label: "*Solution Component*
**Treatment Efficacy Evidence**"}
1==>|"publish results [Solution Linking Wire]"|6
style 1 color:#000000, fill:#e0ab18, stroke:#004563
style 2 color:#000000, fill:#f5fffa, stroke:#000000
style 3 color:#000000, fill:#FFE599, stroke:#000000
style 4 color:#000000, fill:#FFE599, stroke:#000000
style 5 color:#000000, fill:#DDA0DD, stroke:#000000
style 6 color:#000000, fill:#DDA0DD, stroke:#000000

Analyse Patient Data: ML Flow based analytics pipeline to run the variety of models over the patient data. (Extracted from V1.0)

From design to delivery¶

The blueprint becomes valuable - rather than decorative - when it is connected to what is actually being built.

As implementation proceeds, solution components are linked to the digital resources that implement them using the ImplementedBy relationship. A component might be implemented by a catalogued database, an integration connector, a governance action process, or a whole subsystem. Because these links are added as the resources appear in the catalog, the design and the implementation stay attached to each other instead of drifting apart.

That linkage supports several things at once:

• Progress against the agreed design. Which components have implementations yet, and which are still just intent, is visible to stakeholders without asking the project for a status report.
• Traceability in both directions. From a component you can reach the resources that realize it; from a catalogued resource you can reach the design that explains why it exists and what it is supposed to do.
• Impact. When a change is proposed to a data store, the blueprint shows which parts of the solution - and which roles - depend on it.

From delivery to operation¶

Once the solution is running, the blueprint becomes the natural place to aggregate its operational picture. The design is already the map of what the solution consists of, so it is the right structure on which to hang what is happening:

• Lineage captured from the running implementation shows the data actually flowing along the wires the design described.
• Measurements and governance metrics can be attached to the components and to the blueprint as a whole, so the effectiveness of the solution is reported against the same structure that was agreed at the start.
• Exceptions and incidents raised by the implementation resolve back to the component - and therefore the role - responsible for it.

In the new systems architecture scenario, this is exactly the argument Erin Overview makes: the blueprint makes the architecture visible to a broader audience, lets stakeholders follow the progress of the implementation because it is linked to the solution components, and once operational becomes the aggregation point for statistics about data sharing across the organization - so the teams relying on the exchange can verify that it is working.

Creating and viewing blueprints¶

• The Solution Architect API maintains blueprints, solution components, ports, wires and information supply chains, and their links to the implementation.
• Dr.Egeria lets a blueprint be authored as a Markdown document. This is how Erin creates the Data-Driven Systems Architecture blueprint, and how Robbie Records documents his data sharing hub for stakeholders.
• Egeria Explorer displays blueprints and components, with the mermaid graphs shown above generated automatically from the metadata - which means the picture is always current, because it is drawn from the thing it describes.

Raise an issue or comment below