I received a huge number of views and good few direct messages with questions after my post about KPN API Store launching a Programmable IoT Wireless platform with JpU. Some of the questions are something I didn’t have an answer to and figured they may be in the interest of others so I reached out to the CEO of JpU, Jonathan Schwartz and interviewed him over email as well as adding in a couple of my own questions since it has been a while since Jonathan and I caught up.
Making the IoT connectivity experience something more akin to the public cloud experience like AWS or GCP has been something near and dear to my heart after building and launching multiple IoT connectivity, analytics and technology platforms in AWS in CTO roles across Telenor Connexion and Tele2 IoT. To this end, I’ve followed the development of JpU closely since they are doing something really unique in this space.
Note that there are some flow edits to take an email conversation into an article.
[Stephen] Hi Jonathan – thanks for taking the time out for questions. I’ll jump right in. One question I got was why does the world need yet another Connectivity Management Platform (sometimes called a Connected Device Platform)? There are strong offerings from the majority of Network Equipment Vendors.
[Jonathan] The challenge we’ve seen over and over is that Connectivity Management Platforms are largely IT systems that handle the SIM lifecycle and billing specific to IoT. And that they have mobile core networks bolted onto them. JpU aspired to do something very different – Hypercore is a single platform that is software defined, API controlled for the orchestration and management of connectivity. There is no hardline between an IT system and the mobile core, firewalls and routers. We saw this as necessary to help Service Providers build strong scalable and repeatable IoT businesses and work with the largest enterprises down to the small startup in a way they cannot today.
[Stephen] That is something that really struck me when we first met at Mobile World Congress years ago. JpU has a telco edge that supports SIGTRAN, GTP and DIAMETER and then everything on the other side is JSON, REST and Kafka like a modern cloud native stack.
Aside from the technology differences, one of my observations is that most of what a Connectivity Management Platform does is actually for the benefit of the Service Provider as opposed to the Enterprise, user or developer. Most of the value to the Enterprise has been the early stage activation orchestration handling production, testing and distribution of a connected device and then after that it is mainly a billing engine that supports that Service Providers’s business model.
[Jonathan] I think we are doing something really cool and valuable. I agree that most of the value to the Enterprise has historically been the activation orchestration. More and more Enterprises are moving to the public cloud with DevOps and CI/CD, but no Connectivity Management Platform out there is designed for that concept. JpU is completely API driven with more than 100 APIs to facilitate automation and can be driven headless in the same way you think of Terraform or CloudFormation for managing your cloud with Infrastructure as Code – we enable an Enterprise to manage their mobile IoT deployments the same way. By being completely open and programmable, we provide value throughout the entire lifecycle of IoT applications than just in the activation phase as compared to the traditional Connectivity Management Platforms.
Another key differentiator is security, we don’t see that any of the traditional Connectivity Management Platforms have given Enterprises the tools and capabilities to properly manage security policies in the IoT space. And security as a selling point has always been tricky because buyers just assume security or rely on certifications – but historically haven’t placed a specific value on features in the platform. For JpU, security is paramount to see IoT grow and we give Enterprises a rich set of features to be able to properly manage their own security.
We’ve also seen a sea change in the business models that Service Providers are offering as Enterprises are demanding more simplified and scalable models. So much of the traditional Connectivity Management Platform offering has been about getting the billing model right and Enterprises don’t really value that – what they really want business simplicity and full control of everything from the device through to routing and firewalling via an API.
[Stephen] One good question I got related to why yet another Connectivity Management Platform is your own business case for JpU along with the oft quoted document from GSMA’s Connected Living Programme “Understanding IoT” that from a revenue mapping perspective Service Providers only get 10% of the revenue of a deployed IoT service and players like yourself would presumably see much less.
[Jonathan] That is a tough, but great question. Consider Moore’s Law and compute – compute has historically gotten more and more commoditized and yet AWS runs a growing and extremely profitable business providing rich API driven services on the back of compute and networking services. JpU allow Service Providers to tap into a similar opportunity in the IoT connectivity space that AWS, GCP and Azure are doing in the compute space. As per your original post, KPN are doing an amazing job at building an API marketplace that in many instances also drives more growth of their core connectivity services. We are thrilled to be part of the KPN API Store and to work with visionary Service Providers that launch innovative new services. We have a solid and fast growing business helping Service Providers grow beyond 10% of that value mapping you reference by giving them the scale and richness of monetizable services to become the AWS of IoT connectivity for their footprint.
[Stephen] Another question raised was, what kind of XaaS category do I think JpU fit into or are JpU helping Service Providers fit into a specific category? I am really curious about this myself.
[Jonathan] The category space is quite tricky and getting more and more blended together. Many of the Application-to-Person Messaging players are presenting themselves as Communication Platform-as-a-Service (CPaaS) vendors with the ability to send SMS, RCS and other types of omni-channel messaging as well as handling voice. And then the Unified Communication-as-a-Service (UCaaS) vendors are traditionally voice and SIP with some messaging capabilities. More and more this space is getting blended together as everyone is focused on conversational applications, chatbots and personalized experience. We’re clearly don’t enable Service Providers to take a CPaaS or UCaaS position as we are focused on IoT, but we do something more akin to taking the traditional IoT Service Provider offering and turn it into a proper as-a-Service offering with the ability to build rich automated solutions in a way that the traditional Connectivity Management Platform offerings have failed to do. So I think a proper category definition a la Gartner et al is still in the making.
[Stephen] One topic I’d like to raise with you is something I’ve seen over and over in the IoT Connectivity Service Provider space is that there is no return on Customer Acquisition Cost for may customers. This is a real challenge for Service Providers as IoT is still evolving and some customers grow faster than others meaning that Service Providers can invest a lot in customers and not see the return on that investment.
[Jonathan] You’re spot on here and JpU was built for this. Here again, consider AWS as they can serve the largest global businesses on the planet as well as a startup. We built JpU’s platform to cater for a completely touchless, self service model that allows Service Providers to support startups and at the same time have a far richer, more configurable offering that can be completely API driven to support the demands of the largest businesses with the most complex needs. To make IoT fly, connectivity is the key prerequisite and it all comes down to business case for both the Service Provider and the Enterprise and I believe JpU are truly position as the only platform that can make that happen.
[Stephen] One thing that I’ve reflected on in my career is how important that birthdate of a platform is. If a platform isn’t born in a modern age and grows up behind a firewall with no open APIs it isn’t really suitable for where the world of connectivity and cloud compute is today. What do think about that?
[Jonathan] I think it is an interesting point. JpU of course leverage many battle tested components in building out our platform combined with the best modern design paradigms. But it has been born in the age of public cloud and provides experiences that developers and DevOps teams demand to build the best connected applications.
[Stephen] Great catching up with you again and I look forward to following JpU’s development.
[Jonathan] Take care, Steve