Table of Contents

Mockup/prototype • 4

Another thing • 7

Moar things • 9

Mockup/prototype • 12

Table of Contents

How Backend as a Service Enables the Mobile Enterprise • 3

Comparing DIY and BaaS Development Tracks • 7

Selecting target mobile platforms • 8

Mockup/prototype • 10

Analyze backend system interface • 11

Select middleware technology that works with the backend interface • 12

Generate the backend interface • 14

Handling security • 21

Caching • 23

Offline behavior • 25

Page 3 of 27

How Backend as a Service Enables the Mobile Enterprise

To achieve competitive advantage, large organizations today are busy developing mobile

applications that meet two key objectives: 1) enable business processes for employees,

and 2) meet the growing mobile demands of customers. In order to do both, organiza-

tions very often need to integrate mobile apps with enterprise systems and data — col-

lectively referred to as “the backend.” Organizations that do not integrate mobile apps

securely and effectively with their existing backend infrastructure will face competitors

whose employees are more productive, whose customers are more satisfied, and whose

costs are lower.

Historically, many IT departments have gone the do-it-yourself route to integrate with

mobile, often by using homegrown solutions and at other times by cobbling together

various on-premise tools. But just as the cloud has disrupted virtually every other busi-

ness function, cloud-based middleware solutions are now emerging as viable alterna-

tives to DIY.

Page 4 of 27

DIY vs BaaS: The Enterprise Mobility Showdown

Organizations that adopt this type of cloud-based backend as a service (BaaS) typically

do so for the following reasons:

Faster deployment — it takes less time to deploy a mobile app if most of the

backend infrastructure already exists

Faster app performance — because BaaS is their core business, providers are

highly incentivized to constantly find and implement performance optimizations

in their code (and might be expected to have many more years of experience do-

ing it) compared to developers for whom the backend is not a core focus

Higher quality — greater service refinement through constant process optimi-

zation and deep domain experience leads to reduced error rates

Lower TCO — development and support costs can be spread over many users,

and organizations do not over-provision IT capacity to handle demand peaks for

data, thereby reducing expense

Higher reliability — because a cloud infrastructure can scale with demand, app

performance (e.g., screen refresh) remains consistently high

Higher customer / user satisfaction — as quality, reliability and app perfor-

mance all consistently reach higher levels, end-user satisfaction will follow

Higher margins — lower TCO plus higher user satisfaction (hence increased

business volume, lower cost of sales, and more productive employees) equals

more money for the business

The motivation of these BaaS adopters is easy to understand: why spend time develop-

ing and maintaining something that isn’t your core competency when you can outsource

that component to a proven, more cost-effective vendor?

Building out backend infrastructure that makes enterprise data securely and efficient-

ly available on tailored enterprise mobile apps is non-trivial. Furthermore, that backend

“plumbing” — like most plumbing — is non-differentiating. It’s one of those things

DIY vs BaaS: The Enterprise Mobility Showdown

Page 5 of 27

that is only noticed when it fails. So, rather than spend limited resources on challeng-

ing, non-differentiating backend development, organizations often create more value by

focusing instead on app frontend development — i.e., the app’s differentiating function-

ality.

These backend development challenges include:

• Lack of compatibility between backend and frontend development

• Security

• Complexity of third-party APIs

• Architecting highly reusable code

• Legacy databases and systems not engineered for mobile

• Offline operation

• Caching

• Policy management

• User management and access control

• Social login

Using a BaaS, many mobile integration tasks can be accomplished simply by filling out a

form or clicking a few dashboard icons — rather than spending weeks in custom devel-

opment. Often functions such as auto generation of REST APIs are available out of the

box. (A REST API, or application programming interface, is a commonly used mechanism

with which a web service “talks” to an application over the web’s http protocol. It is con-

sidered “lighter weight” and therefore better suited for mobile devices than the SOAP

mechanism which is typically used in the enterprise space to connect web services to

applications running on desktop computers.)

And rather than devise a one-of-a-kind interface for every app, backend data set, or

