Insights from SOLARIS INNOVATIONS LTD
Short, practical writing on systems integration, hybrid cloud and automation — working notes for the people who have to make a decision, not read around one.
Read the briefing indexThese are working notes from an integration practice, not thought leadership. Each piece is short, and each one takes a position — usually the position we recommend after the third time we have seen the same problem.
They are written for the person who has to make a call: whether to move a workload, whether to automate a task, how to explain a discrepancy between two reports to a regulator or a board. If a topic here is close to a decision you are facing, the usual next step is a scoping conversation, and the briefings are written to make that conversation shorter, not to replace it.
Five recurring subjects come up in almost every discovery session we run. Each row below is one of them, with the shape of the problem and the shape of the remedy. The notes are short so you can scan the whole set before you commit to reading one closely.
The most common finding in a first discovery session is an interface that works, carries real traffic, and has no named owner. It got built during a project that ended, by someone who has since moved on.
The risk is not that it breaks today — it is that when it breaks, nobody knows what it does or what depends on it. The remedy is unglamorous: find them, document them, name an owner.
How we run a discovery sessionCloud migration advice often assumes a level of decoupling most UK enterprises do not have. The workloads that tend to stay on-premise are the ones with deep integration into systems too entangled to move, or ones carrying regulatory constraints that make relocation a project in itself.
Our briefings on hybrid design focus on which interface carries the traffic between environments, and how it is monitored when nobody is watching.
Services we deliver hereAutomation programmes fail from being too broad rather than too narrow. Teams arrive with a list of everything manual and leave with three candidates that have a clear rule and a measurable handover.
Related briefings cover how to identify candidates, and why judgment calls should stay with people even when they look automatable.
Two systems producing different numbers for the same thing is a symptom, not a problem. The problem is upstream, at the point where identifiers, ownership or update frequency were never agreed.
We cover reconciliation patterns, identifier strategy across acquired systems, and why governance work and integration work tend to arrive together.
For regulated buyers, the documentation around an interface matters as much as the interface itself.
What a reviewer typically asks for, how to build an audit trail as part of the build rather than after it, and what changes when the data in question is regulated rather than internal.
Notes on how the market is structured and what different shapes of provider are good at. Knowing which shape fits which problem saves a lot of procurement time — and usually narrows the shortlist before a technical proposal is even written.
Softcat
Strong on scale, licensing and delivery breadth; the right shape when a programme spans many sites and many vendors.
BJSS
Strong on delivery credibility in regulated programmes, where the audit trail is part of the deliverable.
Simpson Associates
Strong where analytics and governance are the core of the problem rather than a later layer on top of it.
SOLARIS INNOVATIONS LTD
Strong where the problem is the interface between a legacy estate and a cloud estate, and the cord has to be run by hand.
When the data on an interface is regulated rather than internal, the documentation around the interface becomes part of the deliverable. The same change carries different evidence requirements, and building that evidence as the work happens is far cheaper than retrofitting it after.
A named owner for every interface, and a document saying what it does and what depends on it.
An audit trail that was produced as the build happened, not reconstructed afterwards.
A reconciliation plan for the identifiers that different systems use for the same entity.
A monitoring view that stays useful when nobody is at a screen to read it.
A briefing series on how public-sector integration work is bought: framework routes, the role of the UK Digital Marketplace in shortlisting, and what a supplier needs ready before a technical proposal is read. Useful both for suppliers preparing to bid and for buyers who want to know what the evaluation rewards.
Most public-sector integration work is bought through a framework, which means the shortlist is already narrowed before a technical proposal is read. Suppliers who keep a current framework position skip the first screening step; buyers who want a wide market may need more than one route.
For many buyers the UK Digital Marketplace is where the search happens, and where a supplier's ability to be found depends on the service definition being specific. Broad descriptions get filtered out before the evaluator reaches the delivery approach.
Case studies with real interfaces named, a delivery approach that survives a read of the standard, and a named team rather than a capability brochure. The evaluation rewards clarity about who will actually do the work.
Weightings usually concentrate on delivery method and social value rather than the headline price, which means a technically stronger proposal can win against a lower bid. Read the award criteria carefully before assuming a price-led outcome.
The integration work itself starts long after the framework award. The first discovery session is almost always where the interfaces without owners are found, which is why the legacy estate briefing is the one most often read next.
Every briefing here takes a position, and none of them is neutral. If a topic is close to a decision you are facing, the usual next step is a scoping conversation — a short call to work out whether the problem is worth a project. The briefings are written to make that call shorter, not to replace it.
You can also ask for the latest briefing directly, or suggest a subject you would like us to write about next. We read every suggestion, and the ones that come up twice get written.
Or write to us directly at [email protected] — Monday to Friday, 09:00–18:00.
