Perry Hoekstra

Posts by this author: RSS

Beacons, not iWatch is Where the Enterprise Action Is

Wearables have been in the mobile space news again lately, with the news that iWatch sales have slipped significantly.

However, one of the other facets of mobile space and one that has greater enterprise applicability, Internet of Things (IoT) and in this case, beacons have made a number of quiet but significant advances lately. The IBM/Apple partnership released another round of enterprise apps and one, Safe Site includes iBeacon technology to alert people on the job when they are approaching a hazardous area. More importantly, lost in the din of all the announcements coming out of Google I/O 2015 such as Android M is the release of Eddystone Android/Google’s new framework for supporting Bluetooth low energy (BLE) beacons (I grant you, iBeacons is a sexier/easier to remember name).

Android 4.x supported BLE but in a very limited fashion and Android 5.x improved upon that support but Eddystone is the first effort Google has made to support beacon technology in a significant way. In addition to the base frame format that Apple iBeacon uses, Google has released other frame formats such as a telemetry frame that allows the sending of diagnostic data about the beacon so that its health can be monitored (battery level, etc). Finally, Google has integrated a number of APIs to extend the functionality of beacons. These include the Nearby API and Proximity Beacon API to establish proximity between the beacon and the smartphone and integrates Places API for location awareness. Integrated into Google Play Services, Eddystone is the first fruits of the efforts from developers understanding the uses beacons could play within the enterprise space and pushing Google with statements such as “Android’s support for BLE is fine but it would be better if I could do X …”

The Connected Car Platform Conundrum

I recently completed some proof-of-concept work for a major automotive manufacturer and I have come to the realization that the automotive manufacturer’s approach to the concept of the “Connected Car Platform” is going to run into growing pains as the pace of mobile innovation continues unabated.

One of first issues I ran into was that I did not own any of the client’s vehicles so I could not develop against an actual head unit but instead, had to use a head unit emulator.  Each manufacturer has their own head unit (that is the screen in the dash and all the associated systems that controls the music and any information displayed on the screen) with their own custom software and approach to connectivity.  This requires a mobile developer to work with aconnected_car multitude of manufacturer’s SDKs in order to have their mobile app work with any number of vehicle platforms.  The current state of the world in terms of mobile development for car platforms is very similar to what we found ourselves at a number of years ago when you were trying to decide how to support four or five different mobile platforms (iOS, Android, Microsoft, Blackberry and maybe Symbian).

Either you choose the top two or three, depending on the size of your development staff or looked at an expensive alternative such as Verivo. For the small mobile developer or development team, are you only going to support Ford and GM, leaving out all the other vehicle platforms? That might have worked in the 50s when GM and Ford dominated the automotive landscape, similar to what iOS and Android do in mobile today but not now.  There are initiatives such as the Open Automotive Alliance, however, their goal is to bring Android Auto to vehicles.  That cuts out the iOS platform and for families like mine who are blended (I have an Android phone but the rest of my family has iPhones), that won’t work.  Apple has come out with CarPlay but again, supporting that platform in a vehicle cuts out the Android consumer. (more…)

Reconsidering Enterprise Wearables

I was talking to a colleague a number of weeks ago and the topic came up of where mobile was headed now that smartphones/tablets have become “commonplace”. The three areas that seem to get a considerable degree of focus is wearables (whose hype will be even further boosted if Apple releases the rumored iWatch on September 9th), Google Glass, and Bluetooth Low Energy (the catchier-named “iBeacon” to you iOS types). As a mobile architect, trying to keep up with all the things going on with mobile, I try to keep the deluge from being overwhelming by focusing on those mobile technologies that have enterprise applicability and that clients may come to Perficient seeking expertise. Therefore, I told my colleague that I had dismissed both Google Glass and wearables as more consumer-focused and that my focus was on the possibilities of iBeacons in the enterprise.

However, after a number of subsequent conversations with other mobile architects and articles such as “ sees wearables catching on with customers, partners” has caused me to rethink my position. While I am not confident in Gartner’s claim that by 2017, wearable devices will drive 50 percent of total app interactions, I moto360do believe there is a place where having access to data on your wrist (rather than digging into your pocket for your cell phone or having to have a tablet in one hand) or a headset will have advantages to various classes of enterprise users such as those who require hands-free access such as industrial (warehouse, transportation, etc.), healthcare or in the case of one enterprising firm, replacing access key cards with a wearable.

