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

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP