API-led integration for AltNets and MSPs

As companies of any size and industry grow, so does their IT ecosystem. While the number systems and applications remains small, integrations can easily be developed and managed with custom code. As more systems and applications are added however over time, custom coded integrations can become a bottleneck. IT teams struggle to deliver at the speed required by the business, whereas luck of governance can hinder business continuity.

An API-led approach to integration allows you to connect data to applications through reusable and purposeful APIs, bringing much needed speed, agility and cost efficiencies so IT can become a growth enabler for the business.

This approach has already been adopted by companies across industries, but in this blog we wanted to focus on the benefits APIs can bring to the rising disruptors within Telecommunications -AltNets and Managed Services Providers.

We asked Trevor Hackett, makepositive’s Business Lead for the Telecommunications Industry, to give us some examples:

Deploying Salesforce Communications Cloud

An AltNet is looking for an initial deployment of Salesforce Industries Communications Cloud to handle sales, marketing and Quote-to-Order journeys. This requires integrations between Communications Cloud and the wider estate to answer key questions such as “can I get FTTH access Broadband service at my house?”, which requires a check against Resource Inventory (you can now) and possibly also a view from Planned Build (you can from next month onwards).

Transformation is occurring in the Resource Inventory and Plan and Build estate at the same time. We COULD build Salesforce Industries Data Raptors / VIPs to integrate into Resource Inventory / Plan and Build platforms directly, and change those definitions as transformation occurs (e.g. upgrading to a new Inventory platform with different APIs), but the better answer is to use MuleSoft. By adopting an API-led approach to integration, you can:

• Build Salesforce Industries Communications Cloud DR / VIP integration to a ‘Dialogue Service’ that answers the question for us without requiring direct connection to systems in the customers estate (e.g. Resource Inventory platform)
• Build the Dialogue Services in MuleSoft, supporting the quickest possible:
  • build/change of integrations into the target platforms (e.g. Resource Inventory platform)
  • orchestration of multiple calls to different platforms to answer the question, handling of business logic to interpret the response and provide an answer back to the caller of the Dialogue Service (e.g. Salesforce Industries Communications Cloud)

By taking this approach, as the wider customer estate is transformed:

• • No change is required on the Salesforce Industries Communications Cloud side (DRs/VIPs to the Dialogue Services remain the same)
  • All required change occurs on the Dialogue Service side, realised in MuleSoft (the best tool for the job)

Creating connected supplier and partner ecosystems

An AltNet wholesaler needs to expose APIs to Retailers and possibly also Retail Mediator platforms to support their Order Journeys. These are to an extent standardised (TMF), but there can be variations in implementation. With MuleSoft, they can quickly build scalable, flexible APIs exposing Wholesaler capability (starting from TMF template APIs) with embedded security.

Another example of how APIs can optimise the partner and customer experience is with a Managed Service Provider (MSP) who sells connectivity services to their business customers. Under the hood, these could be provided by the MSP themselves or by one of a number of possible partner providers (e.g. Openreach, CityFibre).

This makes the ‘Availability Check’ for the MSP (can I have service to a premise) quite complex. It needs to:

• Check with local platforms to determine if the MSP can provide service themselves (‘on-net’), what flavours of product are possible (e.g. 100M, 400M but not 900M) and what work needs to be done to complete provisioning (e.g.half a days’ work for an engineer working outside and inside the premise).
• Check through (often subtly different) integrations to different partners (‘off-net’) to see if they can provide service, and again figure any constraints on the product and what work needs to happen to complete provisioning. This requires an array of APIs to be quickly defined, API calls to be orchestrated and business logic to be enforced in answering the ‘Availability Check’ Dialogue Service question.

MuleSoft is the best tool for the job – consider also that the MSP might want to quickly onboard a new partner, meaning that the Availability Check Dialogue Service would have something new to integrate into and new business logic to reflect.

So in summary, what is the key ‘secret sauce’ of MuleSoft here?

• It can support rapid implementation / change for APIs (don’t emphasis the point, but it’s better at doing that than SFI CC integration tools such as DRs and VIPs). It also has a library of TMF-aligned integrations and platform-specific integrations to work from, which helps to get you there even quicker.
• It can support rapid definition of orchestration / business logic necessary to handle calls to multiple platforms and provide a simple / coherent answer to the calling platform (again, better than SFI CC DRs / VIPs would do it).

Where do we really see this shine?

• • Where there is a lot of transformation going on around us in the customers’ estate
  • Where the customer wants to rapidly reconfigure their supply chain – to suppliers (MSP new partner example), to customers (alt-net Wholesaler integration to Retailers / Mediator platforms example)