Components do not prove it works: flows, ownership and operations

A solution overview diagram can be accurate and still prove very little. It shows a portal, a case management platform, an integration layer and a notification service, neatly connected. What it does not show is whether a real customer’s real problem actually gets solved, what happens when something unusual comes in, or who is responsible when it breaks on a Sunday.

Evaluators know this. Components do not prove that a solution works. Evaluators need to see how a user’s goal becomes a business and technical outcome.

This part covers the views that do that job: the business flow, the technical sequence, the data flow for sensitive information, the ownership view and, where automation makes decisions, the rules around it. We stay with Ridgeline Digital’s bid for Rivermark Water’s customer self-service and case management platform. Both organisations are fictional, and all figures are illustrative.

Why a list of parts is not enough

Picture a restaurant. The floor plan shows tables, a kitchen, a bar and a till. It tells you the restaurant has everything a restaurant needs. It tells you nothing about whether your order will arrive hot, what happens if the kitchen runs out of an ingredient, or who sorts it out when the bill is wrong.

To judge that, you would follow one order: taken at the table, sent to the kitchen, cooked, checked, served, paid for. Architecture flows do exactly this for a solution. They follow one piece of work from start to finish, including the awkward cases.

At Rivermark, the most important piece of work is a fault report. About 9,000 arrive a month, rising to around 30,000 in a bad storm week. So that is the flow Ridgeline draws first.

The business flow: one fault report, start to finish

A business flow shows the work from the customer’s and the organisation’s point of view, without technical detail. It includes the decisions, the exceptions and the steps where a person has to act.

Walking through it in plain terms:

1. A customer reports a fault through the portal, WhatsApp or by phone. All three channels feed the same process, which is itself a change from today.
2. The account and location are validated. A report with no usable location cannot be dispatched, so the customer is asked to confirm it straight away rather than days later.
3. The platform checks whether the fault has already been reported nearby. When a main bursts, dozens of people report the same thing. Instead of creating dozens of cases and dozens of field jobs, the new report is merged into the existing case, and the customer receives the same reference number and the same updates.
4. The platform checks for safety risk or complexity. Most new faults are straightforward and go straight through, meaning no person needs to touch them before a field job is created. A burst main next to a busy road, or a report mentioning a sinkhole, is an exception and goes to a supervisor to review and prioritise.
5. A field job is created, either automatically or by the supervisor, in the field team’s existing mobile job app.
6. The field team fixes the fault.
7. The customer is notified and the case is closed. Status updates also go out along the way, which is the point of win theme 2 from Part 5.

Notice what this view makes discussable. The contact centre manager can challenge the duplicate rule. The operations manager can check the safety criteria. Neither needed to understand an integration pattern to do so.

The technical sequence: the same report, system by system

A technical sequence shows the same journey from the systems’ point of view: which component calls which, in what order, and what comes back. Technical evaluators use it to judge feasibility. Operations evaluators use it to see where things can fail.

A few terms in that view are worth explaining:

• The API gateway is the front door for all requests from the channels. It checks who is calling and whether they are allowed to, before anything reaches the business logic.
• The case service is the heart of the new platform. It creates and updates the case record for each fault.
• The rules service holds the business rules, such as the duplicate check and the safety criteria, separately from the code, so Rivermark can adjust them without a software release.
• The field job app is the mobile system Rivermark’s field teams already use. It has a supported API, so the case service can create jobs in it directly.

Every arrow in a sequence like this is a place where something can go wrong. Ridgeline’s proposal adds one sentence under the diagram that matters a great deal: the case is recorded before the field job is requested. If the field job app is slow or unavailable, the customer still has a reference number and the job request is retried from a queue, so no report is lost.

The sequence also explains an honest answer elsewhere in the proposal. Requirement NFR-004 asks for 99.5% monthly availability. Ridgeline marks it as “partially comply”, because showing a customer’s live balance depends on Rivermark’s billing views, which Ridgeline does not run. Fault reporting keeps working when billing is down; the balance screen shows the last known figure with the time it was read, and billing queries are queued rather than answered with false data. Drawing the flow is what makes that distinction visible.

The data flow: where customer information goes

