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 check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

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

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…