Are you ready to deal with continuous change?

In an earlier blog post, we already established that the key goal of Digital Transformation is all about being ready to change easily and continuously. We then followed up by applying this to the specific use case of a transition to IP in the media industry.

It has been shown that using a traditional project approach for a transition to IP inevitably leads to significant problems and challenges, despite the best intentions of all involved parties. Therefore, this type of transition should be treated as a Digital Transformation initiative, which consequently implies that there must be a very explicit goal from the outset to design a platform that can easily and securely evolve over time. 

Change is everywhere

Of course, the relevance of this is based on the supposition that change is indeed omnipresent. That’s why the operation has to be explicitly designed to accommodate that continuous change.    

And while the real-life lessons learned from early adopters (cited in the previous blog post) all revolve around a lack of readiness to deal with change easily and continuously, with this blog post, we want to further drive the point home that all these projects are all about being ready to run a continuous operation while being in a constant state of transition.  

When it comes down to transitioning to IP with a media operation, there’s a common saying that perfectly applies here: There are things you know you know, some things you know that you don’t know, and a whole lot of things that you don’t know you don’t know. And that’s the very reason that the importance of readiness to change is constantly vastly underestimated and overlooked by many.  

But how much change can there be? A whole lot more than you could ever imagine. That’s the whole point. Let us take a swing at it anyway. 

For starters, change spans across a multitude of categories. This includes:  

• software and firmware updates on all involved products   
• changes in baseline configuration of products  
• service-related changes of configuration of products  
• deployed products that need to be replaced (off-boarding)  
• products that need to be added for expansions (on-boarding)  
• new products that have to be integrated and introduced   
• operational, technical, or business workflows that have to evolve  
• efficiency and utilization of resources that need to be optimized   
• changes in the competitive landscape that impact operation  
• new customer expectations or opportunities that impact operation  
• business models that change and translate to operational changes  
• new specifications & standards that emerge and you have to adapt to  
• …  

That’s already quite a bit, and those are just a few categories to start with. However, it is not just about the many categories of change. The nature of the changes, their dynamics, the potential impact of each of them, and much more are of importance as well. Let’s take a closer look at some of the above-mentioned categories to further illustrate that. 

Change in practice: expect the unexpected 

My firmware updates can wait, right? ... right?

Everything these days, even products that are technically a piece of hardware, is centered around the software or firmware that it runs; software that needs to be updated. Here are some considerations linked to this first category alone.    

Firstly, whether it is related to new features, bug fixes, or dealing with security vulnerabilities, it becomes increasingly more important to roll out those updates as quickly as possible. The vast bulk of cyber incidents, for example, can be traced back to the exploitation of security vulnerabilities for which a patch already existed.  Instant deployment of updates is a major paradigm shift as compared to the past. 

The vast bulk of cyber incidents can be traced back to the exploitation of security vulnerabilities for which a patch already existed.

Secondly, you have many products from various different vendors. All of them work in ever shorter and more continuous development cycles. Because of this, more and more software updates are coming your way, all of them asynchronously from each other, as your vendors are definitely not aligned.  

The ripple effect of change

By now it might start dawning on you that change could be quite massive indeed.  And we’ve only gone over one of the categories. Because if you consider optimization of the utilization of resources, you will come to the same conclusion. And whether you focus on getting a proper return of investment (ROI) on the massive cost of a switch fabric, or keeping the invoice from your cloud service provider under control, or reducing your carbon footprint, it is all about continually optimizing utilization of resources, which inevitably translates to continuous change.  

By now it might start dawning on you that change could be quite massive indeed.

To wrap it up, there is one more extremely important observation that needs to be considered to conclude the topic of change, and that’s the nature of the operational systems, which has fundamentally changed compared to anything in the past. Cloudified, virtualized, and IP-connected platforms are complex ecosystems. And while this type of ecosystem brings us a lot of benefits, they also result in their very own set of challenges and characteristics that need to be accounted for.  

We’ll do a deep dive into that in a future blog post. But for now, know that they have so-called non-linear behavior. In practice, that means that even the most insignificant and trivial small change in the environment can become the root cause of a massive system-wide outage. Therefore, any of the many changes that we identified, represent a very tangible and real risk for the entire operation.  

Every week you can find evidence of how the smallest and most insignificant changes can result in the most unexpected, massive, system-wide outages, like one trivial change in a single router ...

It can happen to even the most respected, most experienced, and well-prepared organizations. Microsoft's services were back online after facing a downtime that lasted for more than four hours.

In an upcoming blog post, we’ll provide a deep dive into how to deal with change. This post will revolve all around Continuous Integration and Continuous Deployment (CI/CD), DevOps, Infrastructure as Code (IaC), and many other transformational concepts. This combined with agile development practices, automation at every stage of the software delivery process, and a collaborative culture that values rapid iteration and innovation.