Configuration: The Key to Agility for CSPs
Hansen enables service providers to launch innovative new products quickly and profitably, to capitalise on the opportunities presented through digital services. A key part of our philosophy is this: configure first and code only when necessary.
What does that mean in a world of fragmented systems and complicated product propositions? And, more importantly, why is it important to CSPs?
Let’s start by looking at the alternative. With systems that are developed without a configuration-driven functional framework, bringing a new product to market requires specialist support – which is expensive and time-consuming – to create code that makes things happen. The drawbacks are obvious: it places strain on resources, extends time-to-market, and adds another point where errors can be made. And it makes one ask: shouldn’t systems be able to carry these things out without the need for coding?
Furthermore, as more and more code is added to enable new products and services, system complexity increases, which can cause major problems during upgrades.
Coding to enable the creation and launch of new products slows down processes and increases costs – not a good thing, especially in the 5G era.
Using configuration-driven software to drive product innovation addresses this and means that authorised users are able to bring new products to market without the need for specialist IT support. Using configurable templates and rules, service providers can ensure consistency in the way products are created (including the related workflow to get things ordered), and the ability to reuse and modify existing elements can massively improve efficiency.
Of course, the user has to understand the processes to configure a product (and don’t worry, there is a lot of training for that), but by removing the need to code in the first place, the power to create new products and services can be given to business-facing users without the need for additional IT and systems support.
And this really resonates with our customers. We recently won a contract to supply products from the Hansen Create-Deliver-Engage portfolio for CSPs to an APAC mobile operator which, during the buying process, explicitly stated that it was specifically looking for a solution which enabled it to configure new products, while minimizing the need for coding to shorten time-to-market and improve flexibility.
Are we saying that it’s all configuration, all the time, for our customers? No, of course not. Acknowledging the realities of the industry, there will always be tasks that require coding, especially when it comes to integrating our software with systems and infrastructure either from other vendors, or within the service provider’s environment.
At Hansen, we believe in allowing service providers to protect their legacy investments, while we provide them with an agile overlay that positions them to take advantage of digital opportunities. That means we need to integrate with these legacy systems, which have been built up over time and are unique for each CSP.
This integration with external systems is a key component of any implementation of our software. And writing some specific code for these integrations is often the most efficient way to deal with the unique aspects of every deployment.
Key to minimizing the impact of this custom code is the ability for our products to provide frameworks wherein these specific code-based customizations can occur, while keeping them separate from the core product. This allows control over the impact of these customizations, and also makes the process of upgrading the underlying product software much easier.
So to truly deliver on the value of the configure first and code only when necessary ethos, these coding situations need to be around the edge of the application – not the central logic of it.
And that is what we have delivered at Hansen Technologies – the core domain of the products and the key use cases are all delivered through configuration and our model-driven paradigms.
When that core capability needs to be connected to other systems in the enterprise, or some very implementation-specific edge cases are required, then coding can be used, and the different skill sets of different classes of users can be brought to bear.
Coding in this sense is a fact of life, but Hansen believes that coding should not define your product innovation capability when creating products, or when defining the workflow to order products and services.
For service providers, perhaps the key question is how much is configuration, and how much is code, rather than looking at this as a simple, black-or-white issue. This is a question which should be asked for all stages of a project – from implementation through to everyday use. At Hansen Technologies, “configure first and code only when necessary” is a philosophy that runs throughout our portfolio, and is a central consideration when it comes to how we build software.
Senior Vice President of Engineering