Powering Wearables for the Enterprise

DZone 's Guide to

Powering Wearables for the Enterprise

As wearables become a part of our everyday lives, businesses need a strategy to integrate these devices into their existing systems and workflows.

· IoT Zone ·
Free Resource

This article appears in DZone's Guide to the Internet of Things – 2015 Edition.

Wearables and smartwatches have been around for a while now. Simple fitness trackers really started the movement, but things have evolved quite a bit since their introduction. The Pebble smartwatch kicked things off back in 2013, quickly followed by Samsung and Motorola who produced similar entries in the market. Not long after that, Android Wear emerged and created its own product ecosystem. Most recently Apple has set the wearables space on fire with the Apple Watch. In fact, Apple recently announced it has sold over one billion dollars worth of devices, capturing 75% of the smartwatch market in a single quarter. The market for apps for this new class of devices is rapidly evolving as well.

While apps like fitness trackers and “remotes” (meaning a remote controller for either an app on your phone or a remote control for a physical object) have been popular so far, that is not where things will end. In fact, wearables and smartwatches are working their way into the enterprise, much like smart phones have already done. The phone allows for a more personal experience than the desktop computer, because it’s a device that you almost always have with you. It has enabled access to data that is important to you, with respect to your personal context.

You can expect this to continue and mature in the context of wearables. Apps developed for wearables and smartwatches will be even more personal than ever. Not only will they deliver the information that you need, when you need it, but they will go even further with an emphasis on simple, easily consumable, or easily actionable interfaces. Context is the critical difference. A smartwatch is just a glance away, and can notify you when there is news you should see, without having to pull something out of your pocket. Information can be delivered based upon your location, history, or any other kind of preference—all right to your wrist. It’s not just about the consumption of information; smartwatches also enable simple, personal collection of information. Whether it’s your location, a simple tappable form on your wrist, or a remote for a more complex app or peripheral device, for both consumption or creation of data, it is a more personal context than ever.

So, is your enterprise ready for the incoming wave of smartwatches and wearable devices? Do you have a strategy to integrate these kinds of devices into your systems or workflows?

Let’s focus on the smartwatch category. Luckily for most of us, everything that we need to integrate smartwatches into our ecosystems already exists. If you have a successful mobile application, then chances are very high that your smartwatch app can reuse this infrastructure and existing code. You don’t necessarily want the exact same user experience. It is highly likely that your user interface and user interactions will be extremely different due to the lack of a keyboard and significantly less screen real estate, but backend services and workf low logic can probably be reused.

A smartwatch app is, in essence, functionally the same as a mobile app on a phone. Many Android-based smartwatches are more or less small phones strapped to your wrist. They contain the processor, memory, and networking capabilities of a phone, and they act as independent devices. When you write apps for them, you will have to use the smartwatch platform SDK, but you can reuse much of the logic and services that power your mobile app. The Apple Watch, in its current release, is a peripheral device. The Apple Watch contains limited processing ability; rather, it delegates all processing logic and networking requests to an extension (separate application binary) that runs on your phone. This will change slightly with watchOS 2, which enables on-device program execution, but the way that you write your apps remains largely the same as for an iPhone. In both of these models, the UI is built using Xcode’s Interface Builder, and application logic is written in either Swift or Objective C.

This gives you the ability to access backend systems in exactly the same way that your mobile apps do. The app’s business logic and server interaction can be shared code assets so that both the server-side code/services and the client-side workflow code can be reused across both projects.

At a high level, the most common architecture for enterprise apps will be that the app (on the phone or on the watch) makes HTTP requests to the server. These requests either push data to the backend or retrieve data from the backend system. The server then processes the request, saves or retrieves data, and returns whatever data is needed to the mobile client. The services could be RESTful, SOAP-based (though I don’t recommend SOAP because of its verbosity), or just plain old HTTP requests. It really doesn’t matter. Likewise, the application server tier doesn’t really matter much either, because we are operating on standard web protocols. Your existing infrastructure based on an enterprise Java platform, built on top of Node.js, built on top of .NET, PHP, or really anything else, is still sufficient to deliver information to and from your mobile and wearable apps; I’m also assuming that your backend is built in a service-oriented fashion that enables this architecture.

Let me rephrase this in terms that are related to my role as a Developer Advocate with IBM: you have lots of options for building mobile applications with IBM products. There is the MobileFirst Platform, which is a comprehensive suite of enterprise-class tools for efficiently building and maintaining mobile apps; there are MobileFirst MBaaS services on IBM Bluemix (cloud services); and there are also individual Platform-as-a-Service (PaaS) offerings on Bluemix, such as the Node.js infrastructure, Java/WebSphere Infrastructure, the Cloudant NoSQL database, and more. There are also the Watson cognitive computing services that can be used with any of your mobile applications.

If you already have an application that, for example, uses the MobileFirst platform to deliver secure data and active monitoring on a mobile app, then that existing infrastructure and investment can be reused easily within a wearable or watch app with almost no code changes (besides the user interface). This is already being done today: major institutions are leveraging the services that they created for their mobile experiences to power their most personal interactions at a glance on smartwatches.

If you have already built an app on top of Node.js that uses IBM Watson to perform complex cognitive analysis and return it to your iPhone and Android apps, then the exact same code and processes can be leveraged within your wearable application. Imagine that you have an app that leverages IBM Watson language services to translate from English to another language in real time as you interact with data. Now imagine that you want to move this experience to the wrist to enable more efficient and contextual interactions in everyday life. You can reuse the exact same logic and operations as the mobile client, and only need to create a user interface for the new form factor.

Delivering apps on the Apple Watch, Android Wear, or other wearable platforms really is not anything new in a technical sense. You have a new user interface, a new form factor, and a new notification and interaction mechanism, but the logic f low and order of operations are largely the same. If you have built your existing mobile experiences in a modular fashion that leverages standard protocols, then there is a good chance that most of your work to build the wearable experience is already complete.

For more insights on IoT security, protocols, and standards, get your copy of the Guide to the Internet of Things – 2015 Edition now!

iot ,wearables

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}