1. M BILITY
H O W TO AV O I D T H R E E Y E A R S O F PA I N
Why
struggles with
2. Today, enterprise developers build web apps or mobile apps. Gone are the days of
building client/server apps. The world now revolves around browsers and mobile
devices.
But, it won’t be long before developers are just building apps. Not web or mobile
apps… just apps. Why? Because soon enough ALL apps will HAVE to be accessible
from whatever device type a user chooses. In the same way web has become the
default for nearly every enterprise app, mobile-ready will soon be mandatory for
any new enterprise application.
Today, enterprise mobile application development is in its infancy, and it is
suffering from the same growing pains that were experienced with client/server
applications in the ‘80s and the web in the ’90s. Companies are struggling with
standards, strategies, architecture, device priorities, and a quickly expanding and
shifting landscape of devices and user expectations.
This paper chronicles the adventures and misadventures of the enterprise mobile
app journey based on our observations working with industry leaders who have
weathered three years of pain to arrive at the same conclusions.
The enterprise mobile app journey can be classified into three stages:
My company doesn’t care about mobile apps. Our users don’t have a need.
Our website and portals are just web apps, so they are accessible from
mobile – right? (Never mind the deplorable user experience.)
We outsourced our first native mobile app project to an agency. Can we carry
on like this?
We just delivered our first iOS app, and now we have to do the same for
Android?!
The developer (or agency) I hired to build our mobile apps is leaving, and we
don’t have the skills or experience in house.
Managing multiple code bases is problematic.
Our need for completely native apps is limited.
We need a new approach for delivering mobile and customer-facing apps.
Why IT struggles with mobility
Stage1 Denial
Stage2 Grief
Stage3 Acceptance
/ Why IT struggles with mobility2
3. My company doesn’t care about mobile apps.
Our users don’t have a need.
It’s possible you don’t have a mobile need right now. Or maybe you’re just not
aware of it because your marketing department has hired their own agency to
build one. But trust this… the mobile tsunami is here! Get ready or drown! Call it
BYOD or BYOT – employee-owned smartphones and tablets used as part of bring
your own device policies will increase to over one billion devices globally by 20181.
So why would you ever build an app now that was not at least mobile ready?
Business units are demanding mobile apps to win, serve and retain customers,
because users expect to find what they are looking for in their current context and
moment of need. One million apps are already in the Apple and Google app stores
and 900 million public web sites now need to become mobile-ready2. Mobile
devices are the go-to tool for the basic things in life – it’s a fundamental privilege.
While the most obvious instances of enterprise mobile apps are B2C, the big
hidden tsunami is actually in the potential mobilization of your partners and
employees. Life has become a collection of mobile moments and life in the
enterprise is following suit.
Our website and portals are just web apps, so they are
accessible from mobile – right? (Never mind the
deplorable user experience.)
By 2017, 2.5 billion people will own smartphones and use them at home and work3.
The enterprise must embrace mobile apps – your customers, partners and
employees already have. Your role is to take advantage of this mobile movement.
Any web site or portal that is not mobile ready today feels as legacy as a mainframe
system to the mobile user. If the primary basis of interaction with the app is
through a keyboard - you’re already behind the curve. We all use cool mobile apps
on our phones or tablets and that is the experience that your employees, partners
and customers expect when they access your business apps.
Which is why any app you build today should be mobile-ready out of the box. Enter
responsive web design (RWD). If you are not heading down this path, you are
already behind. Any web app or portal built today should be leveraging RWD,
making your apps mobile-ready whether users are currently demanding it or not.
RWD is not easy and neither is gaining skills in HTML5, CSS3 and JavaScript. But
there are platforms available that make RWD automatic. In fact, if you are looking at
app dev platforms and they don’t produce applications that deliver RWD apps out
of the box you should move on.
DENIAL
1 Juniper Research, Mobile Security, BYOD, mCommerce, Consumer & Enterprise 2013-2018
2 http://news.netcraft.com/archives/2014/02/03/february-2014-web-server-survey.html
3 eMarketer, Worldwide Mobile Phone Users: H1 2014 Forecast and Comparative Estimates
Stage One
/ Why IT struggles with mobility3
4. Oftentimes, the app an agency delivers is the first mobile app for a company.
Marketing needs a customer-facing mobile app and they want it on the app store.
And it needs to be native, because that’s what the agency said it had to be. No
problem, right?
It is also critical to consider integration requirements and to structure your services
to support the needs of these native apps. In order to avoid one-off development
projects, it is imperative to develop a strategic vision to structure your back-end
services for the growing need of mobile as well as creating an architecture of
reusable components and services that can leverage previous investments.
Are you even in a position with your current development techniques and tools to
take on the delivery of mobile apps at the pace and quality that is expected from
business users? Many IT organizations are just struggling to keep the lights on, with
as much as 85% of IT spend going towards maintenance and support5. This leaves
very little room for innovation let alone something as challenging as building out
and delivering on an enterprise mobile app strategy.
First, hiring an agency to build a consumer-facing mobile app is hardly an
enterprise mobile strategy. It is a one-off attempt to satisfy burning need, which
will eventually come back to haunt your IT department. There are no economies of
scale. The first app won’t be cheap and will likely address one device type and form
factor. Depending on complexity, building a mobile application can run between
$50,000 and $150,000+4. The second app won’t be any cheaper and neither will
changing any of these apps to keep up with demand.
We outsourced our first native mobile app project to
an agency. Can we carry on like this?
Inevitably, the expense of outsourcing these apps, the need for more rapid
iteration and change, or the need for tighter integration with existing systems and
data will bring these apps back to IT. How prepared is your IT staff to take on the
maintenance and enhancement of these apps?
4 AnyPresence Mobile Readiness Report 2013
5 http://www.gartner.com/newsroom/id/497088
new backend systemnew interface new interfacenew backend systemnew interface
new backend systemnew interface new interface
change request new interface
Serious mobile apps grow fast and become maintenance hogs.
change request
change request
change requestnew backend system
change request
new backend system new backend systemnew backend system
new interface
new interface
new integration
new integration
new integration
Your first mobile app: small, cute and likely, inadequate.
/ Why IT struggles with mobility4
5. We just delivered our first iOS app,
and now we have to do the same for Android?!
Hands down this is the most common state of the union for most businesses. Of
course the first app had to support iOS. (Did you pick iPhone or iPad?) And of
course, it had to be native. So you hired, contracted or found the native device
programming skills and the back-end programmers that could make the
integration work. In the best scenario, the 6 to 12 weeks spent on the project
resulted in an app that is now published in one of the app stores. And then, the
typical dynamics of the app lifecycle kick in with a vengeance. The must-have
requirements and change requests come pouring in.
Oh, and now the users want the same app delivered on Android devices and native
too.
If your strategy today gives preference to iOS and Android, there are two other
platforms to consider. The most obvious is Windows Phone, which has experienced
an uptake but can still be discarded for most applications. Not to be ignored is the
web browser. This requirement has been driving enterprise architects to adopt a
one code base, multiple deployment platforms approach that includes the mobile
web browser as a first-class target platform.
The developer (or agency) I hired to build our mobile
apps is leaving, and we don’t have the skills or
experience in house.
Trying to develop and deploy on so many different mobile platforms is a very
common breaking point for many IT departments as this approach does not scale,
does not meet delivery time frames, and requires much different skill sets than are
typically available.
The reason mobile app dev does not come naturally for the enterprise is the
compound nature of the challenge, unseen since the client/server era of the ‘80s.
Many platforms multiplied by many form factors
Mobile is not about cell phones. It is not only about employees outside your
corporate network. It is about making any business application – for employees,
partners or customers – accessible from any device, anywhere, and in a relevant
manner for the device and the interaction.
For employee back-office applications, a traditional browser look-and-feel may
suffice.
Now, employee front-office or field-facing applications are moving from the
desktop onto tablets and smartphones. Responsive web design (RWD) is the
minimal requirement to support these multiple form factors. However, if access to
device sensors is required (e.g. camera, geolocation, barcode scanner), hybrid
(combination of native and web technologies) will be more suitable.
GRIEF
Stage Two
/ Why IT struggles with mobility5
6. For some customer-facing apps, a truly native app may be the best fit. But in many
cases, a strong hybrid option that enables deep integration with device sensors,
while enabling more device compatibility and more rapid iteration of the
application functionality through RWD may be a far better choice. As organizations
come to understand the challenges of managing change across such a large
number of platforms and form factors, they begin standardizing around web
technologies seamlessly integrated with small, stable native code bases.
But chances are you will have some need for all of the above.
One web app = Seven mobile apps
Most desktop web applications can satisfy a very large number of use cases for
multiple user roles. Mobile apps cannot. Given the drastic importance of user
experience for mobile adoption, successful mobile apps are optimized for specific
use cases and personas.
For every one enterprise application, approximately seven mobile applications
need to be built for various users and use cases.
Consider any one business application you have today. Extending that application’s
business functionality and data to mobile users could spawn many new apps built
specifically to support certain use cases. For example, a quoting app for sales
dedicated to the most common product, next quarter’s forecast dashboard for
management, place an order, check inventory, etc. The list goes on, because a
mobile app requires the interaction to be case specific, simple to use, and designed
with the user in mind.
Now consider how many platforms/operating systems that one business
application runs on. Likely, one. However, the seven new mobile apps need to
render and operate perfectly on users’ mobile devices. In most cases, there is a
need to support at least three mobile operating systems – iOS, Android and
Windows Phone - and they have multiple form factors. So, the one business
application is now 21 applications (seven mobile apps supporting three mobile
platforms.)
Considering application changes and iteration, that one business application is
typically updated or revised two or three times per year. Mobile apps are typically
iterated two to three times a month!
Reviewing the math…
One business app, on one platform, released three times a year, is now…
Seven mobile apps, on three platforms, released 30 times a year.
Three builds a year for one business app is now 630 mobile app builds per year.
Now multiply that number by the number of applications that need to go mobile.
So build more, build faster, and make sure everything runs perfectly on every
device - not an easy task.
New tech, new languages, new architectures, new skills
Embarking on a pure native approach will mean learning specific mobile native
frameworks and new languages (Objective-C, Swift, Java, C#). Even though RWD is
web, it can be really hard to get right. It requires expertise in HTML5, CSS3 and
JavaScript. These new skills and techniques are difficult, but you have to get there.
Businesses today will not survive without the ability to deliver RWD apps.
hey, What about me??
Okay... You can join the party...
/ Why IT struggles with mobility6
7. Managing multiple code bases is problematic.
As stated earlier, mobile is not about cell phones or about employees outside your
corporate network. It is about making any business application – for employees,
partners or customers – accessible from any device, anywhere, and rendering it in
a manner that makes sense for the device and the interaction.
In many cases, the device type the user will use to access your all-important mobile
app is unknown. This means addressing an expanding landscape of device types,
form factors, and operating systems (including versions of operating systems).
Most organizations quickly realize that maintaining multiple code bases targeting
specific device types is insanity. The costs, required skills, and time-to-market
considerations make it impractical.
ACCEPTANCE
Accepting this reality is driving most IT organizations to consider an approach or
platform that will enable them to address the vast majority of their users and use
cases with a single app design and code base.
Our need for completely native apps is limited.
After the first, and typically painful, native app project, organizations question the
need for completely native and start challenging the uses cases. Typically, the
marketing department is the hold-out because the ‘me too’ factor of having an app
in an app store that looks and feels like a native app is a marketing requirement not
a business requirement. But beyond that, the need for strictly native is easy to
challenge.
Hybrid mobile apps are a blend of an
open source native shell that
provides access to device sensors
and provides the app store appeal,
with all the productivity, flexibility
and cross-platform capability of
responsive (RWD) apps. With hybrid,
organizations can attack the mobile
challenge head-on with a single app
design and a single code base. And if
architected properly, this single app
design and code base can also serve
as the infrequently needed strictly
native app. By accepting the need to
isolate and limit the number of
device-specific coded apps and
addressing the bulk of the mobile
app needs with responsive web or
hybrid mobile apps, IT can get ahead
of the mobile tsunami and claim the
high ground!
Stage Three
/ Why IT struggles with mobility7
8. We need a new approach for delivering mobile and
customer-facing apps.
The need for a new approach is organizational, technical and operational and can
be summarized as follows:
People and Processes
Create good UX skills internally. Rapid adoption of a mobile app is ALL about
the experience.
Foster collaboration between developers, business analysts, and
users/stakeholders. IT cannot build successful mobile applications in a
vacuum - period.
Release early, engage with users, and tune fast. Because so many mobile
applications have specific use cases in mind, understanding and quickly
reacting to users’ needs and experience is paramount to success.
Tools and Technologies
Utilize responsive web and hybrid approaches to address 95% of your mobile
needs. Isolate the strictly native apps as much as possible to limit the amount
of different code bases and skill sets required.
Deliver rich UI design in a manner that can be easily manipulated and
changed. Detect adoption problems early. Update continuously.
Adopt a backend design approach that will enable you to mash-up and
integrate a wide variety of data sources and services easily. Most change
requests demand new data and services and the expectation will be days,
not months.
Automate DevOps processes to the extreme. Reduce the time of testing,
staging and production deployment. Iterate. Iterate. Iterate. It is the key to
mobile success.
The need to build compelling and highly usable customer and partner facing
mobile apps is driving a new breed of rapid application delivery platform. Platforms
specifically designed to meet the needs of multichannel apps that run perfectly on
any device and can be changed at the speed of business. Forrester has termed this
new breed of apps low-code platforms, and states that:
Hand-coding is too slow to develop and deliver many of the applications that
companies use to win, serve, and retain customers. Firms are turning to new,
low-code application platforms that accelerate app delivery by dramatically
reducing the amount of hand-coding required.
New Development Platforms Emerge For Customer-Facing Applications
By Clay Richardson and John R. Rymer
Forrester Research
“
”
Forrester says...
/ Why IT struggles with mobility8
