Continuous software updates – What should they mean for the purchasers of software?
As the real world keeps changing, software must keep pace. Graduates from the Ä¢¹½Ö±²¥â€™s Master’s Degree Programme in Information and Software Engineering will be experts in the needs and possibilities of entire systems based on continuous change, writes Professor of Software Engineering Tommi Mikkonen from the Ä¢¹½Ö±²¥.
We have all probably been frustrated at some point with the experience that just when you have an important task at hand, the computer – be it a smartphone, tablet, PC, or a cloud service – announces that unfortunately a software update must be performed. Why don’t they make everything ready and complete in the first place?
Software evolution – what does science say?
Although this phenomenon, as a nuisance to end-users, is fairly recent one, the fundamentals of software evolution, so-called , have long been known. Meir ‘Manny’ Lehman formulated these laws based on three types of software: S-, P- and E-type. Of these, the S-type software is based on precise specification, such as a mathematical formula, and P-type software performs specific operations that determine everything that the software can ever do – like chess moves, for instance.
E-type software, in contrast, is part of real-world processes and closely connected with the surrounding environment.
E-type software differs from S- and P-types in that it calls for continuous finetuning in order to serve users and function appropriately in a changing context.
Continuous finetuning, however, means increasing complexity, which in turn calls for further work and efforts to manage the complex system by means of software architecture. All this requires well-organised work, which often begins to resemble software itself in its structure.
A big part of software engineering has consisted of finding technical and methodological solutions for the management and organisation of increasing complexity. Software frameworks, containers, and continuous deployment are examples of how designers have sought to respond to the needs of ongoing software evolution.
Many corporations, such as Facebook, update their services several times a day, and the game industry uses several rivalling implementations in order to find the version that best serves the users– or the game house itself.
At the same time, there are large organisations that procure massive software packages in the belief that the system will serve the organisation for a long time without changes, if only the software requirements are adequately formulated. They fail to realize that any software system that deals with the changing world is inevitably E-type software: however well its requirements might be formulated, there is no known way to convert it into an S- or a P-type system.
Suppliers prepare for changes in their pricing policies, even if buyers might ignore such aspects
Because supplier organisations participating in this kind of competitive tendering know they are dealing with an E-type system, they are prepared, in their pricing, for the continuous change of the software and for maintaining the required organisation.
As a result, the prospective customer organisation often receives tenders with prices many times higher than expected, especially when it comes to the supply of a complex software system, the production of which may have called for hundreds of work years and which perhaps nobody understands in its entirety, at least on the buyer’s side.
On the other hand, because the system is often essential for the customer organisation’s core activities, such as in medical care, outsourcing the whole system fully to an IT supplier creates a huge risk.
Moreover, because the system is customised, it is often incompatible with any similar system offered by another supplier and possibly in use in a neighbouring municipality or health care district, for example.
Microservice architecture simplifies the whole
In terms of software engineering, the simplest way to manage supplier chains is to divide the entire system into a set of services that can be administered independent from each other.
In cloud services, for example, this model is called microservice architecture. In such a case, the buyer administers the microservices, which could be purchased from different service providers and/or in a centralised way from the Digital and Population Data Services Agency, for example.
Because an individual service can be updated or altered in a centralised and controlled fashion, this would simplify the evolution of the whole system – which is inevitable for E-type software.
The new Information and Software Engineering programme of the Ä¢¹½Ö±²¥ is designed to train experts who understand the developmental challenges and possibilities pertaining to these kinds of systems, combining Information Systems Science and Information Technology in suitable proportions. In addition, the software business plays a major role when considering what a suitable business model is and revenue logic for different settings. The ultimate goal is that not a single software project would ever again fail because of the unhappy situation where the buyer and supplier are talking past each other without understanding the other party’s needs.
Tommi Mikkonen is a professor of software engineering in the Faculty of Information Technology, Ä¢¹½Ö±²¥.