third-party API that a mobile app might require, organizations typically can use a single

stable BaaS interface to specify virtually any backend data field they want an app to

read or update.

So let’s look at how a BaaS handles mobile’s enterprise integration challenges ver-

sus DIY and how this achieves the benefits cited in speed, cost savings, higher quality,

DIY vs BaaS: The Enterprise Mobility Showdown

Page 6 of 27

greater reliability, higher customer / user satisfaction and ultimately improved margins.

For the sake of our discussion in this paper, let’s also assume that in either case, DIY

or BaaS, the organization is seeking to employ an agile development methodology (al-

though companies that deploy waterfall or other development methodologies can equal-

ly derive value from these comparisons.) So one of the first challenges right at the start

is to figure out how to adapt an agile track to the mobile space.

Page 7 of 27

Comparing DIY and BaaS Development Tracks

For the sake of discussion, let’s assume that software development occurs in seven stag-

es, each of which is iterative within its own scope and within the overall cycle:

1. Receive request to build app

2. Select the target mobile platform(s)3. Wireframes

4. Mockup or prototype5. Core development (backend interface, security, caching, offline operation, etc.)6. Testing

7. Deployment

The highlighted stages (2, 4 and 5) make the most difference in terms of time and effort

when choosing one approach over the other — and hence offer the greatest opportuni-

ty for cost and time savings. In this example, let’s assume we are building a client app to

work with our SalesForce CRM system. Okay, so let’s compare:

DIY

Selecting target mobile platforms

In the DIY scenario, developers are limited in the number of mobile platforms they can support in part because they will have to de-vote resources to building a different backend connection to each platform they target. The problem is: there are lots of platforms. There are two dominant ones by market share, An-droid and iOS, and also several that are less dominant, but nonetheless important, including Windows Mobile, Symbian and Blackberry. The mobile web (i.e., HTML5/JavaScript/CSS3) is also a platform. Then within the An-droid market itself there are also dozens of

BaaS

Selecting target mobile

platforms

By serving as an any-to-any universal

connector, a BaaS can provide a single

interface to each mobile platform the

organization wishes to support. It essen-

tially “commoditizes the pipe,” meaning

that there is no additional connection

“toll” to pay in order to plug a given back-

end data source into another mobile

platform or to plug a given mobile plat-

form into another backend data source.

Of course, the mere fact that a BaaS

could potentially provide such a

important variants of the platform introduced by different device manufacturers.

This typically means (in the DIY approach) that the interface between each data source and each mobile client must be custom tailored, which also means there is a potentially astro-nomical number of unique source-to-mobile connections that must be developed and main-tained over time — even with all the various components of those connections subject to constant change: enterprise data, data formats, connection protocols, middleware, develop-ment tools, mobile operating systems, mobile hardware specs, and more.

This is a new environment for many enterprise developers — even compared to writing desk-top web apps. Those were often targeted for one browser (Internet Explorer) running on one kind of system (Windows PCs). Even though there have been many browsers introduced over the years, and even though Apple desk-tops and laptops have gained significant market share, enterprise IT managers have been able to enforce the IE/Windows standard as cor-porate policy. Such “platform purity” is much harder to achieve in the mobile space when end users (even employees) insist on using their own devices.

commoditized backend pipe does not

mean that a given BaaS actually does.

That’s one of the criteria for evaluating a

BaaS: How easy is it to add mobile plat-

forms on which the organization wishes

to access backend data?

DIY BaaS

Page 10 of 27

Mockup/prototype

Instead of a “mockup,” a BaaS approach

enables construction of a working pro-

totype using sample backend data —

and in less time than to go through all

the work of constructing a “cardboard”

lookalike. (For prototyping you just im-

port sample .CSV or JSON data to Kin-

vey.) Once user buy-in is obtained, the

prototype is essentially done except for

polishing work and implementing securi-

ty.

Mockup/prototype

