EDITING BOARD
RO
EN
×
▼ BROWSE ISSUES ▼
Issue 51

Plan the project decommission from the beginning

Radu Vunvulea
Solution Architect
@iQuest
PROGRAMMING

We all make mistakes. Sometimes, they are small with no impact on business continuity, while, other times, they are bigger and can impact the business. A few years ago, I was indirectly involved in a project where a wrong decision resulted in a large amount of money being lost, which impacted the current business and the business continuity.

I decided to write this post as a lesson for all of us learn, in order to avoid making the same mistake, especially in this era, where SaaS is the preferred option. It is an era where buying licenses for existing solution is better than developing your own - without analyzing the impact and without considering what should be done if you want to change the provider.

Overview

Don't understand me wrong. I'm a big fun of SaaS, of buying the solution, and then pursuing in-house development. From my perspective, this is the correct approach for companies that have the right people around them, people that are aware of the dependencies. In this context, dependencies refer to the fact that the system will become a one-time legacy and will need to be replaced. Companies need people who do their job, and not only follow KPIs.

There is a rule that says that a Manager, GM or Cxx shall start, from the first day, to find and prepare the next person that will take their place. The same thing shall happen in the software industry, especially when we talk about enterprise and IoT. Nowadays, replacing a component might have a high impact on business continuity, costs and legal (licenses) after 5 or 10 years.

The story

The story unfolds in a big enterprise that has been working with devices and IoT for more than 25 years. They are that kind of company that change the world. Their solutions can be found around the globe and are used by millions of people every day.

Of course, especially in enterprise a device comes with a support and maintenance package. This means that telemetry data needs to be collected, updates needs to be sent to devices and many more. In one word, this is IoT, the way we know it today.

As any software solution, you try to reuse it as much as possible. This means that you will try to use the same implementation for all your device landscape. This action is perfectly normal and natural. In the end, the flows are similar. Usually, only the source or the information you collect is different, based on the device capabilities.

Being in the era of IoT, the normal thing that you'll do is to look around you, identify the current solution and try to find the one that suites your needs. Once you identify a platform that fulfills your needs, you will buy the license for it. And, of course, you'll start to use it.

In general, such a platform comes with an out-of-the-box solution on the backend, and another part that runs on your devices. On top of it, you might need to do some customization and voila, you connected your devices to your backend system.

The out-of-the-box solution that comes with the IoT platform can come with different licensing models. The most aggressive one, from my point of view, is the one where the agent which came with the IoT platform and which runs on your devices is not your property and you are allowed to use it as long as you pay your annual license.

This is what happen in my story. It is one of the evilest dependencies that you can have.

Let's me explain why it is.

As any software solution, the system has a normal life-cycle. One way or another, you know that this solution will not run forever and you will eventually need to change it. The life-cycle could be 5 years, 10 year or even 15 years. This means that, from the beginning, you need to think about the dependencies that you'll have when this period ends. You need to ensure that the migration to the new solution can be done with minimum impact. In this kind of situation, the minimum impact will be a big one, but at least, you want to try to avoid human intervention on each device.

Second, if you are working in special industries, laws will not allow you push to push any software to devices. There is a standard validation process that can take from 6 months to several years. This means that for the devices that are not included in the validation phase, injecting new software will add another 6 months out of your 2-year project. It means that, for this period, you will not be able to push new type of devices to the market.

Third, attention must be given to devices which are offline, but which are running. Removing software from them will be hard. We don't even want to talk about how you can remove this software from the backup images that you pushed with the devices and that are used automatically when the software or OS that run on the device crash…

All these things happen because you have, on your own devices, which are produced by you, a software component, which can be used as long as you are the client of that IoT platform provider.

Once you are removed from the client list, you are required, by contract, to remove all their property software.

The moral

It is acceptable to have this kind of software on systems where you have easy access. These kinds of dependencies could be pushed to cloud solutions, datacenters where you have access, but not in the field. The field is a territory where you don't have access and control.

In the field, each device will run software with a license that enables you to run it even after 50 years of usage, without having to pay a single fee. It is normal to pay a fee for a service or for anything else, but, for the agent, for that small piece of code, you should buy the right license. You don't need to hold property of it, but you need to be able to run it or have it installed on devices for as long as you want it.

A good example here is Windows OS. There is one thing that should be mentioned about Windows 98 or Windows 7. You buy the license only one, but you can use it as much as you want. Other versions will enable you to upgrade them (receive fixes and updates) as long as you pay the license.

An example from the IoT world is the agent of the IoT Hub that is offered by Microsoft. It is open source, it is free and you can use it any way you want. You can even modify it without problems. What do you have to pay? You need to pay the IoT Hub backend as a service. If you don't use it anymore, nobody will request you to remove the agent from the devices.

In conclusion, try to have a vision of the software life-cycle from the beginning. Even the best software will be replaced in the end.

Conference

Sponsors

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects