As I mentioned in my previous article on agile assurance, to succeed in assurance means to be agile with the tools we use, the processes we follow, and the knowledge we exploit in order to address risks in a timely and proper fashion. But what does it really mean to be agile in technology usage? What are the cornerstones which can help us to achieve this state?
The starting point is that each assurance team uses a set of solutions which are provided by suppliers. Both parties play a sort of game, making investments whilst looking for a return. From the supplier’s side that means building a solution based on a given architecture to sell it to assurance teams. From the side of the telco assurance team that game involves implementing solutions that deliver gains. These gains emerge when risks are covered. But do these two players synchronize their turns?
We do not need to wait to learn how to answer this question. New realities mean we can take proactive steps towards deciding our own answers. To do that we need to re-think how the market between telcos and suppliers is organized. If you are on the buy side then traditionally you have to choose between different kinds of particular solutions provided by given suppliers. Some solutions are quite niche, being designed for specialized tasks. Others are designed to be combined together to deliver complex tasks.
Each supplier tends to create his own isolated ecosystem of solutions. This creates barriers for any customer considering an exit. This is an obvious way to save investments in the solution’s architecture. But what if there is another way to generate value from those investments without creating artificial barriers?
The buyer of these solutions cannot be made happy by being told they must keep buying new versions of the systems they already have. Assurance teams will keep a solution as long as they keep gaining value from having it. If we speak about the ability to be ready to respond to different kind of risks it means that the solution should be flexible enough. In other words it should be a bundle of solutions which can be easily managed, upgraded and re-combined.
In this scenario it is obvious the supplier which can provide core parts of this agile ecosystem is very valuable for potential customers, especially if those components are designed in a way that is friendly towards the extension of functionality by adding other components. A modular approach has many advantages. An application may become a plug-in for another application and vice versa.
Returning back to the market, it means that suppliers should deliver solutions which solve parts of a common puzzle, in contrast to each trying to provide complete and similar but incompatible solutions to different puzzles. A more connection-friendly solution will be able to deliver more value by remaining a core component of the evolving ecosystem of assurance tools used by the telco. This, in turn, means it is more likely that the solution will be purchased, increasing the returns for the supplier.
To be ready to address different risks means that any assurance team will be happy to have as many of these connection-friendly elements in their toolbox as they need. But how do we move the market in this direction?
First, we can begin by developing common standards which make sense and are valuable for all parties.
Secondly, we should define ecosystem principles of assurance on the telco’s side like the TM Forum Business Assurance initiative, for example.
Last, but not least, we must turn this idea into reality through the spending decisions made during the next investment cycle.
Ok, stop there. Are there differences between this approach and current activities on the market like discussions about API and microservices? The answer is yes, and maybe.
Current activities are more about putting rivals on the same page to make them interchangeable and be able to provide same tasks. To build an ecosystem based on different solutions is a more sophisticated task. This is about changing business models to monetize the value added to the whole ecosystem. But these changes are possible when properly managed and coordinated.
To meet the agile future we want, let’s leap!
