When asked about their biggest problems with vendors/suppliers within the ICT-area,
many Swedish municipalities point out a limited number of factors that prevent and
slow down development speed and create unnecessarily high costs. This section is a description of our philosophy to overcome these problems.
Lock in effects
Lock in effects is by far the most negative factor. These effects are both technical and legal/contractual.
Technical “lock in” rest on proprietary closed standards, closed API:s (if any), factors as no web based interface as standard, no possibility to export the entire data base etc.
Legal lock in is bound by a contract, e g giving the effect that although a municipality has collected data, saved it in a database and then used it on a daily basis, this data base is not owned by the municpality, but by the suppling company.
If the municipality wishes to export the whole database, e g to transfer it to another (competing) system, the supplier can legally prevent this, or create high costs for the permission to export data.
The situation has also been acknowledged in a study by Richard Wessman, Doctor of Laws (LLD), for the Swedish Competition Authority. Among others he points out that the de facto lock in creates a situation where it is impossible for the public sector to change suppliers, that municipalities often are locked into an oligopoly-like situation where suppliers have a de facto monopoly as soon as the systems are installed.
Dr Wessman also shows that municipalities, being rather small units, often have a disadvantage in the negotiation process with large suppliers. The power balance is often beneficial to the suppliers.
An additional problem is that interoperability between different systems, delivered by competing suppliers, is low thus preventing an efficient data handling.
Larger suppliers try to lock in clients into a supplier-specific “echo system” of their own. External software from other suppliers is simply not allowed.
The main problem
The main problem lies in the fact that often data produced within the public sector is owned by, and only available to, the supplier of the system who controls in what manners this data can be exposed to the organization and to the end user.
This lock-in effect is often an effect from current work practices for public sector procurement and is not due to technical reasons.
The supplier also controls the development of the system and has no incentive to improve a system, as this would require investment and therefore reduce the profit.
The public sector faces an oligopoly of suppliers where no supplier has an incentive to change this situation. Attempts to compete by smaller or new suppliers are handled with oligopoly logic – just buy the competitor and then continue as before.
This is not an efficient way of to speed up development in the public sector.
Instead the public sector could use open platforms, with open API:s, open documentation and open standards, to store data and define basic routines and processes for handling data.
The platform would permit access via the API:s by third party components that are built onto both open source and proprietary code.
Thus the platform that is the “infrastructure” of the service would contain data and basic routines and processes for handling data that will prevent and/or avoid any lock-in or interoperability problem.
Using an open platform would give other suppliers (or the public body itself) the possibility to process data outside of the system, create a number of services that are external to the platform, yet keeping all the strategic data in one place (the platform).
The platform itself does not need to keep track of all different types of units that will access it. The supplier of the open platform will only be responsible for the basic technology and a standardized administrative interface.
Multiple channels, interfaces and suppliers
The communication with the end user will be handled by a number of channels, applications and means. The platform can be called from web, mobile phones, pads, that is, from a number of different systems.
And when new means of communication appear on the market, it can easily be integrated as one more communications channel.
A number of suppliers, developers can use the data from the platform, present it, modify it and/or restore it into the platform.
As the platform is created for external communication, with well defined API:s, all data in the platform can be used externally by general or highly specialized applications.
It would be possible to create a general web based view for an administrator. At the same time, in another channel, parts of the data can be used to present information for highly specialized purposes, e g groups of disabled/blind people in a mobile app that would be custom built for the needs of this group.
One does not any longer need to make compromises trying to satisfy both an undefined general public and specialized target groups in the same user interface.
As the API:s are open, the specialized applications/interfaces can be constructed by anyone having the knowledge about their target group. We will no longer be dependent on one supplier trying to cover all needs from within their own technical organization.
The complete document with examples of how the philosophy can be adapted can be found here.