The challenge for mobile architects and enterprise IT in general is to understand how wearables could provide an advantage to the business (by actually going out and observing how warehouse workers may be using ruggedized tablets now rather than clipboards or rolling computer kiosks and how a wearable could provide an even more productive work environment) by starting to take a look at this technology. This means short R&D initiatives with minimal investments in both hardware and developer time (taking fail-fast to a new level) and developers open to new approaches in terms of screen size, data input, even further optimization of enterprise data access over what is needed for smartphones and processors/memory. In addition, after the issues that firms have had with BYOD in relation to security and mobile device management, determine if wearables create issues that smartphone access to the enterprise did not already expose. If so, better to address it now rather now in an R&D mode rather than later, when you are creating a true business application. The final issue of course is to determine which platforms will break out with many new watches (Apple iWatch, Moto 360, Samsung Gear ) being released and all of which are jockeying for position.

Microservices as a Mobile Development Enabler

A mobile application has very little function without data to work with and enterprise business mobile applications, even more so. This has given rise to the visibility of application programming interfaces or APIs within the enterprise. Businesses are using APIs to allow visibility to certain business data to business partners outside the company. This concept is nothing new, businesses have been sharing data through Electronic Data Interchange (EDI) and Value-Added Networks (VANS) since the 1980s. However, in the last two years, the spotlight has again shown on APIs as the linchpin to support mobile development.

Microservices as a Mobile Development EnablerOne facet of creating APIs to support mobile development is Microservices which are small, single-purpose, server applications and that can be composed together to form other server applications. The idea is that a microservice does one thing well and executes as a standalone application within a server container (which is one of the differentiators between microservices and their larger SOA brethren). A number of IT technologists have equated microservices with the idea of Unix shell pipeline apps in that they share characteristics such as “small”, independently deployed in their own container, may communicate with each other and are loosely-coupled. James Lewis and Martin Fowler of Thoughtworks published an excellent paper that covers Microservices 101:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

You can say that the above statement could also fit SOA but Lewis/Martin call out how microservices are different enough to stand as its own architecture.

One of the reasons that microservices is a popular choice for mobile development is that each service can start out small, the developer can work both sides of the effort, creating both the mobile app and the service to support it, iterating the services to meet the needs of the mobile app and simply deploy the changed service without coordinating with other developers or the service development team.

This leads into the second trend besides mobile development that has pushed Microservices to the forefront which is the shift to DevOps and Continuous Delivery as another key enabler. The reason for this is that microservices support the need for quicker, independent development (no teams), easy rollback, developer-owned (no handoff to the service support team, it follows more of the “you built it, you support it”), and frequent releases.

Microservice allows an easy and flexible way to integrate automatic deployment with Continuous Integration tools familiar to developers such as Jenkins. That is not to say that microservices provide some type of free-lunch; once the size, number and complexity of the services move out of infancy, a number of issues need to be addressed including operational overhead, a higher level of DevOps skills and the complication of managing a large number of services, many of which perform some level of service inter-communication.

SOA has been around for quite a while and it is difficult to remember when it was the new kid on the block. For the most part, service development around REST and the JSON data interchange format has taken hold and microservices has made it easier for the mobile developer to easily and quickly build/deploy the services needed to support a mobile application.

Android Version Deprecation

The latest version of Adobe Cordova was released today (v. 3.5) and perusing through the release notes, I saw that they had dropped support for iOS 5, leaving only one major previous release (iOS 6) and the current release. In the past, Android developers have been plagued by the slow release of new versions of the Android SDK to existing Android phones. It has only been in the past year or so that a significant number of developers have moved off supporting 2.3.3 (Gingerbread) and below, making the lowest androidversion number supported being 4.0.3. The question for Android developers is: how aggressively can they move off of 4.0.3 to the next major release, 4.1?

Taking a quick check of the Android smartphones available through the various carriers, none of the phones are lower than 4.1 but a number are at 4.1 (example, the LG Enact and Motorola Droid RAZR M) so, unlike Apple, we as developers cannot move back to only 4.2 and eliminate phones that are still being sold by the major carriers. In all likelihood, the 4.0.3 phones are those who are waiting for their 2-year contract to come up, knowing that the phone will be not be updated by the carrier or OEM. Dropping 2.3.3 loses a developer about 16% of the market but gains in terms of lower bug count (quite a few issues are performance related, trying to use a modern mobile app on older hardware) and a wider selection of third-party tools (which have abandoned 2.3.3 and many are 4.1 and above).

