Skip to main content

Plan the project decommission in day 0

We all make mistakes. Sometimes are small with no impact on business continuity, sometimes are bigger and can impact the business.
A few years ago I was involved indirectly in a project where a wrong decision generated not only a large amount of money to be lost, but also still have impact on the current business and there is a high risk to affect the business continuity.
I decided to write this post as a lesson learn for all of us and to try to avoid making the same mistake, especially in this era, where SaaS is the preferred option, buying licenses for existing solution is better and developing your own – without analyzing the impact and what shall be done if you want to change the provider.

Overview
Don’t understand me wrong. I’m a big fun of SaaS and buying then in-house development. From my perspective, this is the right solution. It is the right solution for companies that have the right people around them. People that are aware of dependencies, that the system will become one-time legacy and will need to be replaced – in one world they are doing their job, not only following the 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 his place. The same thing shall happen in software industry, especially when we talking about enterprise and IoT. In this world replacing a component might have a high impact on business continuity, costs and legal (licenses) after 5 or 10 years.     

The story
The story is happening inside a big enterprise that is 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 package and maintenance. This means that telemetry data needs to be collected, updates needs to send to devices and many more. In one word is IoT, in the way we know 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 perfect normal and natural. In the end, the flows are similar, usually only the source is different or the information that you collect may be slightly 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 one that suites your needs. Once you identify a platform that fulfill 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 them 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 model. The most aggressive once, in my vision is the one where the agent that came with the IoT platform and runs on device is not your property and you are allowed to use it as long us 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. In one way or another you know that this solution will not run forever and you will need in the end to change it. The life-cycle could be 5 years, 10 year or even 15 years. This means that from the begging you need to think about the dependencies that you’ll have in the moment when this period of time ends. You need to ensure that the migration to the new solution could be done with a minimal impact. In this kind of situations, minimal impact will be a big one, but at least, you want to try to avoid human intervention on each device.
The second thing is that if you are working in special industries, laws will not allow you push to the device any software. There is a standard validation process that can take from 6 months to even years. This means that for the devices that you are not in this validation phase, injecting a new software to them will add another 6 months of 2 years. It means that for this period of time you will not be able to push new type of devices to the market.
Another thing is with the devices that are offline, but are running. Removing software from them will be hard. We don’t even want to talk about who you can remove this software from the backup images that you pushed with the devices and are used automatically when the software or OS that runs on device crash…
Al these things are happening because you have on your own devices, that are produced by you, a software component that 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 the contract to remove all their property software.

The moral
It is acceptable to have this kind of piece of software on systems where you have easy access. This kind of dependencies could be pushed to cloud solution, datacenters where you have access but not on the field. The field is a territory where you don’t have access and control.
In field, each device shall run software with a license that allows you to run it after 50 years without having to pay a fee. It is normal to pay a fee for a service, for anything else. But for the agent, for that small piece of code you should buy the right license. You don’t need to be the property of it, but you need to be able to run it or have installed on devices as long as you want.

A good example here is Windows OS. Thing 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 allow you to upgrade it (receiving fix and updates) as long as you pay the license. Once you stop to pay the license you are allowed to run it.
An example from IoT world is the agent of IoT Hub that is offered by Microsoft. It is open source, is free and you can use it in any way you want. You can even modify it without problems. What you pay? The IoT Hub backend as a service. But 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 begging. Even the best software will be replaced in the end.

Comments

Popular posts from this blog

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Can User Technical Profile Influence AI Architecture Decisions?

In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see...