Integration, and the law that goes with it

Most expensive technology mistakes are strategy mistakes wearing a technical costume. The platform bought for a market that never came. The build started because a build was the exciting option. The supplier chosen on a demonstration nobody technical attended. We do the thinking that comes before those decisions, and we do it with the same discipline we bring to a codebase: options, evidence, a recommendation, and a record of what we could not verify.

Technology and digital strategy means a roadmap somebody can actually sequence, with dependencies on paper. Product strategy means discovery before design, a go-to-market view the build can support, and technical validation before an investor asks. Build, buy or partner means a scored comparison against your own criteria, not the vendor's. And due diligence means the report a buyer, an investor or a procurement panel would have written if they had our access, delivered before they do.

The legal partner sits in every one of these. A strategy that assumes a data flow a regulator will not permit, or a supplier whose terms make the exit impossible, is not a strategy. It is a problem with a launch date.

Integration work fails for boring reasons: nobody owns the field mapping, retries duplicate orders, and the nightly job fails silently for three weeks. We design for those cases first. Idempotent writes, explicit reconciliation, and alerting that fires on a missing run rather than only on a failing one.

Where the constraint turns out to be the database rather than the integration, we say so and fix that instead. And where a monolith genuinely needs breaking up we will do it, but only after showing you what the split buys and what it costs to operate. Scalability is a decision with a bill attached, not a default.

Most reporting projects produce more charts than decisions. We start from the other end: name the decision, name who makes it and how often, then build only what changes that decision. It is a shorter list than anyone expects, and it gets used.

The unglamorous half of the work is definition. When finance and sales disagree about revenue, the problem is almost never the database, it is that nobody wrote down which one is right. Every metric we build ships with a written definition, an owner and a refresh schedule, and the dashboard says when the data was last good rather than pretending it is live.

Forecasting comes last and only where it is honest. A model trained on eighteen months of a changing business will produce a confident number that means nothing. When the history supports a forecast we will build one and state its error range. When it does not, we will tell you that instead of selling you a model.

Transformation programmes usually fail on sequencing rather than on technology. Three workstreams depend on the same migration, nobody owns the order, and the first slip cascades. We do the assessment, put the dependencies on paper, and say plainly which parts can run in parallel and which cannot.

Product ownership carries on through the build, so what was decided in discovery is what actually ships. Downstream sits the team. Setting up a delivery team and a PMO practice that survives after we leave, and managing the vendors and procurement that go with it, is part of the same job. Both partners hold the project management credentials this needs, and use them.

The other common failure is that the new system ships and people carry on using the old process. Change management is not a slide at the end of the deck, it is who gets trained, what stops working on which date, and who answers the phone in week one. We plan that with you, and we say when a deadline has stopped being realistic rather than reporting green until the week before.

We build ingest paths that validate every message against a published contract and only acknowledge it once it is durably stored, so a producer is never told a reading was accepted when it was dropped. Positions carry an error budget derived from the actual calibration, which means the interface can draw an uncertainty ellipse instead of a dot that lies about its own precision.

Some of this work belongs on the device rather than in the cloud, because the link is narrow or the latency budget will not allow a round trip. We train and evaluate perception models, then deploy them to run on the hardware in ONNX, with the evaluation numbers reported rather than claimed.

Above that sit the rules that make an operational picture usable: correlation that refuses to merge two tracks when the evidence is ambiguous, lifecycle rules that retire a track nobody is observing, and geofence logic that uses each track's own accuracy as its hysteresis band rather than a guessed constant.

We start with a STRIDE threat model and a data classification, and we write the uncomfortable rows down. Every threat gets the control that answers it and a source in the codebase, and anything without a control is marked open rather than quietly omitted. That register is the document a customer security team, an insurer or a regulator will actually ask for.

Then we test the claims. Authorisation is the usual weak point, so we generate cross-tenant access tests from the route list, which means a new endpoint that skips the check breaks the build instead of shipping. Identity and access design gets the same treatment: who holds which role, what a token can reach, and how fast a compromised credential can be taken away. Static analysis runs with warnings as errors, dependency audits fail the build, and a software bill of materials plus container scanning covers what you inherited rather than wrote.

On testing: we scope and run security audits and penetration tests, and we advise on resilience against volumetric attacks. Where independence is the point, because a customer or an insurer is the audience, we will tell you to commission the test from someone who did not build the system.

Work for a public body has a different failure mode from commercial consulting. The risk is not that the recommendation is unambitious, it is that somebody repeats a number in a briefing and cannot say where it came from. So we build the file around provenance: comparative benchmarking against official primary sources, a clear separation between what is confirmed and what is inferred, and an explicit list of what we asked for and did not receive.

The second half of the work is feasibility. A scheme design is not finished until somebody has checked that each step is actually permitted and at what level it has to be set down. We do that analysis, and we design the application system and assessment process the scheme will run on.

In short: we produce policy and strategy for public bodies, and the programme file that carries them through institutional review.

Technology contracts go wrong when the person reviewing the words has never seen the system. Service levels get agreed that the architecture cannot meet, data processing terms describe flows that do not exist, and an exit clause assumes an export the platform cannot produce. We review the contract and the system together, which is the only way to catch that class of problem before signature.

Intellectual property is the clause people skip and regret. Who owns the code a contractor wrote, what happens to it if the supplier is acquired, and whether you can take it with you: we settle that before signature rather than during a dispute.

On data protection we work from the actual processing rather than a template. What you hold, where it moves, which third countries it reaches, and which transfer mechanism covers each hop. Then the documents that have to exist: records of processing, processor terms, impact assessments where the threshold is met, and a breach process somebody has rehearsed.

Scope note: we advise on technology, commercial and data protection matters and draft the documents that go with them. We are not a litigation practice and we will refer you on where a matter needs one.