The connected car is now one of the hottest use cases for APIs. APIs are used in all aspects of connected cars. Security, version management, and developer and app registration is core.
If you are interested in how APIs are central to the rise of the connected car, I recommend checking out the talk by Sebastian Mennicke of iC Consult at Odette 2014 in Lyon, France on 19 and 20 May. iC Consult is an Axway partner which has been to the fore of deploying secure API projects worldwide.
Sebastian is speaking about the usage of the Axway API Gateway for secure APIs, using the example of the BMW i series project. The abstract is below:
The move to the connected vehicle is already in full swing with all major automotive OEMs offering systems that connect vehicles to the Internet. And the BMW i series is already on the road proving this evolution. The market opportunity has the potential to be huge: according to research firm SBD and the GSMA, the global connected car industry will be worth €39 billion in 2018, up from €13 billion in 2012.
In order for manufacturers to truly cash in, they need to consider the potential challenges that arise from this new era of vehicle mobility. Automakers need to look at the next generation security and integration technologies so they can control exactly who has access to the vehicle. The key to this is API Management.
APIs are what connect the apps in connected vehicles to the services which they depend on. Therefore, there is a need to manage and govern the APIs that enable collaboration between a vehicle and an app, such as the registration of developers and apps, API key distribution and revocation, and API version management.
Sebastian Mennicke, Senior Consultant at leading Identity & Access Management Consultancy iC Consult, shows how the Axway API Gateway can help to integrate mobile apps with backend APIs by the example of the BMW i series project.
- Real world best practice use cases for integrating mobile apps on the car with enterprise data systems
- How an efficient API management strategy is fundamental to securing flow of data across a network of connected cars
- How to control the access to and from your car in the emerging Internet of Things
(Originally posted in slightly different form at soatothecloud.com.)
We’re now at the end of standard maintenance on several DataPower SOA appliances. And that probably means most companies who haven’t yet upgraded are buying extended support, because you don’t just replace appliances for important applications — you test and deploy over many months so that you don’t put the business at risk. If you’re in this situation, use the next 1-2 years wisely to rightsize DataPower, and break the vicious spending cycle.
When it comes to appliances, many companies buy excess capacity up front to support several years of growth. Often it’s because they don’t want to be forced to do an early upgrade or add-on purchase. Most are convinced they will use the extra capacity for other projects. And this is the vicious cycle. Companies end up putting applications on DataPower that just don’t belong there. DataPower is great as an XSLT acceleration engine, but that’s mostly it, and that “data power” comes at a big cost. Don’t keep loading up DataPower. Start to evaluate which applications don’t belong there, and start to implement your rightsizing program now. Then, buy the right size of DataPower for what’s left.
Reevaluate all new projects and see what can be moved to another platform before you put it on DataPower. Any integration across a firewall or across divisions can probably be done using an API gateway. The right API gateway will have native wire-speed integration with DataPower that makes it easy to add it to a DataPower deployment, migrate workloads, or add functionality to other deployments.
Finally, build out your roadmap for migrating existing functionality that can or should be run on other platforms, either during release cycles for the applications or as part of a larger initiative. Some of the more common reasons for moving to an API gateway are:
- A move to virtualization or an outsourcing strategy. DataPower isn’t designed to run on a third-party virtualized infrastructure such as VMware or Amazon AWS.
- A need to support cloud and mobility. DataPower supports XML. It’s not good at supporting the new world of JSON and REST.
- Productivity. DataPower requires developers to code in XSLT. A modern API gateway is a highly graphical environment, where developers configure, not code.
- Antivirus protection and security concerns. DataPower requires an ICAP connection to add anti-virus protection, which adds an extra network “hop” and a delayed response. The right API gateway supports antivirus in-process and a host of security measures for hardening access from outside the firewall.
- Identity bridging. DataPower does not directly support bridging OAuth, Oracle Identity Management, CA SiteMinder, or even Tivoli as well as a quality API gateway that delivers federated identity management and single sign-on (SSO) across the old and new channels.
So build your roadmap now. Start by identifying the strengths and weaknesses of DataPower and evaluate each application it supports. Get advice from others who have used API gateways with DataPower. Use some of the money that had once been earmarked for extended support — and extra capacity — to work on new projects that make a difference to the business.