In the DIY case, the goal is to create a model of what the finished app might look like, so developers can present it to end-users for com-ment and buy-in. A lot of effort is therefore spent making the model as lifelike as possible. Sample screens are mocked up and sample (static) data is typically hardcoded and stored locally. The code used to populate the screens with that data may in fact bear no resemblance to the actual code to be written for the finished app. It is simply there to create an experience that approximates what end-users can expect. Actual work on the production code can only begin after end-user buy-in.

DIY BaaS

Page 11 of 27

Analyze backend system

interface

If a vendor’s BaaS implementation an-

swers these questions already, most

analysis can focus on the frontend, not

backend interface details. In this app,

for example, the developer can just fol-

low the Kinvey Getting Started Guide to

download the library containing the code

needed to talk to the backend.

Analyze backend system interface

How does the backend present its data to the outside world? What type of inputs will the client app give the backend and what type of outputs will the client expect back? What type of API exists on the backend? SOAP? REST? What’s the connection protocol? TCP? HTTP? How will the backend handle errors? What re-sponse codes will be returned? These are some of the questions the DIY developer needs to ask and answer before moving forward.

DIY BaaS

Page 12 of 27

Select middleware

technology that works with

the backend interface

Not needed. Out of the box, Kinvey gen-

erates a REST interface that maps to the

SalesForce SOAP API, which the orga-

nization then tailors based on data field

mappings, etc.

Select middleware technology that works with the backend interface

Since this is a SalesForce example, the devel-oper has to work with a SOAP interface. So de-velopers need middleware technology that gen-erates compatible APIs for the client. They’ll have to check with the SalesForce documen-tation to see if there is a recommended tool-set. (There is. For a full rundown, check the SalesForce API Quick Start Guide). For other enterprise apps, appropriate candidates might be Apache Axis2 (for generating Java-based clients) or WSClient++ (a web service SOAP

Page 13 of 27

client generator for Android, iPhone, and Blackberry on Java). Developers will need to be familiar with the appropriate tools and make an evaluation as to which tool is best suited for their specific situation.

DIY BaaS

Page 14 of 27

Generate the backend

interface

Going the BaaS instead of the DIY route

takes a lot of this back and forth be-

tween development teams off the table.

As a result there is a lot less rework and

a lot less time spent on conference calls

and email — so resources are used more

efficiently. But they are also used more

efficiently because there is simply less

work to do if a BaaS has already done

much of the work already. In the Sales-

Force example, generating a backend in-

terface is a two-step process. First, fron-

tend and backend developers agree on

Generate the backend interface

Once the middleware technology is selected, other implementation choices also need to be made — and both the frontend and backend developers need to agree on these choices. This agreement is necessary if the frontend devel-oper will build an interface to the backend that the backend developer is expecting. What makes this agreement so challenging is that there are so many areas on which the two must agree in order for the interface to work — and in a DIY scenario front- and backend develop-ers may need to negotiate every single item. Areas of potential disagreement run the gamut

Page 15 of 27

what fields from the SOAP interface are

required and, second, they generate the

data link using a Kinvey command-line

application (i.e., they don’t need to write

the interface).

A BaaS can therefore make coming to

agreement simpler in two key ways.

First, it can greatly reduce the number

of variables over which the frontend and

backend teams need to negotiate and,

second, it can make it easier for them to

negotiate over those variables that do re-

main. The number of variables is reduced

to the extent that the BaaS provides off-

the-shelf connections to enterprise data

that the development team would other-

wise need to create on its own. So in the

example described above (i.e., “Opportu-

nities” vs. “OpportunityById”) that discus-

sion would be moot if the BaaS provider

had already written or selected interface

syntax, a connection protocol (e.g., TCP

or HTTP), an interface type (e.g., SOAP or

REST), service ports, etc. That’s often the

case when the backend is a commercial

cloud-based app (again, SalesForce is an

example), where the selections involved

would mostly already be done.

from high-level architectural decisions (like how to implement client-side caching, if at all) to more granular decisions such as whether the data passed from backend to frontend will come over the link in an array.

