One of the key factors in procuring a new computer system is how well it will integrate with existing systems and report across different databases, while also avoiding any duplication of data input and storage. This led to the idea of the RSL ‘Super System’. The Super System can be thought of as being a single database solution encompassing all major functions needed by an RSL, from housing management and repairs through to asset management and finance.
In reality, the Super System does not exist but comprises a number of disparate applications, often with entirely different database technologies, acquired by a single IT supplier and held together by internal interfaces. Not surprisingly, these Super Systems tend to offer more generic functionality than those available from niche application-specific suppliers.
But in today’s age of open system architectures, why is interfacing and integration such an issue? Without the guidance of standards, the need for interfacing and integration not only increases the capital costs and implementation timescale of projects, it also results in data consolidation and consistency issues.
In our experience, there are two main reasons why this is such an problem, and neither of them are technology constraints:
- It is not in the commercial interest of some suppliers to make integration easy;
- RSLs often have disparate business processes to achieve the same thing which makes it difficult to achieve a ‘one size fits all’ specification.
Regarding the first point, there are broadly two types of technology suppliers in the housing sector – large organisations with a broad portfolio of products in differing areas and niche suppliers operating in specific fields such as housing repairs or asset management.
Super System suppliers often don’t want to make integration with other systems too easy because their goal is to sell additional products after the initial implementation. This ultimately results in the ‘corporate takeover’ of an RSL’s IT infrastructure, leading to a loss of independence and total reliance on one or two technology suppliers.
On the other hand, most niche technology providers like the concept of standard interfaces to other key corporate applications. Certainly for us, developing interfaces is simply not a core business activity. Although we are very experienced at it, we would much rather be developing innovative software modules and adding real value to our systems than writing bespoke interfaces.
Coming to the second point, the failure to agree a set of data exchange standards and model interfaces is due to the widely different business processes used by RSLs to carry out common activities.
A good example of this is variation processing which is managed in completely different ways from organisation to organisation. Sometimes there are pre-defined limits where work can be carried out without approval. Sometimes it is a percentage of the order, the SOR, the trade or the total contract, or it depends on the location or the type of work; all these factors influence the way the interface logic operates. Sometimes the differences in business processes are simply historical but in other instances they are innovative and give organisations a real commercial advantage. Either way, a code of best practice covering the key business processes would at least enable the 80/20 rule to be applied and allow the standard interface to be used and configured to meet the majority of requirements.
While the absence of interface standards can be mainly attributed to the above two reasons, other factors can also influence the ease of integration, including:
Common open infrastructures, such as Microsoft SQL Server, allow quick and easy integration both at the application layer and between business applications and desktop applications such as Word or Excel. Database table mapping between Microsoft applications means there is no need for duplication of data.
Treating the housing repairs function as a single, end-to-end process (straight-through processing), from taking the tenant work request to costing, resourcing and completing the job, significantly reduces the complexity of interfaces.
Ensuring that all applications have been specially developed for use over the web, such as those which use Microsoft .Net or similar, will enable pages from different sources to be seamlessly presented to end-users.
The creation of a set of interface standards is entirely possible as long as all parties are committed and collaborate on their production. While useful lessons can be learnt from previous initiatives such as EGIF (E-Government Interoperability Framework), suppliers need to provide what the market demands. ROCC for one is committed to their production.
Chris Potter is the operations director for Uniclass at ROCC.
