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.

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.


Popular posts from this blog

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 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.51EF 6.0.2VS2013
It seems that there …

Fundamental Books of a Software Engineer (version 2018)

More then six years ago I wrote a blog post about fundamental books that any software engineer (developer) should read. Now it is an excellent time to update this list with new entries.

There are 5 different categories of books, that represent the recommended path. For example, you start with Coding books, after that, you read books about Programming, Design and so on.
There are some books about C++ that I recommend not because you shall know C++, only because the concepts that you can learn from it.


Writing solid codeCode completeProgramming Pearls, more programming pearls(recommended)[NEW] Introduction to Algorithms


Refactoring (M. Fowler)Pragmatic ProgrammerClean code[NEW] Software Engineering: A Practitioner's Approach[NEW] The Mythical Man-Month[NEW] The Art of Computer Programming


Applying UML and Patterns (GRASP patterns)C++ coding standards (Sutter, Alexandrescu)The C++ programming language (Stroustrup, Part IV)Object-oriented programming (Peter Coad)P…

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…