next generation service platform summary 2015
TRANSCRIPT
Next Generation Services Platforms Munich 17/18th June 2015
The Telcos winning the migration to service providers have understood and internalized API Management operations, and are now focused on mashing up local capabilities in an open ecosystem as no problem is solved through just one providers APIs. But remember APIs are just a small piece of technology, the solution is much broader then simply presenting APIs to internal groups, partners, 3rd parties and customers.
Structure
• Dean Bubley WebRTC update o 6B WebRTC- capable devices by 2019
• Dragana Linfield, Etisalat o Etisalat Digital Case Study, Leveraging WebRTC to extend digital
communication services • Francesco Vadalà & Vincenzo Amorino, Telecom Italia
o Future Strategies and the Impact APIs has on Telco Industry
• Sebastian Grabowski, Orange Poland o BIHAPI Business Intelligence Hackathon API
• Michal Ajduk, Play Poland o Play API, Enriching 3rd Party Services with Operator Capabilities
• Antonio Cruz, SAPO o API Management Patters
WebRTC Market Status & Contextual Roadmap
Dean Bubley, Disruptive Analysis
NGSP, June 2015
[email protected] @disruptivedean
Any web-connected device will be WebRTC capable over time. Main limitation today is the lack of IE and Safari WebRTC support, plus its not yet a ratified standard.
WebRTC on >6bn devices by 2019
Million WebRTC devices worldwide,
year-end
Source: Disruptive Analysis 2014 Edition WebRTC Report
0
1000
2000
3000
4000
5000
6000
7000
2011 2012 2013 2014 2015 2016 2017 2018 2019
Other (TV+M2M/IoT)
Smartphones
Tablets
PCs
Copyright Disruptive Analysis Ltd 2015June 2015
Lead WebRTC use-cases, June 2015
Copyright Disruptive Analysis Ltd 2015Source: Disruptive Analysis WebRTC report update June 2015
Customer service & platforms• Mayday, Amex etc.• Contact centres• Developer SDKs/platforms
• Mobile consumer VoIP & social chat• Education/training/healthcare• Free standalone video-calling• Conferencing niches & web extensions• Innovative UC & collaboration
Live & commercial
• Full-scale corporate conferencing & UC• Telco VoLTE/IMS extension• CDNs, File/screen-sharing
Pilots /pre-
commercial
Trials & demos
• Entertainment & consumer electronics• IPTV & personal broadcast• M2M & IoT• Public Safety
What is interesting in some ‘WebRTC’ implementations is they use the technology with customizations in their own container rather than relying on the browser. This reflects the pre-
standards status and patchy browser coverage. Plus highlights the lack of importance interoperability plays in most use-cases.
Telcos & WebRTC: growing fast
Copyright Disruptive Analysis Ltd 2015June 2015
Developer / PaaS
Service extension
Verticals / New services
Not yet commercial
European SP videoconferencing
and many others
Asian MNO dev pltfm
Integral to some iOS RCS apps
Asian MNO chat app
Growing WebRTC adoption by Telcos, beyond simple experimentation.
| 1
Etisalat Digital Case Study
Leveraging WebRTC
to extend digital communication services
Dragana [email protected]
| 4
Etisalat introduces HD voice and video calling with new C’Me app
http://7daysindubai.com/etisalat-introduces-voice-and-video-calling-with-cme-app
http://ameinfo.com/technology/it/software/etisalat-introduces-hd-voice-and-video-calling-with-new-cme-mobile-application/
C’Me is a proprietary IP Communications Client – we’re seeing more telcos follow this path given RCS and VoLTE’s costs and delays.
Supports most of the common IP Communication features. Main challenge is interoperability with other telcos if its to offer a traditional telco comms proposition, and if
it does not, then the value proposition will be limited by limited community.
|
• Existing Etisalat MSISDN works on any device•Android/iOS (smart phone/tablets)• App to non app calls• Existing billing relationship for prepay/ post pay• English/Arabic language
6
Etisalat C’Me: Communicate from any device with your mobile number
• Social Networks: Follow your social media messages (e.g. Twitter) in one app
C’Me is a Single identity, multi device unified communication solution that allows user to access rich portfolio of services using their smart phones, tablets and PC/MAC over any network.
‐HD Voice/Video Call‐Rich Chat with live video window: ‐sharing (location/PTT etc.),‐Group chat, Stickers‐ Send SMS from C’Me
Etisalat are using WebRTC to extend traditional comms services as well as offer them through APIs to be used within apps, services and business processes.
| 9
Etisalat WebRTC Platform – Telephony made simple
� A cloud‐based platform enabling Etisalat to deploy new
services based on Comms APIs and accelerate innovation.
� This will allow voice, messaging and real time presence to
be consumed in a new and more exciting way.
� Simplifies complexity and technology barrier involved in
providing a communication services for the application
developersObjectives:1. Develop and rollout new communications‐enabled services.
2. Bridge between Web and Telco services
3. Address Enterprise and SME market
4. Expose APIs (Voice, Messaging) and start engaging regional
developers to develop apps
Similarly extending C’Me and exposing capabilities through an API
|
� WebRTC can help C’Me to extend reach to anywhere, any device, any network and any time
� Extend Network Capabilities to reach SIM‐less device (browser , PC, social networks)
� Opening to Innovation‐ expose C’Me API through WebRTC to regional developers to develop innovative services
11
C’Me – browser integrated communication experience
WebRTCPlatform
WebRTC opportunity: Extend the reach of C’Me
The challenge with this use case remains channel to market, other people than telcos appear able to sell it. While Telcos struggle.
|
PLATFORMFORFUTUREINNOVATIONATWEBSPEED
• A seller doesn't want to reveal his number.
• Subscribe to a privacy service ‘Call Me’ button.
• Control when to receive calls. Notification by voice message/ email/ SMS.
• Buyer simply ‘Clicks to Call’
• When the car is sold, ‘Call Me ‘ button is deactivated.
13
Seller set-up Page
Call me
Buyer Page
Call Me from Web Browser – Give customers privacy and control
Future Strategies and the Impact APIs has on Telco Industry
TELECOM ITALIA GROUPNext Generation Service Platform – Telecom API - 2015Munich, 17-18 June 2015
Vincenzo Amorino
Francesco Vadalà
The Telecom Italia Experience
SmartPipe & NetAPI dept.
5
Telecom Italia API project is one of the longest continuously operating programs of any Telco. Recent focus has been on processes, and has seen significant internal uptake in APIs.
While the focus in 2016 will be on making money through the services made possible.
6
Significant rise in API use – mainly internal consumption to 2B per month
11
Conclusions
• Telecom Italia Network API Platform is not a "black box", rather it is an approach to platform design and service integration built and evolved over the years.
• The Network API Platform plays a key role inside the Telecom Italia, by increasing abstraction through functional decomposition while ensuring security, performances and differentiated SLA to fulfill heterogeneous (internal and external) third party needs and business models
• The API approach is somehow stabilized and the Network API Platform has allowed to explore new business relationships and promise to enable more and more smart usage of the network resources.
• It is time to consolidate our experience, and make it more fruitful
Keep it easy
Telecom Italia’s update on Network API PlatformFrancesco Vadalà, Vincenzo Amorino, Smart Pipe and NetAPI
Telecom Italia has been on a long journey with APIs, but they now feel confident to use APIs across all aspects of their business to drive new revenues. Not API platform is am approach
to design and service integration – significant organization learning.
BIHAPI Business Intelligence Hackathon API
II edytion (2014-215)
BIHAPI shows the importance of taking a local focus and mashing-up APIs
BIHAPI
Business Intelligence Hackathon API
Open Data, Telco&Web APIs, WebRTC OpenMiddleware Community
For whom: Developers, SME, SOHO, Startups, Geeks, Students…..
3 cities Warszawa Poznań, Gdańsk
3 finalistów wizyta.pl PublishSoSimply Sesame+
20 partners
16 members of jury
22+ warsztaty konsultacje dostęp do infrastruktury Ministerstw
o Administracji i Cyfryzacji patronage
33,5k PLN awards
3 finalistów wizyta.pl PublishSoSimply Sesame+
81 APIs 36: Orange PL 30: Warszawa 11: Poznań 4: Gdańsk
101 ideas 28 PoC
BIHAPI
Business Intelligence Hackathon API
Ecosystem based approach
Multi-technology – real world is not just one vendor’s APIs
BIHAPI
Business Intelligence Hackathon API
OCSG
api.orange.pl
SMS
ZTE SDP
USSD
Payment AccMgmt
IKEA
Call Services
OpenCloud JSLEE
Terminal Status
Warsaw WMS
Historical Maps
MySQL Database
Public Transport
Location MMS Adaptation
Telco Domain
City Data Domain
Main Platform
Security SLA
Warsaw WFS
Veturilo P&R
Gdańsk WMS
Hypsometric Maps
Poznań Web Services
Busstops Events
Warsaw Web Services
Queue
NGW Mobicents
Cell ID Status HLR
Open Data GW
WFS WMS
Michał Ajduk [email protected]
Play showed a solid grasp of how APIs apply across their business 11 Play API
Proof of concept
Internal Service
Partner service
70% API use is internal and 30% is with partners, with no long tail use - nothing new!
PoC
3rd party
Internal & MVNO
Net API – 100mln requests / month
They are also taking an open approach – Poland is going to be a hot-bed of innovation. 16 Play API
Service Delivery… Framework
Trusted 3rd parties with ready services,
not mythical long tail developers Trusted, FLEXIBLE, technology partner
Enriching working services 70% API use is internal and 30% is with
partners
Billing, Auth & User Profile API is a Key!
Messaging and Voice services are nice to
have’s
APIs between departaments (eg. IT <->
Billing <-> Core Network) – Amazon
approach
API Management Pa,erns
with Service Delivery Broker
António Cruz
Next Genera1on Service Pla7orms 2015
This is an important presenta<on as it consolidated much learning from SAPO on API Management. They’ve built up a plaGorm using open source, its an important model for other telcos that wish to
take control of their future.
The API Management Momentum
API Management Solu6ons Today
• The capabili<es found in many of API Management solu<ons today go way beyond the Web services Catalog commonly found in classic corporate SOA solu<ons, aka “ESBs”: • Not only XML, SOAP and WS-‐*, but especially REST and JSON, and performs transforma<ons between any of those.
• Authen<ca<on and authoriza<on, using OAuth and OpenID Connect Web standards.
• Support to most of IT management processes that are relevant to the API lifecycle.
• Portals for community/product ini<a<ve/program. • Real-‐<me sta<s<cs/no<fica<ons on APIs usage, health, performance and SLAs.
• APIs mone<za<on, stores and open business models. • Scale efficiently as a mul<tenant cloud service. • Perform a strategic role in Enterprise Business Architecture.
API Management Context
• Agile reu<liza<on and integra<on of business capabili<es in both internal and external par<es projects. • Processes and culture change, resources standardiza<on, infrastructure consolida<on, costs reduc<on. • Strategic posi<oning, innova<ve P&S, new business models, data assets, improved customer experience.
TM Forum Digital Services
Reference Architecture
IoT Reference Architecture (example)
Analysis Mason SDN/NFV Reference Architecture
Portugal Telecom Service Delivery Broker
SDB Ecosystem Today
SDB delivers APIs to a broad portfolio of apps developed by PT and its partners.
23% GROWTH YoY
40M API
CALLS DAILY
750 APIs
1.2B API calls per month (mostly web-‐based not network based), on a per subscriber basis is twice that of Telecom Italia. With strong growth of 23%
About API Management Pa,erns
• Design paderns are (only) “proven solu+ons to commonly occurring problems”. • They are not “silver bullets” nor “magical recipes”. • Generally, paderns are discovered/recognized by real-‐world experience of solving the problems, not “invented” or “created”.
• Paderns are valuable essen<ally because they enable a common language to debate, approach and eventually solve problems. • API Management paderns help to understand the current Enterprise Architecture state in an organiza<on, and what can be done about it.
Service Design
Con6nuous Delivery
• PROBLEM: The end-‐to-‐end process of developing and releasing soeware is oeen long and cumbersome, it involves many people, departments and obstacles which can make the effort needed to implement Con<nuous Delivery to seem overwhelming.
• SOLUTION: Iden<fy the goals, establish the processes and a plaGorm that will enable evolving in the right direc<on. This plaGorm includes adop<ng specific principles, tools, methods and prac<ces. A maturity model helps to understand the actual state and iden<fy paths to progress.
BUILD
DEPLOY
TEST
REPORT
External by Design
• PROBLEM: Any business capability only used internally in the organiza<on today may be required to be externally exposed in the future, e.g. in order to enable new business models. However, tradi<onally in the organiza<on, architectures, standards and tools used to implement solu<ons for internal consump<on, are different from the ones applied when the solu<on is targeted to external par<es or customers, e.g. outside the corpora<on firewall. This differen<a<on creates a burden in maintenance, makes more complex to access internal resources from external applica<ons, and difficults the reposi<oning of internal solu<ons in an external context.
• SOLUTION: All services and applica<ons must be designed with built-‐in ability to be externalized at any moment. Using the same architecture and technologies for developing both internal and external APIs and applica<ons, the reu<liza<on poten<al of internal assets is greatly simplified, e.g. only requiring to provision a new configura<on.
Enterprise API Catalog
Service Delivery Broker
IT Resource
s Data Physical
Resources
Domain APIs
Custo
mer
Emplo
yee Partne
r
Real-‐Time
• PROBLEM: Users will not wait long for anything, par<cularly mobile users expecta<on is to have what they want immediately, or in a few seconds.
• SOLUTION: Every service must be designed with user experience in mind, and that means designing and developing service APIs able to fulfill the real-‐<me expecta<ons of users. Real-‐<me is a transversal quality required in Enterprise Architecture, and is not restricted to a specific type of services or data. When interac<ng with a Real-‐Time Enterprise, the user will get any of his Products and Services immediately provisioned and configured aeer subscribing, immediate understanding and feedback upon his problems, and proac<ve offerings that make sense to his lifestyle and needs.
Mul6tenancy
• PROBLEM: Both for business and opera<onal reasons, it is desired to enable resources sharing, such as an applica<on and its database, and being able to deliver both to a group of tenants (customers) in a way that each tenant’s data is isolated and remains invisible to other tenants.
• SOLUTION: The applica<on logic must decide how to iden<fy and flow tenant iden<fica<on on every request, and most database tables must include a tenant ID column.
Standard Management API
• PROBLEM: APIs and applica<ons usually do not explicitly expose management capabili<es such as their own health status, neither no<fy their dependencies failures, nor follow a standardized approach when implemen<ng those capabili<es. Monitoring systems are thus generally coupled with APIs func<onal interfaces, use them to assert health of both APIs and applica<ons, and generally only respond reac<vely to incidents.
• SOLUTION: Beyond their func<onal interfaces, APIs and applica<ons may offer a standardized management API interface that will enable monitoring systems to act proac<vely upon problem no<fica<ons and predict poten<al incidents.
User Applica1ons
Monitoring Systems
APIs (e.g. News)
Network &
Devices (e.g. SMS Gateway)
Physical Resourc
es (e.g.
Database)
API
Management
Interface
Func<onal
Interface (e.g. GetManagementReport) (e.g. GetNews or
SendSMS)
PlaEorm & Infrastructure
Collabora6on Lifecycle
• PROBLEM: Service lifecycle management is a complex process that impacts provisioning, assurance and opera<onal readiness. When not done efficiently, nega<vely impacts the customer experience and the <me-‐to-‐market of new products and services.
• SOLUTION: Successfully managing the lifecycle of every service API requires that several persons/teams collaborate efficiently. Segment user experiences based on simple and well-‐defined tasks, according to their responsible roles, and whenever needed to advance the process flow, inform ac<ons and decision required through event-‐driven no<fica<ons and status reports.
Process Automa6on
• PROBLEM: When performed manually, tasks tend to be repe<<ve and tedious, introducing undesired latency into processes, drama<cally raising the risk of errors, unsa<sfac<on, and cost.
• SOLUTION: By exposing APIs, automate as much as possible all the manual ac<vi<es that are cri<cal to the business. Automa<on is a game changing road, leading to many organiza<onal, process and cultural challenges. Poten<al candidates for process automa<on generally include, but are not restricted to: 1) IT development ac<vi<es; 2) BSS/OSS provisioning and configura<on of all physical and logical resources; 3) Enablement of self-‐service experiences to customers, internal IT requests, and partners on-‐boarding.
Mul6channel
• PROBLEM: Users aden<on is disperse over different channels and they prefer experiences that are cross-‐channel, e.g. mobile, Web, TV, etc.
• SOLUTION: Products and services should be designed to support mul<channel experiences from the start, so that instead of compe<ng, channels can become complementary, e.g. using a tablet to control a Video-‐On-‐Demand service, or the Web to create TV playlists. This can be done semng up small mul<disciplinary teams that are specially assembled/consulted for the dura<on of each specific project.
Cloud Service
• PROBLEM: Adding more resources (e.g. CPU and/or memory) to a physical server in order to increase a service performance (ver<cal scalability, or scale-‐up) is limited by the capacity of that server, and in many cases this will not be cheap and/or possible.
• SOLUTION: Services must be designed to allow the addi<on of redundant servers in a Virtualized environment, with the same func<on, so that they can scale work without exponen<ally increasing costs, as a single logic en<ty, thus enabling to increase service performance whenever needed (horizontal scalability, or scale-‐out). Adding on that, elas<city is also an important capability, so that only the resources effec<vely needed are allocated and will be charged.
Mul6tenant Load Balancing
• PROBLEM: A service implementa<on on a single server has a finite capacity. To address this problem, redundant deployments of the service are created and a load balancing system over a servers farm is added to dynamically distribute workloads across service implementa<ons. However, the customers of a mul<tenant service will have different performance requirements, but there is no way to dynamically configure and balance their requests accordingly.
• SOLUTION: The load balancing system must be able to iden<fy which servers must answer to each of the tenants requests, so that it can efficiently distribute the requests load through the servers farm. To enable that, we can dynamically configure on each server a set of load balancer probe endpoints per tenant, so that only the configured servers for each tenant will be visible to the load balancer.
S1 S2 S3 S4 S5
Tenant A
Tenant B Tenant C
Shared Databases
End-‐To-‐End Tracing
Applica<ons
APIs
Resources
Users “[email protected]”
“VOD App on iOS”
“SubscriberManagement API”
“Server A on Farm X”
IDENTITY PROVIDER
AUTHORIZATION SERVER
API CATALOG
CMDB/INVENTORY
UNIFIED TRACE COMPONENTS ACTORS
• PROBLEM: Several layers of Products, Services and Resources make understanding of problem root causes difficult, and significantly increases the <me and effort required for incidents detec<on and resolu<on.
• SOLUTION: When using APIs in the integra<ons between layers, it is possible to consolidate all segments of each message flow in an unified trace view, that iden<fies the user, applica<on, service APIs and physical resources involved on every message flow, which will increase support teams efficiency, avoid undue incident escalona<ons and reduce cost.
Security
Iden6ty Gateway
• PROBLEM: Applica<ons need to authen<cate users using different providers, such as social, corporate and applica<onal iden<ty providers. Integra<ng applica<ons with different protocols requires significant effort and couples them to the providers specific protocols, thus lowering applica<ons portability, maintainability and extensibility.
• SOLUTION: An Iden<ty Gateway abstracts the specific details of any iden<ty provider, thus allowing applica<ons to integrate with them using a single protocol, enabled by the Iden<ty Gateway service component.
User
Facebook, Google, Twi^er,
LinkedIn, etc.
Service Delivery Broker
3
Corporate Iden1ty
WS-‐Federa<on Adapter
Social Iden<ty Adapters
SDB Connect
Iden<ty
Gateway
Applica<on
OpenID Connect
1
Frontend
2
4
Integrated Authen6ca6on & Authoriza6on
• PROBLEM: Applica<ons requiring users iden<ty generally also need to access (through APIs) protected resources on behalf of those users. Instead of implemen<ng two disconnected flows, store and use separate creden<als on each flow (users authen<ca<on and resources access authoriza<on), applica<ons should be able to authen<cate and authorize their users relying on an integrated protocol.
• SOLUTION: When used together, OpenID Connect and OAuth 2.0 specifica<ons enable support to users federated authen<ca<on and delega<on of access authoriza<on to APIs. An applica<on can use OpenID Connect to sign-‐in a user and then request an OAuth 2.0 access token to invoke APIs on behalf of that user.
APIs SDB Run1me
User
Facebook, Google, Twi^er,
LinkedIn, etc.
Service Delivery Broker
3
6
Corporate Iden1ty
Token
Manager
WS-‐Federa<on Adapter
Social Iden<ty Adapters
SDB Connect
Iden<ty
Gateway
Applica<on OAuth 2.0
1
Frontend Backend
4
2 OpenID Connect
5