George Glass, Chief Systems Architect, BT, describes how to design a platform – and what you can do with it when you do it right. He was speaking at TM Forum Live! in Nice.
Here’s that description:
A platform consists of a set of related systems, processes, people and data that deliver (or expose) a set of business services via a standard set of application program interfaces (APIs). They should follow a logical model: BT’s follows TM Forum’s Frameworx – that is, the Business Process (eTOM), the Application (TAM) and Information (SID) Frameworks – to determine where the boundaries of your platform need to be.
Setting the boundaries right is important because it means you can build components that allow platform services to be implemented independently of each other. Platform is a means of sub-dividing, or logically partitioning, your architecture into sets of related business services, provided by the people, processes and systems associated with your IT estate (see graphic below). The platform’s business services are represented by an API or sets of APIs, which expose the business services in a consistent and predictable way.
Nested APIs fledge new business
Glass explained how the APIs are “nested by nature”, saying, “The more complex, for example those for orchestration, pass decomposition rules into each API and can be different for each product. The higher level has complex business processes and call the simpler, lower level ones, which call those for ‘fire-and-forget’ [the simplest] tasks.”
The APIs can hide the complexity of a platform, and in fact you may not even have a platform behind your APIs, but just look like you have. BT APIs are either closely aligned or exactly aligned with TM Forum’s Open APIs – the only ones that are not exact were deployed before the Forum’s API Program was created with BT as a founding participant.
Transforming the legacy IT estate
“We have used this model extensively to transform legacy and build a platform incrementally,” Glass said. “From my perspective we’ve been able to transform the cost base. If you want to be truly agile and part of a digital ecosystem, you need APIs and platforms in your business.”
By mid-2016, BT had reduced its IT systems from 4,500 to 1,600, but the number rose again dramatically when the company acquired UK mobile operator EE, which itself was formed by combining Orange and Deutsche Telekom’s British operating companies. “It was a bag of bits because it came from [two companies]but we got stuck straight in, using exactly same model as previously to simplify our IT estate,” Glass said. The company is again making excellent progress and expect the number to be back below 2,000 by the end of this year.
Using assets to enter new markets
But platforms aren’t just about becoming leaner and realizing substantial cost savings; they are about opening up whole new revenue streams.
“If you have a platform-based business, you can rapidly adjust to cope with new business or financial models,” Glass commented. “Using APIs, you can construct new businesses using things you didn’t realize could be deployed in other contexts.”
He gave the example of exposing the mapping and location system BT uses to manage its field engineers. “We took the same APIs, wrapped them in a service and now, if you’re in the UK and you break your windscreen, the company you call is Autoglass to fix or replace it. Autoglass uses the service/API to find you,” he explained. “So platform allows you to move in a totally different market. If you abstract services like that, then you can build platforms and leverage value… Implement once, test once, reuse multiple times.”
Watch out for network effects
The reason that platforms are the most successful business models ever (the world’s top five companies are all platform companies and have displaced banking and oil companies which previously dominated the top slots for decades) is due to network effects. Put simply, the more parties are on your platform, the more people and companies they can reach, and the more effective everyone can be. This leads other to join. If you think about it, telcos are old hands at understanding network effects because in telephony, two phones allow one connection, but 12 phones allows 66.
And as Glass stressed, care is needed, because network effects can work in a negative way too. That’s why BT builds a monitoring and measuring capability into its platform-enabled applications. For example, it built a directory enquiry service for people to find phone numbers, but then outbound (cold calling) call centers started to use the service.
“Instead of hundreds of calls per second we ended up with many thousands,” Glass said. “So we throttled [limited]the service and now we charge for [commercial use of] it. You must put in measuring and monitoring around [applications], or that would kill your business model with huge costs.”
A final word on microservices, preserving plug and play
A member of the audience asked how exposed services are related to microservices. Glass replied that microservices are just ‘read’, ‘write’ and ‘search’ content commands within APIs: “There are hundreds if not thousands of microservices because we’re at the stage of having several hundred APIs and every one of them has four or five microservices, so it becomes quite complex and you have to manage the API measurement.”
Glass said he would love to see a “concept platform” adopted by telcos to limit suppliers’ implementations.
“Whenever we get into a new market…vendors move in and start to build stuff,” he explained. “What some have done is have some functions straddle the service management domain and the resource management domain. That doesn’t work well in my architecture because I’ve got loose coupling between those domains and between platforms, and hold a logical inventory that refers to physical and digital infrastructure… I want to have the physical inventory associated with both VNFs and physical network functions and stay loosely coupled.
“My plea to vendors is to read TAM [the Application Framework]and see where boundaries are between the platforms,” Glass concluded. “Applications sit above or below, so if a vendor builds one that straddles the boundary, we can’t plug and play.”