The key issue is supporting 4.0.3 and its 13.4% share. The developer has to determine how resource-intensive the app is and what is the risk of users trying to run it on 4.0.3 (which are also resource-limited) and the subsequent crashes due to memory errors. It is difficult to justify to management a proposal that shuts out almost 30% (2.3.3’s 16.2% and 4.0.3’s 13.4%) of a customer base but the bigger question is: does it make business sense to support a project when the funds required exceeds the return of investment and the risk of poor acceptance in the marketplace when the app’s performance requirements exceeds the user’s hardware at the low end of the curve?

One other consideration I failed to mention is usage by the international market. If the mobile app is targeted outside of the United States/Canada, many lower-end Android phones (white-box, introductory) sold in India, China and Africa are still using 2.3.3/Gingerbread. In the case of tablets, even the low-end 8 GB/under a $100.00 models are supporting Android 4.1 and above (source:

Minimal Viable Product

In a conversation the other day, the focus was around the integration of the Agile methodology with Lean Startup and the cycle of build > measure > learn and how concepts from Lean Startup can complement an Agile software development process. One of the intriguing ideas that carry over into enterprise mobile development is a Minimal Viable Product or MVP. Quite a bit has been written this year about moving to a “mobile first” Minimal Viable Productenterprise, especially as the threshold of “7.1 Billion people and 7.1 Billion mobile phone subscriptions worldwide” has been reached. Corporate IT needs to adapt to this new way of working or run the risk of employees and managers bypassing the IT organization and creating a large shadow IT environment. There have been numerous examples in the past, the one that comes to mind is the Microsoft Access-based systems that cropped up in enterprise departments in the 1990s when IT could not meet the needs of business and so departments created their own IT systems and thus, silos of data with no interoperability. Corporate IT needs to get ahead of this new wave and demonstrate to the business that they are the right organization implement and manage it. It is imperative for IT to embrace mobile by examining how to enable mobile applications and understand the challenges of a “mobile first” environment. The question becomes, how does IT do that?

So, back to the original topic which was the Minimal Viable Product or MVP. IT needs to work with business to identify problems that are occurring within the organization and look to solve it through mobile. In the case of software development, a minimal viable product (MVP) is a software product that meets the minimum requirements of the end user so that these users can test the product and offer immediate feedback to the mobile development team to iterate on. The feedback is reviewed and incorporated into the next build of the product. Releasing the MVP frequently demonstrates to the end users that a) they have a voice into the mobile app’s design and b) the IT organization is attempting to meet the mobile needs of the business. Creating a number of MVPs targeted at various segments of the business user community with an organization allows IT to understand what these groups are looking for, what is useful and how the IT infrastructure needs to adapt to support mobile. Those MVPs that “scratch the itch” of the user community can be further developed into a valuable enterprise mobile application and discard the ones that do not add value.

One word of warning however, as Abraham Wallin pointed out in his article: Lost in Translation: The Minimal Viable Product, the word “Viable” seems to be pushed into the shadows of “Minimal”. A minimal viable product cannot be poorly designed, all of the learning and feedback from the end users is lost and it will be difficult to get the end users engaged for any subsequent releases or other mobile products created by IT. Creating an MVP requires an entire team of UX, interface design and development so that, even though the product may only have a subset of functionality, it meets base quality and usability standards.

The ‘Businessification’ of Tablets

Apple has always been known as a consumer-oriented organization. It’s last business or enterprise-focused product; the Apple xServe rack servers were discontinued at the beginning of 2011. However, a funny thing happened on their way to consumer electronic dominance, they became relevant to business. The evidence is never clearer than the dominance of the iPad as a lightweight business tool. The iPad and tablets in general fit into the executive and manager work styles. How often have you been in meetings where participants are bringing out iPads (or Samsung Galaxy Tab 10.1) to fire up a spreadsheet or a business intelligence dashboard in order to emphasize a point?Galaxy-Note-10.1