In this example, one decision to make right at the outset is whether to bind directly to the SalesForce SOAP API or create an intermedi-ate layer (like in a BaaS). Binding directly to the SOAP API takes less development time, but also creates a tighter coupling between the mobile app and the backend application. Why does that matter? Let’s say the organization wishes to change the name of a field in Sales-Force (e.g., “sales lead” to “prospect”). With a tight coupling, that single change means the client app must be rewritten, regenerated and redeployed for all platforms running the mo-bile app. The same would be true if new fields are added on the backend. So, what perhaps looked like a way to reduce development time and cost actually turns out to be just the oppo-site.

Once you have decided on an interface strate-gy, the next step is to decide how to implement that strategy — for example, whether to pass an entire record or only pieces of it as request-ed over the link.

Page 16 of 27

Rather than define all this manually sim-

ply to retrieve specific fields — the de-

veloper just lists the fields to be retrieved

by name and the BaaS stages the data

from the selected fields in the cloud for

delivery to the mobile device. To enable

delivery, the frontend developer needs

to have included the relevant libraries

and also have included the names of the

fields to be imported. Compared to the

DIY case, that’s a lot fewer items for the

frontend and backend teams to agree on,

and far simpler too.

In a homegrown app, however, the BaaS

may not have already mapped to the na-

tive backend interface. But even here,

plugging into the BaaS from the enter-

prise side is simpler than when going the

DIY route. The BaaS API already exists

and is well documented so there should

be no guesswork by the backend team

about whether its code will agree with

the frontend. Then once the BaaS stages

the data all the frontend team must do

(once the relevant libraries are installed

in the app) is write in the names of the

fields to be accessed.

Take a scenario in which a sales rep working in the field needs to pull a sales opportunity re-cord from an enterprise CRM application back at headquarters. Suppose that “Opportunity” is an object containing 100 fields, such as the name of a sales prospect, the person’s con-tact information, the type of opportunity (e.g., “high value,” “low value”) and so on. The backend developer might have decided that the most efficient way to deliver sales oppor-tunities to requesting clients is simply to bring the entire 100 fields of all 1,200 active oppor-tunities over the link. This developer may also have had no other choice, depending on which client-side development tools were selected. Either way, it is then left up to the mobile app to parse whichever fields the user wants to see from the opportunity — which means the client-side developer knows to implement the client code required to do that parsing — a fact the backend developer may assume, but which may not necessarily be true.

That’s also assuming that the client would even know how to call the backend data in the first place — that the client-side developer would write the call the way the backend developer expects the call to be written.

You don’t have to be a programmer to see how the two developers might have written

Page 17 of 27

different SOAP interfaces. In SOAP, a WSDL (web service description language) file con-tains XML syntax — essentially a header that sets up the call by telling the compiler what metadata to expect. So if the client is getting all sales opportunities in one call (as the back-end developer expects) then the WSDL’s XML syntax might look like this:

<SP GetOpportunities>

If, on the other hand, the frontend developer expects to be able to pull only certain fields across the link (perhaps to conserve limited CPU or link bandwidth) then the actual WSDL (not expected by the backend developer) might look like this:

<SP GetOpportunityById>

<input ID>

<output type “OpportunityType”>

Here only data from a specific opportunity object would be passed based on an ID the user input (not all 1,200) — and, in fact, only one field, OpportunityType, would be passed from the object (not all 100). From the fron-tend developer’s viewpoint, this might be the most efficient way to request specific data from a specific record from the backend, given the client’s resource constraints. But obviously if

Page 18 of 27

we finished pages ago

the backend developer did not agree on this approach (or it hadn’t been discussed), the app wouldn’t work.

Of course, such a “discussion” only helps if the backend hasn’t been finished yet. It could very well be, for example, that the backend is a commercial cloud-based enterprise applica-tion such as SalesForce. In that case, no back-end developer may be available with whom the frontend developer can negotiate. In cases where the backend does belong to the enter-prise, the backend may still be written before the frontend. So, again, the backend interface might have been written with more of a “leg-acy enterprise orientation” than a mobile ori-entation — likely leading to backend/frontend mismatches such as the one just described. That can sometimes happen even if the mobile app project requires the enterprise to develop new backend code from scratch.