For sensitive or regulated information, a proposal should show more than boxes and arrows. A data flow view needs to cover the items below. At Rivermark, the sensitive information is customer personal information: names, account numbers, phone numbers, addresses, and anything a customer types into a complaint.

That last row connects back to Part 3. Where the WhatsApp messaging provider processes messages was classed as a blocking question in discovery, because a different answer changes both the design and Rivermark’s obligations. The data flow view does not pretend the question is answered. It marks the WhatsApp provider as provisional, with the open question written beside the diagram, until the clarification comes back.

Under POPIA, South Africa’s data protection law, Rivermark is the responsible party: the organisation that decides why and how the personal information is processed. Ridgeline, running the service under contract, acts as an operator: it processes the information on Rivermark’s behalf. Using the right words here signals that the bidder understands who carries which obligation.

Ownership after launch

A diagram can show every system and still leave the most important question unanswered: who is responsible for what once the build team has gone. An ownership view answers it directly, and Ridgeline built one for Rivermark.

Two rows deserve a closer look. The first is business policy and content. Discovery found that nobody at Rivermark owns customer-facing content: the fault categories, the wording of status messages, the answers in the portal. The IT manager’s team is small and cannot be expected to fill that gap. So rather than quietly writing “Rivermark: accountable” and moving on, the proposal names the gap and recommends that Rivermark appoints a content owner before launch. An ownership view that exposes a missing owner is doing its job.

The second is the duplicate-matching rules. They decide when two fault reports are treated as the same fault. Rivermark approves the thresholds, because it owns the business risk of getting that wrong. Ridgeline implements and monitors them. The case management software supplies the matching engine. If those three responsibilities are not written down, the first bad merge during a storm week becomes an argument instead of a fix.

Many proposals present this as a RACI chart, a grid showing who is Responsible, Accountable, Consulted and Informed for each activity. One caution is worth keeping: a RACI chart helps only when the real work behind each role is understood. “Ridgeline: R” next to incident response means little. “Ridgeline diagnoses the fault, coordinates suppliers and reports to Rivermark within 30 minutes” means something an evaluator can score.

When automation makes decisions

Ridgeline offers the duplicate-report matching as an optional feature with its own price, because it uses a matching model that makes a decision without a person. Any proposal that includes automated or AI-based decisions should specify, in plain language:

• Which tasks are automated. Suggesting that a new report matches an existing case.
• The evaluation set and measures. A few thousand past fault reports from Rivermark, labelled by hand as “same fault” or “different fault”, used to test the model before launch.
• Which errors cause the greatest harm. Merging two genuinely different faults is far worse than failing to merge two identical ones. A missed merge creates a duplicate job. A wrong merge can leave a burst main unattended.
• Confidence or policy thresholds. Only very confident matches merge automatically; anything less goes to an agent to confirm.
• When a human reviews or takes over. Always for reports flagged as a safety risk, whatever the model says.
• How decisions, sources and versions are recorded. Every automatic merge is logged with the model version and the reports involved.
• Who approves changes. Changes to the model, prompts, knowledge or rules need Rivermark’s approval, just like any other release.
• How monitoring, rollback and incident response work. If wrong merges are reported, the feature can be switched off within minutes and every merge reviewed.

One sharp point belongs in every AI proposal: “98% accuracy” without a defined task, dataset, sampling method and error tolerance is not an architecture requirement. It is a number. For more on testing automated agents properly, see evaluation: how do we know an AI agent is working?.

What to take from this part

Follow one real request through the solution. A business flow with its exceptions proves more than any component diagram.

Every arrow is a place something can fail. Say what happens when it does, especially for the dependency you do not control.

Show where personal information goes. Geography, access, retention and subprocessors, with open questions marked honestly.

Write ownership as real work, not letters in a grid. And specify automated decisions by their errors and thresholds, never by one accuracy figure.

Next in the series: The target is only half the architecture: as-is, bridge states and to-be.

How CloudNala can help

We help bid teams draw the flows evaluators actually test: a business flow with its exceptions, a technical sequence that shows failure handling, a data flow for personal information, and an ownership view written as real responsibilities. Where a proposal includes automated decisions, we help specify the evaluation, thresholds and human controls in terms an evaluator can score.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Bid Review or write to us at consult@cloudnala.co.za