Why social housing needs digital ecosystems, not digital monoliths
The debate over the ‘one-stop shop’ approach to social housing software has resurfaced. The attraction is understandable: a single supplier appears to offer simplicity, reduced procurement complexity and lower perceived risk.
Yet those benefits can be short-lived. As more business-critical capabilities become tied to one platform, the cost of switching rises and dependency shifts the leverage towards the supplier. It becomes harder to challenge underperformance, replace a weak component or change direction without wider disruption and cost.
The more important question is whether concentrating those capabilities in one platform remains the right strategy for a sector whose regulatory, financial and operational demands are changing rapidly.
A healthy digital ecosystem is a modular group of specialist capabilities able to evolve independently while identity, data and end-to-end processes remain coherent. It’s neither a collection of disconnected applications nor a monolith with many interdependencies.
When integration becomes consolidation
Integrated platforms undoubtedly have value, particularly where business processes are stable and standardised.
Asset management, however, is anything but stable. Housing providers face growing demands around building safety, net zero, consumer regulation, investment planning and wider financial pressures. These require increasingly sophisticated data, modelling and decision-support.
Broad functionality inevitably involves compromise, and specialist disciplines require specialist solutions.
Why specialists matter
Asset management has always depended on knowledge as much as software.
Specialist asset management suppliers concentrate their experience from many housing providers into products that evolve alongside legislation, best practice and operational experience.
This knowledge transfer is one of the greatest benefits of specialist suppliers. Stock-condition approaches, data standards and investment-modelling practices are often developed collaboratively with specialist providers, and better customer practice ultimately improves the value of the software itself.
Few housing providers can maintain deep internal expertise across every specialist discipline, and a healthy supplier ecosystem allows knowledge, experience and R&D to be shared across the sector. But specialism should be visible in more than a feature list – it should be in the questions a supplier asks, the assumptions it challenges, the data structures it protects and the lessons it transfers from solving similar problems elsewhere.
Flexibility is essential
The technology landscape has also changed dramatically. Cloud SaaS has reduced the infrastructure burden of multiple systems, while modern APIs, event-driven architectures and integration tools have made technical connectivity more accessible. AI-assisted development is accelerating this further, making it faster for suppliers and internal teams to create reports, workflows, automations and new capabilities.
As capabilities can be created and adopted faster, flexibility becomes essential. An architecture in which individual functions are difficult to change because of multiple interdependencies becomes a major constraint.
The organisations best placed to benefit will not necessarily have the largest software suite, but the most adaptable architecture.
Meaning, provenance & ownership
Integration is often treated primarily as a technical challenge. Establishing a connection is often the straightforward part. The harder task is ensuring information retains its meaning, provenance and ownership as it moves between systems and teams.
Asset management provides an excellent example:
- Finance views an asset through historical expenditure, depreciation and budget performance.
- Asset managers focus on condition, future costs, safety, lifecycle and risk.
- Investment teams examine future investment scenarios and expected returns.
- Legal teams concentrate on tenure and ownership.
These perspectives relate to the same property but answer different business questions.
Forcing every discipline into a single version of the truth risks satisfying none of them. A better objective is one reliable identity for the asset, with clearly-governed perspectives on the information held about it.
Finance may hold an accounting life and depreciation profile for a component, while asset management records its observed condition and remaining operational life. Both can be valid but they shouldn’t overwrite one another simply because they relate to the same component. With sound data integrity, they can be reconciled but they aren’t interchangeable.
Good data governance therefore clearly distinguishes between:
- Factual historic data;
- Observations of the asset and components;
- Assumptions (subjective or objective) used in modelling; and
- Business decisions arising from those models.
Without these distinctions, organisations risk confusing evidence with policy and assumptions with facts.
Successful integration depends as much on governance, ownership and shared understanding as on technology.
Preserving the right to change
Healthy competition drives innovation but the strategic value of a digital ecosystem goes further: it preserves the organisation’s right and ability to change.
Specialist suppliers compete by solving increasingly-complex problems within their discipline. Their R&D, expertise and customer feedback remain concentrated on that field. If a capability stops keeping pace, an open ecosystem allows it to be challenged or replaced.
A broad platform must spread investment across many functional areas. Where capabilities are tightly coupled, replacing an underperforming element can become inseparable from a much wider platform decision.
The opposite of a monolith isn’t fragmentation, it is modularity. Specialist capabilities should be able to evolve independently while identity, data and end-to-end processes remain coherent.
Without that coherence, best-of-breed is simply fragmentation, but with it, organisations retain specialist depth, competitive tension and the freedom to improve or replace capabilities as their requirements change.
One service, not one system
Residents shouldn’t need to understand their housing providers’ technology architectures. After all, one customer’s service journey might touch customer contact, tenancy and vulnerability information, asset records, inspections, works, documents and communications.
Those capabilities don’t need to reside in one product but residents shouldn’t have to repeat information or navigate system boundaries. Residents should experience one coherent service, while the housing provider should retain the right to change the systems behind it.
Building for the future
Technology architecture should support business strategy rather than define it. The objective isn’t to minimise system numbers at any cost but to minimise the cost and risk of change while delivering a coherent service.
Asset management shows why this matters:
- Much of housing management relies on sound historic factual information.
- Asset management combines that history with current observations, assumptions and estimates to support decisions on condition, compliance, safety and investment.
It is therefore both a record of what is known and a forecasting and decision-support discipline, essential to optimising asset lifecycles and the value they provide.
Those outside asset management, including senior executives, must understand the information being presented and trust its provenance. This is a major investment area where poor evidence can lead to waste or unacceptable neglect, and where experienced specialist suppliers can bring valuable sector-wide insights.
The future is unlikely to belong to the largest software suite. It’s far more likely to belong to organisations that combine specialist depth with the discipline to make a digital ecosystem work, in the form of one coherent service, trusted data and the freedom to change individual capabilities without rebuilding everything around them, and assisted by suppliers, not constrained by them.
Marius Buragas is the technical director at Asprey Solutions.
For further details, please see: www.aspreysolutions.co.uk.
