Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Perry Hoekstra

Posts by this author: RSS

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 “Salesforce.com 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: Walmart.com).

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.

Linking to Mobile Consumers Through APIs

The recent purchase of Mashery by Intel and Layer 7 by Computer Associates highlights the importance that APIs (Application Programming Interface) have become in exposing internal corporate services to mobile developers, both corporate and outside. Corporations are beginning to understand that one of the keys to users interacting with their services is through mobile and mobile applications.  A robust, well-crafted and well-documented API is the gateway for a network of developers to begin building mobile apps that engage consumers.  Corporate mobile developers are a scarce commodity and are normally tasked with critical, internal mobile projects. By building out an API, it allows the creativity of outside mobile developers to build unique and engaging mobile applications that draw new customers to a firm’s products and services.  There is the concern by a firm that there could be a loss of control over the firm’s brand by allow third-party development against their services.  The first step in mitigating this concern is the creation of a Terms of Service agreement that all developers who wish to use the firm’s services must abide by in order to receive an authorization key to gain access.

Using software such as Mashery, Layer 7, and Apigee will not automatically create compelling API’s, the onus is still on the developers to craft those APIs but it is a key piece in a firm’s business to consumer (B-to-C) strategy.  This new breed of API management software (also called a Service Delivery Platform) eases the creation and management of developer portals, key and authorization management, metering of service requests and the linkage between the externally-facing service (usually REST-based) and a firm’s internal SOA platform that may contain a significant amount of SOAP-based services.

New Class of Prototyping Tools

If you believe you are a good software designer, the great news about creating mobile applications is that with mobile apps: design is everything. Time and time again, it has been show that users value good design and its impact on usability. As with everything else in life, we’re all individuals, with different preferences and ways of approaching design.  There are a number of mobile developer/designers who don’t believe that “paper is dead”, instead, take the position that they come up with more fluid layouts when not in front of a computer.  Other designers prefer to work in Photoshop, creating designs that seem ready for the App Store.  For me, one is too hot, and the other, too cold.  In the case of Photoshop or Axure, I would find too much attachment to the work I put in to the screen mockups to readily change them based on user input.

In my case, I find rapid prototyping beneficial to meet the following limited goals:

  • Investigate the key points of the proposed solutionbalsamiq
  • Test the navigation and overall content structure

This is the point of this blog post, to call attention to a new set of rapid prototyping tools for the creation of mobile applications.  Using my favorite screen prototyping tool, Balsamiq, I was able to export my mobile screen mockups to *.png files.

Using the tool InVision, I uploaded the *.png files into the Build Mode. From there I was able to identify clickable zones in my screen layouts and link them to the other screens that I uploaded. From there, I can export a link to the screens to a smartphone and bring up that link in the smartphone browser and navigate through my screens testing the application navigation.  Other features include the ability for other users of the functional mockup to make comments to specific points of the screens.  The tool supports both the Android and iOS environments.

Once you use the tool, the benefits become immediately apparent when users can touch and navigate through a facsimile of the proposed app.  If your tool of choice is something like Photoshop, you users could touch and play with what would seem to be the real app. Either way, having an app that could function on a phone is considerably better than looking at screenshots on a computer or looking at wireframe documentation.