M BILITYH O W T O A V O I D T H R E E Y E A R S O F PA I N

Whystruggles with

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 su�ering 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 classi�ed 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 frommobile – right? (Never mind the deplorable user experience.)

We outsourced our �rst native mobile app project to an agency. Can we carry on like this?

We just delivered our �rst 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

Stage 1 Denial

Stage 2 Grief

Stage 3 Acceptance

/ Why IT struggles with mobility2

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 �nd 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.

Oftentimes, the app an agency delivers is the �rst 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-o� 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-o� attempt to satisfy burning need, which will eventually come back to haunt your IT department. There are no economies of scale. The �rst 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 �rst 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 sta� to take on the maintenance and enhancement of these apps?

DENIAL

1 Juniper Research, Mobile Security, BYOD, mCommerce, Consumer & Enterprise 2013-20182 http://news.netcraft.com/archives/2014/02/03/february-2014-web-server-survey.html3 eMarketer, Worldwide Mobile Phone Users: H1 2014 Forecast and Comparative Estimates

Stage One

/ Why IT struggles with mobility3

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 �nd 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.

Oftentimes, the app an agency delivers is the �rst 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-o� 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-o� attempt to satisfy burning need, which will eventually come back to haunt your IT department. There are no economies of scale. The �rst 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 �rst 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 sta� to take on the maintenance and enhancement of these apps?

4 AnyPresence Mobile Readiness Report 20135 http://www.gartner.com/newsroom/id/497088

new backend systemnew interface new interfacenew backend systemnew interface

new backend systemnew interface new interfacechange request new interface

Serious mobile apps grow fast and become maintenance hogs.

change requestchange requestchange requestnew backend system

change request

new backend system new backend systemnew backend system

new interfacenew interface

new integration

new integration

new integration

Your �rst mobile app: small, cute and likely, inadequate.

/ Why IT struggles with mobility4

We just delivered our �rst 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 �rst 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 �rst-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 di�erent 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 di�erent 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-o�ce applications, a traditional browser look-and-feel may su�ce.

Now, employee front-o�ce or �eld-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.

For some customer-facing apps, a truly native app may be the best �t. 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 speci�c 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

GRIEF

speci�cally 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 speci�c, 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 speci�c 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 di�cult, but you have to get there. Businesses today will not survive without the ability to deliver RWD apps.

Stage Two

/ Why IT struggles with mobility5

We just delivered our �rst 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 �rst 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 �rst-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 di�erent 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 di�erent 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-o�ce applications, a traditional browser look-and-feel may su�ce.

Now, employee front-o�ce or �eld-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.

For some customer-facing apps, a truly native app may be the best �t. 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 speci�c 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

speci�cally 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 speci�c, 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 speci�c 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 di�cult, 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

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 speci�c 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 �rst, 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, �exibility 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-speci�c 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

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 speci�c 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 di�erent 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 speci�cally 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 ApplicationsBy Clay Richardson and John R. RymerForrester Research

“”

Forrester says...

/ Why IT struggles with mobility8

OutSystems® Platform Enterprise Mobile Apps. Delivered Now.

Mobile apps are more than just pretty user interfaces - they need to be properly and powerfully connected to your enterprise. To optimize for speed of delivery, the entire application and its lifecycle must be managed e�ectively.

Visually Develop Your Mobile App. Powerfully Fast. Your Current Skillset.

Utilizing a visual RAD approach, OutSystems® Platform enables any developer to design mobile and responsive UIs without acquiring new skills - harnessing the power of HTML5, CSS3 and JavaScript. Developers use one development environment to design the mobile UI as well as develop the backend logic, work�ow and integration to legacy systems and cloud services. A comprehensive set of pre-built connectors for everything from SAP, Oracle and salesforce.com to databases and cloud services makes accessing and aggregating business data a snap. And you can visually build your own connectors using SOAP and RESTful web services, Java or .NET code.

Cross Platform and Native. All Devices. One Code Base.

Applications delivered with OutSystems Platform are multi-channel ready from day one. From one application design, you can deploy apps, across iOS, Android, Windows Phone, and web, that can easily incorporate native capabilities like geolocation, camera, noti�cations, and on-device app integration.

Open, Zero-Risk Rapid App Delivery Platform.

The applications you create with OutSystems Platform are delivered using open, industry-standard code and stacks.

There is no proprietary framework or runtime that locks you in or slows you down. And our visual RAD approach provides automatic design documentation that survives developer churn, making it easy to maintain large enterprise application portfolios – portfolios that are future proof from changing technology standards and changes in IT sta� and skills.

Automated Continuous Delivery and Iteration.

Creating apps quickly the �rst time is one thing. Being able to rapidly iterate the apps based on user feedback and changing requirements is everything. The key to rapid user adoption is delivering apps that hit the mark the �rst time and being able to react quickly to new and changing requirements. OutSystems Platform was speci�cally designed with this need in mind and the Platform incorporates the most advanced features for user feedback and lifecycle management, including:

One-click continuous delivery - No orchestration scripts or deployment plans

Global dependency tracking across portfolio to ensure proper builds, promotions and rapid change - across all layers (device, backend and integrations)

Security governance controls who does what for all stages of the lifecycle

Ability to capture user feedback directly inside the app

User experience analytics to help developers improve adoption

Over 400 enterprise organizations in 25 countries across 22 industries use the Platform to deliver beautiful mobile and web apps in record time. OutSystems Platform is available as a public cloud, private cloud and on-premises solution.

Learn more at www.outsystems.com

Share this paper on:

© Copyright OutSystems 2014. All rights reserved.

/ Why IT struggles with mobility9