By: Borko Barić, MBA
Who is it for: stakeholders, managers in IT, solution/software architects.
Having worked for telco operators most of my working life, I have met many wonderful people, and have come face to face with many industry processes. While they do differ in some way from operator to operator, they do have one thing in common: boy are they hard to change.
Let’s explore why …
In pivotal scene of recent mega-blockbuster Avengers: Endgame, the characters are discussing what everybody knows about time travel, what are its rules and principles, until they are warned that it simply doesn’t work that way, which prompts one of the characters to proclaim “So... Back to The Future's a bunch of bull****”.
What was it that made me recall this slander against possibly the greatest movie of all time? It’s the ever-present principle of “everybody knows this, this is the way it’s done”.
Each attempt at change will be met with resistance. This is true for every aspect of human life and, although Information Technology is usually (rightfully) perceived as inherently agile and ready to embrace change, the practice often contradicts this. Massive monolithic systems (a label which covers most communication service providers), operate at their own pace and, even though they constantly introduce new products and offers, deep changes are very hard to implement. The main obstacle towards modernization is, was and forever shall be in people’s mindsets. Both management, operations and sometimes even development can get complacent and used to the way things have “always” been done, accepting only minor incremental changes, and thoroughly rejecting the idea of a true upgrade. Modernization without immediate visible results is always a hard sell, so it’s necessary to ease it up as much as possible.
The core question is, as always, WHY?
Why are you changing your system? Does the rival company have cooler apps? Are you simply bored with your “so-last-year” interface? Or do you truly want your system to be more adaptable to the forthcoming challenges posed both by market needs and technological progress? Although it may seem trivial, the answer isn’t always as obvious as it should be, and not being aware of the true reason for change can cause multiple problems or even failure of the entire project. Once all the stakeholders (especially business and operations) are on the same page, we have the foundation for a successful project.
The first step is to avoid “big bang”. (topic covered by our CEO Ivor Bakša)
Big, all-encompassing deliveries have a very high probability of failure, and very little options for fallback and rollback. Iterative transformational improvements should be a preferable way to go, enabling a lower fault rate, as well as making the transition towards something new more gradual.
One tool which can help us with incremental transition is OpenAPI. OpenAPI is a set of standardized framework APIs which can be utilized for any type of product, service or resource. They are being administered by TMForum, a global association of service providers and their suppliers, which makes OpenAPI a crowdsourced tool suited for efficient and agile business development.
Example of iterative transformational improvement can be wrapping the existing legacy interfaces in OpenAPI. This way development on front end and back end can be done almost independently, maybe even by multiple vendors, while switching from a legacy system or module to a new one can be done in a mostly painless way.
The key word here is “mostly”. OpenAPI interfaces were created to make integration easier, but the aforementioned mental block shows its physical form here. Wrapping legacy systems in OpenAPI will require a change in approach for developers, and it may not come easy. Legacy and OpenAPI models most likely differ significantly, and the effort to transform them can be substantial. Now it’s important to remember the unifying “why”, which should ease the transition and help find the motivation to implement the changes.
And this leads to another important guideline - don’t try to reinvent the wheel. The change is not its own purpose. Sometimes the developers can get carried away playing with their “new toys” and waste time and money trying to replace perfectly good components just to make them “more modern”. New technologies are shiny and attractive, but one must not lose focus of the main goal - to keep a stable and functional system for existing clients and create a landscape more adaptable to changes.
The change IS gonna come. The system will need to be improved. The processes will need be modernized. It just won’t be easy, and everybody involved will need to adapt. Adaptation is what lead us here since our ancestors left the water, and it will keep us on top of the world, be it business or otherwise, for as long as we live and breathe.
Of course, no solution is either perfect or permanent. There will be bugs and issues even in the shiny new system we have just implemented. In time, new principles will become old principles, and the wheels of change will have to turn again and again. The important thing is never to lose focus of the true reason for change.
Back to the Future series ends with an inspiring message: the future is not written, it is whatever we make of it. Making a change on a big system shouldn’t be done just to appease the present needs, it should also create a new future. So let’s make it a good one.