Anyone getting involved with classic software systems should be aware of the risks involved. These include:
1) Right of use
The most significant risk is probably the right of use of many mainstream services, further exacerbated by the dismantling of local infrastructures in favor of cloud solutions. This has naturally attracted many manufacturers to make their systems available as cloud solutions. The risk of in-house operation has transferred to the manufacturer, who – after all – should know his system best and should be able to operate it more securely. Moreover, this solution has the added advantage that there is no need to finance a license package. Instead, the user may switch to a subscription model usually associated with such a license deal, which is also – if looked at by month – much cheaper.
Patches and Updates are usually also included in the manufacturer’s offer.
So much for the win-win-situation, which is obviously attractive for both sides; otherwise, the subscription model would not have established itself almost everywhere.
However, there is a price to be paid for this kind of model – the temporary right of use. In other words, you do not buy the right of use once and for all, but only for the period you pay for. What is more, the system sovereignty lies with the manufacturer, on explicit request.
To paraphrase, your own data lie with the manufacturer, and you can only purchase a temporarily limited right of use to work with the system and thus with your own data.
There may be some commercial sense in that, and the definition of the term „reason“ may be very flexible, but on closer consideration, one cannot deny that there is a certain amount of risk involved.
As discussed in the previous paragraph (and indeed in the last blog), data are integrated into the cloud solution described above. At the time of purchase, the future user will seldom consider if, and how, a potential export from the ecosystem might be accomplished, and, above all, how extensive it would be.
Reports or exports are usually provided, but they are typically intended to be part of the work process and not for a scenario where you plan to abandon ship. Since nothing is built for eternity, much less in IT, it is advisable to look for an emergency exit before entering a room.
We often find that exports are not a matter of course, after all, especially with migrations. The database images or complete backups usually offered are not really helpful since the data structure does not provide any transparency at all. The reason behind this is that the database structure is often complicated and difficult to understand for outsiders. Still, this is a relatively easy problem; it becomes almost impossible to find and interpret in-process fields and values or their inter-dependencies.
A comprehensive export function is, therefore, not a bad thing, at least in principle. Reports do not really help here; they rather resemble the windows of a house; you can only see a limited area when you look out of it.
3) When does it get unpleasant?
So when does all that become a problem? After all, the classic solution in IT is one of two traditional models. The alternative, i.e., open source, has only established itself in recent years. How can there be an issue with a “tried and tested“ model?
The most critical point is to get software to production. Once this step has been taken, the most challenging part has been done. But it becomes difficult if you start having problems. There are many and varied reasons for that. To name only a few:
- The software manufacturer has been taken over, and the software is discontinued.
- The manufacturer himself is discontinuing the product.
- Your own company has grown; a new client has to be created, but the solution is not multi-client capable.
- Although your company’s growth requires an international set-up, your system is not multilingual.
- Processes have changed, and the software does not fit anymore.
- The solution did not cover all areas to begin with (maybe because it started out as a specialized solution), and the workarounds are no longer feasible.
Many of these classic solutions are not web-based at all or only in part, since they have their origins in the pre- or post-dot.com era. In the current times, however, when growth sometimes goes beyond our own limits, client-server-architectures pose a problem since they do not include customers or suppliers via a portal solution.
However, problems may also arise from a completely different direction, e.g., if a company tries to save costs on upgrades. IT is fast-living, and software becomes obsolete quite rapidly, mostly due to web technologies and particularly to the process of Continuous Integration (https://en.wikipedia.org/wiki/Continuous_integration). Here, versioning is a clear indicator: Firefox is available in a version higher than 80, as is Google Chrome. The intervals between the releases of new versions have become very short, going from years to mere months. This way, new functions are quickly brought to the users, and the changes remain small. The providers have refrained from sub-versioning, as the increasing number of new versions and plans would be too extensive. Today, the providers simply collect the users‘ requirements, evaluating and implementing them according to priority.
This development has further accelerated the aging process of software.
If you cannot keep up, you’ll quickly find yourself facing an old piece of software. And then there is only one thing left to do: Start over.
It gets even worse if you are put under pressure by unforeseeable external circumstances. No system runs on its own; there is at least an operating system, which in turn consists of different components. If a severe problem is discovered here, the system may certainly be sealed off from the outside. But if the hardware fails, and the old operating system can no longer be run on the new hardware, you are in an even tighter spot. Virtualization may be an option, but even that will, at some point, stop supporting older systems. That will be the definitive end of the journey, and it will come unplanned and usually quite fast. Action is needed; a solution has to be found quickly. Easier said than done, though.