Why would an enterprise actually choose to develop backend code first? One reason is that backend code runs, by definition, on backend servers. In other words, it runs where most enterprise code runs — so it makes sense that many enterprise developers would start there. They know the tools, the environment, and are highly practiced in both. A substantial portion of the total project might very well appear as

Page 19 of 27

“low hanging fruit.” The problem is that by building a backend to support a still non-exis-tent frontend, the odds are high that the back-end will have to be redesigned and rebuilt later — ultimately extending the project timeline beyond what it would have been if the frontend had been done first.

Even if both the frontend and backend parts of the project are started at the same time, there is still a “meet in the middle” problem that must be solved — which is hard to do in a DIY scenario. Both sides are negotiating decisions about some of the variables in play and making assumptions about others. Many of those as-sumptions will simply be overlooked — lead-ing to a protracted back-and-forth between the two sides, perhaps across wide geographic dis-tances and between people who do not speak the same native language. Even if teams agree on fixes, the sequence of when those fixes are applied can often get out of sync. So one team is applying a patch to its own code so that code can now work with what the team thinks is the current rev of the second team’s code — by which time the second team’s code has also changed based on the last email exchange, so therefore none of the fixes work and neither team knows why.

Page 20 of 27

But how to move data between the backend and the frontend is merely one set of imple-mentation details on which the frontend and backend must agree. Other areas include the caching and offline operation (to be discussed later), as well as features such as social logins and security (also discussed later).

DIY BaaS

Page 21 of 27

Handling security

OAuth support generally involves install-

ing both Kinvey library and the OAuth

service provider’s authentication library.

The provider’s libraries produce authen-

tication tokens and hand them off to Kin-

vey which creates an identity. Installing

the Kinvey libraries means the mobile

app already has the functionality to en-

crypt user credentials, pass them to the

OAuth authentication service as the ser-

vice prescribes, and handling the three-

way interchange between client, server

and the OAuth service provider.

Handling security

There is a lot to do here in the DIY approach — much of it having to do with how the code on both the backend and frontend sides will manage OAuth tokens and provide support for user authentication flow that (in this example) SalesForce requires.

OAuth is one of the newest measures for in-tegrating security for the enterprise — and is currently one of measures being most rapidly adopted for authenticating users of a web ser-vice. Part of OAuth’s appeal is that it passes encrypted tokens between clients and serv-ers rather than usernames and passwords —

Page 22 of 27

and that the tokens are provided by a trusted third-party service. It is that third party that receives, authenticates and stores usernames and passwords — not the organization’s own server. The benefit is that there is much less ex-posure to man-in-the-middle attacks by which credentials are intercepted and decrypted.

Without going into details, suffice it to say that if you’ve never done it before handling this token flow is a complex task, involving among other details authentication system constraints imposed on both client and server. These con-straints can include such things as how long a token is allowed to “live” in the client before it is either used to validate some request or ex-pires — and whether the token is allowed to be cached either on the client or on the backend.Part of this complexity comes from having to select and manage the middleware involved — which requires its own learning curve in addi-tion to the learning curve required for handling the basic interface-to-interface connection setup previously discussed.

DIY BaaS

Page 23 of 27

Caching

Kinvey provides code for in-memory

caching so the only thing the developer

might want to do is tweak the caching

policies that are baked into the Kinvey

library.

Caching

Android (to take one example) requires over 400 lines of code to handle in-memory caching properly and efficiently on the mobile device. So if one of the implementation decisions is to cache data in memory, writing that much code can take significant time and effort. The code is also extremely sophisticated since it must be able to handle fairly complex scenarios such as what to do if two threads try to access the same piece of data without locking up the app. And if written incorrectly, the caching code would be extremely difficult to troubleshoot. One reason is that the app is probably written to assume that some operations take time, so

Page 24 of 27

