Originally posted on 30Aug17 to IBM Developerworks (11,517 Views)
Across many industries, including the Telecommunications sector, there seems to be a strong movement towards a MicroServices Architecture and (somewhat) away from Service Oriented Architecture. I’ve seen this move in a CSP here in Australia. The TeleManagement Forum have a significant project that is trying to standardise the REST APIs that a CSP might publish.
The TMF state:
“TM Forum’s Open API program is a global initiative to enable end to end seamless connectivity, interoperability and portability across complex ecosystem based services. The program is creating an Open API suite which is a set of standard REST based APIs enabling rapid, repeatable, and flexible integration among operations and management systems, making it easier to create, build and operate complex innovative services. TM Forum REST based APIs are technology agnostic and can be used in any digital service scenario, including B2B value fabrics, Internet of Things, Smart Health, Smart Grid, Big Data, NFV, Next Generation OSS/BSS and much more.”
“TM Forum is bringing different stakeholders from across industries to work together and build key partnerships to create the APIs and connections. The reference architecture and APIs we are co-creating are critical enablers of our API program and open innovation approach for building innovative new digital services in a number of key areas, including IoT applications, smart cities, mobile banking and more.”
Laurent Leboucher, Vice President of APIs & Ecosystems, Orange
I’ve been a part of a number of projects where these REST APIs have been exposed primarily to a CSPs trading partners – my very first Service Delivery Platform exposed APIs to external developers. Back then, it was Parlay X Web services (REST didn’t really exist and certainly there to external developers.were no Telco standards in place for REST based interfaces) that exposed the functionality of network elements to 3rd party developers. With many of the APIs that the TMF have defined, they seem to be more focused on OSS/BSS functions instead. Now that the TMF have quite a number of Open APIs defined, there are some network focused APIs that are coming onto the list – for instance, a Location API would have typically be exposed using the ParlayX Web Services or ParlayREST REST interfaces to the network’s Location Based Server (LBS). As a result, there does seem to be a small amount of crossover between the new TMF APIs and the older ParlayREST APIs.
Does this mean that the new TMF OpenAPIs are of no use? Not at all. There are certainly advantages to exposing functions that a CSP has to external developers and REST based OpenAPIs make the consumption of those functions easier than the ParlayX web services or Parlay CORBA services have been in the past. Ease of consumption is not to be underestimated. An API that is easy to include in an application and provides a real capability that would have been otherwise difficult to provide stands a much greater chance of wide usage.
Sure, there is a place for externalising the OSS/BSS functions of a CSP. Trading partners could place orders against a CSP, they could bill to a subscriber’s post or pre-paid accounts, they could update the subscriber profile held by the CSP. All relevant use cases for externalising the TMF Open APIs.
The big question in my mind is will REST APIs be of use internally?
REST based APIs being easier to integrate internally will drive some value. But in CSPs that have significant investments in a Service Oriented Architecture (SOA), I’m struggling to see the business value in abandoning that in favour of a MicroServices Architecture where there is no common integration tool, no common orchestration capability, rather lots and lots of point to point integrations through REST APIs.
For those of us that have been around a while, you will have seen point to point integrations and the headaches they cause – complex dependencies in mesh architectures make maintenance hard and expensive. Changing a (say) billing system that is integrated through multiple point to point connections is a nightmare – even if they have a standardised API describing those interfaces. The plane truth of the matter is that not all of those interfaces will be adequately described by the TMF’s Open APIs, so custom specifications APIs will arise and make swapping out the billing system expensive. Additionally, not all of a CSPs internal systems will have TMF Open API compliant interfaces – many won’t even support REST interfaces natively. Changing all of a CSP’s systems to ensure they have a REST interface is a non-trivial task.
A Hybrid environment may be needed.
I’d suggest that a Hybrid approach is needed – existing Enterprise Service Busses may be able to interface with REST APIs – certainly IBM’s Integration Bus and the (now superseded) WebSphere Enterprise Service Bus could connect to REST APIs just as easily as they could connect to Web Services, Files and other connectivity options. The protocol transformation capabilities of a ESB are able to provide REST APIs to systems that would have otherwise not supported such modern interfaces. Similarly, where a function is not provided by a single system, a traditional orchestration (BPM) capability can coordinate multiple systems to provide a single interface to that capability even if (behind the scenes) there are multiple end point systems involved in providing the functionality of that transaction/interface. The diagram below shows my thinking of what should be in place….
