In the wake of the unveiling of the Apple Watch, we are constantly told that we are on the cusp of the wearables revolution. Every week, a new report seems to suggest that the industry needs to prepare for the arrival of wearables, only to be immediately contradicted by another that suggests we don’t need to prepare for them.
What most of the industry does seem to be able to agree on is that these devices, if they do take off, could present new security risks. In particular, the types of data that wearable devices capture can be particularly sensitive ones, often with a medical element.
The obvious response to this is to start planning ahead. But how do you plan ahead when you have no idea what is coming? What is the next wearable going to look like? What security issues will its specific design present? It is quite a challenge to try and out-smart an industry that specialises in innovation.
In an industry that is constantly in flux, then, a potential solution might be to focus on the constants. In this case, this might be application programme interfaces (APIs). These are mostly used in the context of mobile and govern how applications communicate with each other and how they send and receive data.
Crucially, the API architecture is not specifically tied to existing mobile devices, so could provide a much needed continuity as the devices market evolved. Axway, headquartered in France, focuses specifically on securing APIs.
"Organisations want to have a digital strategy in terms of having mobile apps and new ways of reaching customers," comments Mark O’Neill, VP of Innovation at Axway. "In the course of doing that you need to balance putting the data out there and making sure people can access it in real time with apps and get at it through cloud services, but at the same time not create security breaches. There’s a lot of balance to do there, and that’s the challenge."
Axway encourages its customers to use an ‘API-first’ strategy.
"We mean treating your API like a first-class citizen of your architecture," says O’Neill. "You have someone managing it, a product manager. You document it and you manage it. Our customers will often give the API a name, or brand it.
"Once you’ve done that you have people whose job it is to manage the API. They make sure that it’s not going to be changed in any way that’s going to break applications or cause problems for clients."
This compares to what Axway sees as the usual strategy: mobile-first.
"You hear people talk about mobile-first. With this you literally first build the mobile app and you also build some way for the app to get at the data it needs."
O’Neill continues: "The problem with that is you could end up with multiple mobile apps and they all have different mobile channels for how they’re getting at the data. Some of that might not be that well managed or secure, because the way of getting the data is kind of an afterthought after building the app."
"With API-first, the first thing you do is build the API, which is how you get at the data," O’Neill says. "Then when people come along to build apps you say, there’s the API, this is how you access it. And then they’re all accessing the same API. So it becomes one thing to manage.
"Even though you do have the upfront work to design your API and define it, going forward you can manage data access through that API.
Crucially, an API-first strategy might be able to provide that much needed continuity, as O’Neill explains:
"With mobile-first, you’re thinking that everything in the future is going to be mobile. But as I mentioned there are smartwatch applications and different ways that people want to connect.
"When you have an API in place, you can say. Here’s the cloud access, here’s mobile, here’s wearable devices – all of these things could access the API. It’s more forward-looking. That’s something we definitely advocate and we see customers being successful with that type of architecture."
