The document summarizes the SDIS 2014 Service Delivery Innovation Summit, detailing presentations by various telecom experts on topics such as API management, cloud services, and digital payment solutions. Key speakers included representatives from Telus, Portugal Telecom, and Telecom Italia, highlighting the importance of internal API consumption and the challenges faced when integrating with external partners. Overall, the discussions emphasized the need for telecoms to adapt quickly, prioritize customer needs, and collaborate across the industry to foster innovation.

1. SDIS2014
Service Delivery Innovation
Summit Summary
(previously known as the Global
SDP Summit)

2. Agenda
• Telus: An SDP Journey. Cynthia Wong, Telus
• Service Delivery Broker: Business, Governance and Security Architecture for Digital
Services. António Cruz, Portugal Telecom
• Telecom Italia’s update on Network API Platform. Francesco Vadala and Vincenzo
Amorino
• Using the OTT approach to drive innovation within operators. Karel Bourgois, Orange
• Cross-Industry Business Development: IoT and Telco APIs for a Smart World. Dirk
Rejahl, BearingPoint; Sascha Wolter, Deutsche Telekom
• Direct Carrier Billing – API Monetization Opportunity Using Partnership with OTT.
Martin Prosek, O2
• Network of the future - Market need and its influence on services standards. Eshwar
Pittampalli, Ph.D., Market Development Director, OMA
• Transforming the telco service portfolio through cloud delivery. Ivan Krevatin,
Hrvatski Telekom
• Bringing Clouds, SDN and NFV Together. Dr. Adel Al-Hezmi, Dipl. Ing. Florian
Schreiner and Giuseppe Carella; Fraunhofer FOKUS

3. Cynthia gave a great overview of their API program, in some ways similar to
Telenor and Telecom Italia with a focus on internal and partner consumption
of APIs.

4. This remains all too common the case for telcos. 9 months is ignoring the
12-18 months required to get the project off the ground.

5. SDF is essentially an API Management platform.

6. Premium SMS content providers account for a significant % of partner API
transactions. Internal consumption, particularly by Telus web properties, is
currently the fastest growing segment.

7. With success came a hiccup and a focus on process, governance and best
practices. This is also a focus from Antonio Cruz and Francesco Vadala’s
presentations.

8. API platforms need to enable many APIs, most of which are not standardized
and have no need of being standardized.

9. Service orientation is not an option, API is how services are expressed and
consumed. Telus have a strong focus on internal API consumption, which is
the low hanging fruit. This ‘eating own dog food’ enables a mature platform
and processes to be exposed to partners, rather than the other way around.

10. Antonio Cruz’s presentation is simply a SOA migration case study, that is
common to many enterprises. Its just focused on a telco situation. Most of the
platforms are off the shelf IT or open source. This is a great example of the IT-ization
of telecoms.

11. SOA is a well understood IT paradigm. Interestingly Antonio expanded this
model to how the network is adopting a SOA model with NFV.

12. APIs are solidly BAU (Business as Usual) in PT. With a focus on internal and
partner (not long tail) consumption.

13. This is an important IT trend with the Hybrid Enterprise. This enables telcos to
offer and package white-labeled services quickly with much less pain and
integration of the past.

14. Identity is not limited to the telcos Id, which most people forget.

16. Process is not unique, it it common in most enterprises

17. Management and Functional APIs are required. Focus has been Functional.
While for end to end visibility management APIs are critical.

20. This process is where I come across most problems. Internal consumption is
getting there, Telus and Telecom Italia are good case studies. Its when external
partners are involved it becomes challenging. Often its because the processes
for internal API consumption are immature.

21. Portugal Telecom is achieving significant market success in bundling a range of
cloud based services for customers, particularly the SMB segment.

22. This is the same IT architecture as most leading enterprise. IT skills are
essential in today’s Telecom employees.

23. Telecom Italia remains a leading example of API consumption for internal and
partners applications. Their focus over the past 2 years has been on the
processes of making API consumption easy.

24. See common concepts to Portugal Telecom. Note 3rd parties means other
groups in TI as well as external partners like MVNOs and Fiat. Not the long tail
– that in my opinion requires an ecosystem partner.

25. Documentation (as we saw from Telefonica last year) and Flexibility in business
model (which I run into many times).

26. Very similar approach to Portugal Telecom.

27. Collaboration comes through education across Telecom Italia, and
demonstrating success time and time again.

29. Libon is an alternative to RCS, and it uses RCS to interoperate with other
carriers and the RCS device API when its available.

30. As mentioned in my weblog, they need to move faster, but the usage figures
compared to Joyn speak for themselves (time spent with Libon is >100 times
that of RCS)

31. Working across devices is important, it’s a weakness in Whatsapp and many of
the apps that believe mobile first means mobile only – it does not. This will
give Libon a much broader market appeal.

33. The numbers
speak for
themselves.
We have to be
responsive, waiting
for standards
bodies to horse
trade and
generated a
comprise is not a
viable model for
services.
We need to JFDI,
learn, adapt, and
grow.

34. Dirk and Sascha gave a nice review of how to engage customers and partners on
the potential of Telecom APIs, through innovation workshops.

35. This is the process behind embedding telecoms everywhere.

36. Martin as usual gave a great presentation on the DCB opportunity and the
challenges we face and must overcome.

37. Google treats mobile payment like every other payment mechanism, it uses its
card payment platform. It remains perplexed why telcos could not follow
existing proven payment standards and processes – example of unnecessary
Telco Standardization by people who did not understand the business. DCB
has benefits for micro in-app purchases, but its lost in the fat and difficulty of
DCB integration.

38. Payment card industry has solved these problems years ago.

39. Payment card industry has solved these problems years ago. Using an
aggregator reduces already thin margins, and shows what currently is
implemented in not a viable payment platform.

40. Payment card industry has solved these problems years ago.

41. DCB opportunity is stifled by adherence to telco standards. Copy what works
in the market. Telco is too insular and self focused. If you want to offer
payment services, then offer what the customer wants, not what you want.

43. Standards are necessary, but appropriateness is key. And defined by people
have have the necessary skills, not just happen to be standards people. The air
interface (hose connection) is critical. However, specifying internal standards
of the engine used to pump the water by people with limited engine experience
has negative value – and that is what’s happening too often in telco.

44. Ivan gave a great presentation on the practical first steps being made in
virtualization of network elements.

45. This is a FTTH scenario. Data Center run by IT is virtualized.

46. First step was running the WebRTC gateway on a virtualized data center.
Business case was – “that’s how IT group run their data center”.

47. LRF (N.B. fixed network) simply runs in virtualized data center and different
instances can be created for different business needs.

48. Even just sharing application servers has a raft of issues. This is currently
where Hrvatski is in their thinking.

49. Adel gave a good review of the virtualization / NFV implementation options.
Highlighting the latency challenges which will limit data path virtualization for
many years.

52. Its likely we’ll see an evolution through these options. All these practical
considerations limit the savings and to some extent claimed agility.

55. Its quite likely the data plane will be kept un-virtualized to meet the delay
requirements. Which again limits some of the claimed benefits. Its not that
virtualization has benefits, its simply the current NFV marketing is naïve and
distracting the industry from more important issues like service innovation