the fact that data is taking longer to retrieve then expected might not immediately suggest an issue with the caching code.

Other implementation details on the DIY route include determining how and which fields should be cached and the algorithm that de-cides when data is removed from cache (such as a LRU, or least recently used, algorithm). Still another detail is whether the client code needs to explicitly manage the cache on every call or should caching be abstracted (i.e., “built into” the definition of the call object class). Just to handle the cache explicitly may require less sophisticated programming (and so seem easier), it can mean that there will be lots of caching code to maintain throughout the app — which can ultimately lead to more errors, more rework and a longer project timeline.

DIY BaaS

Page 25 of 27

Offline behavior

The BaaS provider can include in its

downloadable libraries code that works

with the backend to automatically ad-

dress many of these offline-versus-on-

line questions — such as whether to

cache a specific piece of data on the lo-

cal device so it’s available to the backend

when the connection is restored. Ideally,

a client library would monitor the state

of the connection continuously and know

what to do when the connection was lost,

such as to trap any errors occurring be-

cause the app is offline rather than let-

ting the app simply crash.

Offline behavior

This takes 1000+ lines of code and typical-ly requires integration with SQLite. That is something else enterprise developers have not typically had to contend with before, even with respect to web apps. With the web they could pretty much assume that users would always be working in areas with robust Internet connec-tivity. So the question of what happens when the app is not connected to the Internet could usually be ignored without significant conse-quences. That’s no longer the case with mobile apps since users will often be working in plac-es (like airplanes) where Internet connectivity cannot be assured.

Page 26 of 27

So then what?

Will the app crash because some data is no longer available? If the app does not crash, will users be alerted that the backend connection is unavailable? Will the application store user inputs on the mobile device and update the backend once Internet connectivity is restored? How will that update occur? What happens if there have been multiple edits to the same data (perhaps by other users who were also offline at the same time)? What about operations that do not involve backend data? Will they contin-ue to operate so that the user experience is the same as if connectivity had not been lost? (Ide-ally, yes.)

Taking the DIY approach automatically re-quires enterprise developers to have answers to all these questions and also that they must know how to implement those answers in code — even though this may be unfamiliar territory to many of them.

Page 27 of 27

Ultimately, what counts, of course, are not the implementation details but the time and

cost it takes to produce a polished high-quality app. Having many of these details taken

care of with built-in functionality means there is less risk of frontend versus backend

incompatibilities; hence, less time spent by development teams going back and forth

looking to prevent or troubleshoot issues. It also means that developers can avoid han-

dling complex middleware, getting up to speed on the latest OAuth security protocols,

engineering advanced caching policies across potentially dozens of different devices,

solving the offline behavior problem (again for multiple devices) and much more.

Instead they can focus on what truly makes a difference to their organizations — the

functionality and experience the mobile app delivers to end-users. A better, more dif-

ferentiating experience delivered at far less cost and on a much shorter timeline. That’s

how you make an enterprise mobile!

Adding it All Up

Page 28 of 27

Written ByMorgan Bickle • @morganbicOn any given day you’ll find Morgan programming mobile SDKs, building

backend APIs, and discussing the future of web and mobile technology. As part of

the core founding team at Kinvey and now the CTO, he owns Kinvey’s

technology vision. Prior to Kinvey, he wrote enterprise software for a decade.

Randall CronkSince 1990, Randall has helped over 250 high-tech companies convey the value

of what they do through white papers, web content, brochures, case studies

and articles. Based today in downtown Boston, he was previously a vice president

with Regis McKenna where he ran the Digital Equipment account.

Project Managed byKelly Rice • @kellyrice88

Designed byJacob McKibben • @ez_Jake_oven

What is Kinvey? Kinvey makes a fully-featured Backend as a Service

solution for enterprises, agencies and individual developers. The compa-

ny’s platform offers 3rd party data integrations, multi-platform support,

push notifications, and custom business logic. Enterprise features, such

as Data and Authentication Links to virtually any business system, are

also available for business-to-employee mobile apps.