The pause in legislative process for the NHS reforms and the information revolution provides time to reflect back on what has been promised by the new government and what changes it will mean for organisations providing NHS care and more importantly for analysts what new information systems will result from this. In the current cash strapped world of the public sector, we are again seeing a new push on the adoptio of open source technologies to replace traditional office automation and relational database technologies, but how “open” is this open source software and how long will it remain so.
The phenomenal rise of Linux as a viable alternative to the Microsoft Windows dominated world of a few years ago has sparked a number of similar businesses, each seeking to pursue a similar business model. The first scenario is therefore the company that begins with an open solution, inviting collaboration from various industries to develop an application which then becomes owned by the community. However, once a critical mass is reached, the company suddenly develops a commercial arm and updates to the commercial application are then dripped into the free version whilst the company structure gears around the provision of support services for the commercial flavour.
The second scenario is one where not all of the stack is free. Take healthcare systems for example. These typically consist of an integration engine which is capable of pulling data from disparate system to avoid a rip and replace model, followed by a server implementation to take this data, merge and publish it to the final presentation layer. Looking at many projects currently claiming open source credentials, only one of these three layers is truly open source.
So, do you have an open source integration engine which allows you to pool data, but not display it. Or do you opt for the open source portal which uses closed systems architectures to draw and process the data?
In our opinion, until such time as the entire stack is truly open source and everything is collaborative, then this is simply a ruse to move people from software which is openly proprietary through to software which allows you access to a limited set of functionality on an open source basis, but recovers this through configuration and consultancy charges, whilst also selling add-on services which are not open source.
Beware technological constraints! Lessons from Hollywood.
For those who missed the series “Paul Merton’s History of Hollywood” and have access to the BBC iPlayer I would recommend watching it from start of finish, but especially the third and final episode. The series paints a fantastic picture of the growth of Hollywood, the egos that shaped the future direction of the industry and the use of technology – not always a positive experience. It is mainly this third element that we will look at during this post. This post is not supposed to be an accurate representation of the history of cinema, purely looking at parallels between this sector and the field of information systems.
As documented in the series, the introduction of talking films without the necessary technological advances reversed many advances in film making techniques which had developed over the previous years. The static nature of the microphones and the perceived need to be making the most of this new technology led to a deterioration in the overall quality of the final product.
In summary, the need to use a particular technique or technology placed additional constraints on delivery of a product with a detrimental effect upon the final product and customer experience. This viewpoint is just as apt to the fields of information systems and information technology as it ever was with an often ongoing tension between the complexity of the customer requirement balanced against the experience and ability to deliver of the supplier organisation.
The solution? The separation of the analyst and developer roles to prevent customer requirements being trimmed to match the favoured development environment. By producing a technology agnostic solution, the analyst role is again customer facing and performing the intelligent customer role in dealings with other colleagues tasked with coding and producing the final system.
If customer service and satisfaction is important the a decision on the appropriate technology to use should not be made until the customer requirements are fully understood. Whilst this can make it difficult to write into a tender response it should still be possible to identify the potential delivery options to the customer along with a professional analysis of the pros and cons of each technology.
Just as the role of the educator is to provide a framework through which individual learning can take place, the role of an information systems provider should firstly be to assist the customer in defining the problem they are trying to solve. Only when this is done should the design be constructed and the solution delivered.