Just as smartphone “phablets” have become popular with consumers to view more web data squeezed onto the screen (does anyone use a smartphone to make calls anymore?), vendors are looking to target business users with larger tablet sizes. Both Samsung and Apple are rumored to be releasing 12-inch tablets with Samsung debuting the Galaxy Note 12 (with their S Pen stylus) in early 2014 and Apple with a 12-inch iPad Air. With notebook sales dropping from 13.8 million in 2012 to a reported 13 million this year (2013), tablets have become the mobile go-to device for business executives and managers and slightly larger tablets with a soft keyboard cover will cause even more notebook users to make the switch. Along with the rise of tablets in business, spending on mobile application development was projected to grow by 50% in 2013, to nearly 2% of total IT expenditure. This spending is strictly software development, i.e. developing new mobile applications and making existing enterprise applications mobile-friendly and does not take into account the purchase of mobile hardware (tablets and smartphones).

Mobile Security Reference Architecture

Just recently, the Federal Government handed out a gift (how often can you say that?) to the mobile community.  As part of the new open digital government initiative, the Federal CIO Council and Department of Homeland Security have published the Mobile Security Reference Architecture.  It is a comprehensive picture of the minimal security controls necessary for a particular government department to begin undertaking the support of mobile devices by the agency staff. From a business perspective, it is also important due to the fact that here are comprehensive, best-practice documents vetted by various federal agencies including the Department of Defense.  Imagine, you are a technical architect with some mobile experience and your department head stops by and states that the firm wants to support the sales staff with mobile applications and you are assigned the task of coming up with an enterprise-wide mobile security strategy.  Instead of panicking (queue the picture of Edvard Munch’s painting “The Scream”) and wondering where to start, this document along with the companion documents; Federal Mobile Security Baseline and the Mobile Security Decision Framework provide the building blocks of a solid mobile security architecture that your IT group can utilize to deploy through the enterprise.

Are Tablets Truly Mobile Devices?

No, I am not trying to make a Thorsten Heins-like splash (the BlackBerry CEO who recently stated that “In five years I don’t think there’ll be a reason to have a tablet anymore.”).

If you pose the above question in one of those Jay Lenoesque “Jaywalking – Man on the Street” episodes, the response would undoubtedly be “of course”. Since their debut, both con­sumers and busi­nesses have gen­er­ally con­sid­ered tablets to be a form of mobile devices.  The interfaces for both the iPad and its Android brethren cer­tainly look and feel more like their smaller smartphone siblings than a Windows 7/8 desk­top.  But does that really make sense considering how tablets actu­ally used?

While growing nearly 50% in Q1 of 2013, cellular-enabled tablets still only account for 12% of the tablets sold. So, what’s my point? Tablets are not primarily mobile devices and should not be treated as such.  When creating a mobile app, quite often, tablets are looked at as an oversized smartphone.  Instead, they are truly their own platform and designers/developers must create a differentiated tablet experience or risk dissatisfying the very consumers (either customers or internal business people) they are targeting and thus, missing an opportunity.  As an example, for a given business app, the smartphone version can be seen a summary/quick perusal of a certain set of business information while the tablet should be used to discover and the plumb the depths of whatever the business person is investigating through the tablet.

You Need Mobile Development as a Skill Set

If you have been sitting on the sidelines, looking at the mobile space and wondering if it is worth your time to learn mobile development, think again. According to a recent Gartner report, Android mobile device sales outstripped PC shipments in the third quarter of 2012. Obviously, if you throw in the iPhone/iPad ecosphere, Windows Phone 8 and even the dying RIM devices (queue Monty Python line: “DEAD PERSON:  I’m getting better!”), mobile devices now dwarf PCs in sales and the gap will only get wider. What does this mean? Back in the day, we as software developers were on the forefront on the web application wave.  Businesses were moving from standalone, PC-based applications to web applications hosted in a browser in order to support their diverse and far-flung work force. Depending on which way you fell on the technological divide (Java or Microsoft), you quickly learned how to use JavaServer Pages or ASP.NET to create web-based applications.  images

I think again that front-facing, UI developers are now again at that same crossroads. If you make your living writing business-based, web-based applications, it is now time to understand and acquire development skills in the mobile space, whatever flavor you choose (Objective-C, Java, HTML5/CSS3/JavaScript, or C#). Businesses rarely ride the cresting wave of any technological shift but they have woken up and are looking to their development teams to create externally-facing, customer-focused apps or internally-facing, business-process apps.  You want to be one of those “go-to” people or get relegated to the mundane task of updating all of the copyrights on the web-based applications from 2012 to 2013.  BTW, backend developers are not left out, you need to be able to do more that understand what AWS or Azure means but that is a blog post for another day.