Post-launch experiences from a locally developed internal proof of concept implementation

4/15/2015– strictly confidential, confidential, internal, public – 1
EXPERIENCES FROMANINTERNALLY BUILT POC
SEBASTIAN SCHUMANN, SLOVAK TELEKOM
15. April 2015. London, UK

SCOPE
Post-launch experiences from a locally developed internal
proof of concept implementation
 Service description
 Used technologies and integration challenges
 Lessons learned
April 2015, London, UKS. Schumann: “Post-Launch Experiences From An Internally Developed PoC”, WebRTC Global Summit 2
@s_schumann
Feedback is welcome! Get in touch during/after the event.

SLOVAKTELEKOM
 Former fixed & mobile incumbent (merger in 2010), Zoznam, Posam, DIGI
 Diverse service portfolio (fixed/mobile network and communications
services, Internet access + content, data services, CPE, ICT services
(data center + cloud), radio/TV broadcasting, call center services, …)
The major shareholder is Deutsche Telekom AG.
Successful deployments in SEE as well as in DT group:
 Fixed network IMS migration finished end of 2014
 Leader in IPTV, offering hybrid sat TV (s. 2009) & OTT app (s. 2012)
 Extensive FTTx deployments (360k households)
 First nation-wide 4G/LTE network (end of 2014 52% pop. coverage)
 Only Telekom group member that rolled out WebRTC-based service
company-wide and accessible for everyone
Slovak Telekom Group is the telecoms market leader in Slovakia

RECAP2014
 Many presentations about my view on operators and the WebRTC paradigm,
misconceptions, reasons etc.
 Experiences of Slovak Telekom in various units and theory & practice
 Drive towards innovation independently of traditional
vendor’s legacy-first approach for WebRTC
 Three in-house innovation designers with “a mission”
 Belief in “change from within” and active learning
 Own development of internal proof of concept
 Many challenges and expectations
 To be used by entire company

SERVICEDESCRIPTION –TELEKOMC-PEAK
 In short...
 ... C-Peak is an innovative way to communicate with everyone in Slovak Telekom
 It is a WebRTC proof of concept implementation to get in touch easily, in high quality,
and uncoupled from telephony
 Unique links built from E-mail address, added to every employees signature
 Audio/video/messaging from personal portal, “ping” users to get in touch
 No telephony break-out or other legacy elements
 No passwords (token based access centered around E-mail)
 No one-size-fits-all: Many features consciously omitted … for now 
(directory, collaboration, conferencing, PSTN)
348 reg. users (>10%)
>200 conversations
in 2015 alone

TECHNOLOGY I/III–GETTINGSTARTED
 Our “own” preconditions
 Open-source software, modern stack, comprehensible, extensible – No “vendor black box”
 No integration with legacy systems – we want to show the power of the web (and be independent)
 First-time trial – not many internal prerequisites
 Lack of modern APIs, no real integration environment
 Execution environment would have needed complex approval procedure, no “typical” project
 Open-source software + MEAN stack for development
 Public third party services offering APIs that will not be implemented
 Development on public cloud with public IP + no restrictions  transition to future “staging environment”
Conclusions

TECHNOLOGY II/III–THEIMPLEMENTATION
 “Typical” web developer
tool- kit experience
 Simple HTML + CSS and
JavaScript experience enough
 This “stack” was been used
for implementing and
demonstrating various demos
 Different features
 Customer tailored
 Nothing that is Telco/NT
specific – pure web dev
 Simple “clean” design to demo early results
 The usual suspects Bootstrap, JavaScript, etc.
 Open-source wherever something more needed, e.g., ZeroClipboard, video.js
Front-End
 Node.js + Express, MongoDB
 Unirest, Nodemailer
 Various libraries for direct service integration
 Framework with a lot of flexibility and high level of abstraction (EasyRTC)
 Firefox/Chrome abstractions, additional functions
 Support beyond C-Peak to demo as much as possible
Back-End
WebRTC

TECHNOLOGY III/III–THEENVIRONMENT
 API topic often neglected due
to business case discussions
 another good sample what
it is useful for
 Shift now to internal lab only,
but no reason to have waited
 Learn from external service
provider
 Development: Virtual machine before internal environment ready
 IaaS preferred over PaaS so everything can run off one box
 Production: Application server, TURN server, two external load balancers
Server
 External: E-Mail (Amazon SES), SMS (Nexmo), Monitoring (New Relic)
 Internal: E-Mail via Outlook SMTP, proprietary REST API for SMS + Monitor
 HAProxy (load balancing on AS, HTTPS termination)
 coturn (TURN server integrated between networks and for “classic” TURN)
 Piwik (own analytics to troubleshoot and evaluate)
APIs
Software
Why this split? – Time & Processes! Getting started and demonstrate something fast was key.

LESSONSLEARNED –BUILDINGIT
 It is easier to use IaaS for development if not easy access to dev resources (even waiting a month is long and
can be used for developing already)
 Corporate networks the most challenging (media traversal, security policies)
 Default browser and installation permissions need to be checked
 Availability of internal APIs cannot be assumed
 Involve management early for “air support”, discuss with stakeholders independently
 Include both IT and NT (IT can do now what NT does, NT needs to get IT skills)
 Do not get irritated by legacy thinkers or doubters
Trial and error seems to do well in the beginning. Try to get something out there!
(and afterwards think how to do it next time with bigger investments)

LESSONSLEARNED –RUNNING IT
 Not everyone will be using it or finds it useful, but it is right what some people needed
 Generally positive feedback about active involvement in innovation rather than “time jealousy”
 Shape acceptance for “unusual activities”
 The initial aim of specializing tool and omitting features not fully appreciated by users
 change of own attitude
 Communication services is a sensitive area (especially if the new stuff works really well)
 acknowledge it, but esp. with WebRTC there is space for both evolution and innovation
 Don’t fight alternatives (e.g. Lync) – explain why there’s place for both and highlight benefits

OUTLOOK–WHATISNEXT?
 Addition of requested features
 UI improvements + manuals
 Business products for various levels
 Get “full clearance” how to handle WebRTC projects – both big and small – in the future for larger projects
 Think about “architectural” approach for future projects
 Build it?
 Buy it?
 Rent it?
 Balance between “boring unavoidables” and innovation

SUMMARY
 We learned a lot and are first in our group offering a cross-network WebRTC communications service
 Accessible to >3000 employees, open to connect with anyone from anywhere
 No vendor involvement or dependency
 Thinking and doing things differently worked
 Try to study it and repeat!
 Elaborate contrasts and what they mean (NFV vs. virtualization, VoLTE vs. WebRTC communications, etc.)
 Building instead of talking works now, especially for the “renegades” 
 People will be stunned to perceive it themselves if they all of a sudden know the people that built it
 Prototyping means learning
 We have developed various prototypes and every single challenge was also a lesson learned (some shared today)
Stop political games! Use NT and IT resources efficiently! Find the right peers!

THANKYOU.
Sebastian Schumann
Application & Platform Innovation | Slovak Telekom, a.s.
 Sebastian.Schumann@telekom.sk
@s_schumann
 +421 903 419 345
… or simply click https://c-peak.telekom.sk/u/sebastian.schumann@telekom.sk

Post-launch experiences from a locally developed internal proof of concept implementation

More Related Content

Viewers also liked

Similar to Post-launch experiences from a locally developed internal proof of concept implementation

More from Sebastian Schumann

Recently uploaded

Post-launch experiences from a locally developed internal proof of concept implementation