Development of Mobile Applications in Regional Companies

Status Quo and Best Practices

Tim A. Majchrzak and Henning Heitk¨otter

Department of Information Systems, University of M¨unster, M¨unster, Germany

Keywords:

App, Business App, Mobile Application, Best Practice.

Abstract:

Within a few years, smartphones and tablet computers have spread dramatically. While their hardware has

become more powerful, the versatility of devices is driven by applications for them. These so-called apps

are increasingly developed for business purposes. We wanted to ﬁnd out whether apps are interesting for

all businesses, how they think apps can be useful for them, in which way they consider to use them, and

what kinds of challenges and problems they see. Therefore, we worked with local companies and conducted

interviews. By analysing the transcripts we got detailed insights of the practial relevance of using apps. We

present the status quo of app development by local companies, highlight early best practices described by

them, and discuss our ﬁndings. Thereby, we raise topics for future research.

1 INTRODUCTION

A couple of years ago, the only mobile devices widely

used were mobile phones, which focused on (speech)

communication. In theory, the functionality of mobile

phones could be extended by e.g. installing small ap-

plications written in Java ME. This was seldom done,

though. Other devices such as personal digital as-

sistants (PDAs) have to be seen as niche products.

Within a few years, smartphones and tablet comput-

ers have spread dramatically. They have mostly re-

placed PDAs as well as other mobile devices. With

their increase in popularity, a paradigm shift can be

observed. Communication is only one of many func-

tions. While the hardware has become very power-

ful, it is the software of smartphones and tablets that

makes them successful. Mobile applications – apps –

make them versatile and adaptable yet easy to use.

At ﬁrst, apps were developed either by vendors of

mobile platforms such as iOS (Apple) and Android

(Google) or by enthusiastic individuals. Slowly but

steadily, enterprises are now exploring the possibil-

ities of using apps. The number of apps developed

with a commercial interest in mind grows. We wanted

to ﬁnd out whether apps are interesting for all busi-

nesses, how they think apps can be useful for them,

in which way they consider to use them, and what

kinds of challenges and problems they see. Business

adoption is too recent to get insights from quantitative

studies. Thus, we worked qualitatively in a project

with regional companies. While this seems like a lim-

itation, it enabled us to keep close contact and conduct

very detailed interviews.

This paper presents results from our project.

Whenever possible, general implications of our ﬁnd-

ings are given along with a discussion. Our work

makes several contributions. Firstly, it depicts the sta-

tus quo of app developmentas derived from a regional

sample. Secondly, it presents early best practices

learned from the companies. Thirdly, it discusses as-

pects of app development that pose particular chal-

lenges. Fourthly, it theorizes about these ﬁndings and

points to general ramiﬁcations. Findings are speciﬁ-

cally suited for businesses just beginning to examine

mobile scenarios.

Section 2 of this paper motivates the importance

of business apps and explains the background of our

project. The status quo of app development as derived

from our business partners is described in Section 3.

In Section 4, early best practices for business app de-

velopment and usage are compiled. Section 5 presents

a discussion of our ﬁndings. An overview of related

projects is given in Section 6. Finally, Section 7 draws

a conclusion.

2 PROJECT BACKGROUND

Apps are, generally speaking, lightweight, easy-to-

use, and optimized for the particularities of mobile

335

Majchrzak T. and Heitkötter H..

Development of Mobile Applications in Regional Companies - Status Quo and Best Practices.

DOI: 10.5220/0004359303350346

In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST-2013), pages 335-346

ISBN: 978-989-8565-54-9

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

devices, such as screen size and prevalence of touch-

screens. They are distributed via a mobile platform’s

app store. Demand for apps from consumers and busi-

nesses alike is very strong. Often, customers expect

companies to be present on mobile devices in one way

or another. They want to be able to use their smart-

phone to access a company’s services from every-

where. There are apps of all conceivable categories,

ranging from games over social media to shopping.

Our work focuses on business apps. We under-

stand them as mobile applications that support busi-

ness tasks. This deﬁnition is broad by intention. It

for example includes apps that employ sophisticated

graphics (or even are games) but serve a marketing

function. However, in most cases apps with form-

based input and output are concerned. Apps are in-

teresting for enterprises with respect to several us-

age scenarios and target audiences. Firstly, a com-

pany may want to provide its employees with apps to

support its business processes. Secondly, it may offer

apps to its customers for marketing, sales, or servicing

purposes. Thirdly, a company with a focus on soft-

ware development may develop apps for and by or-

der of its clients according to their requirements. For

companies that support at least parts of their business

processes with IT, the integration of mobile devices

into these processes appears as the next logical step.

Developing apps poses several challenges, espe-

cially to small and medium enterprises, due to sev-

eral particularities. Up to now, the mobile market

is heavily fragmented into incompatible mobile plat-

forms like Android, iOS, or Blackberry. This leads

to increased development and testing efforts. Fur-

thermore, mobile operating systems are quite differ-

ent from well-known desktop operating systems and

limited in scope, requiring new concepts.

Small software development companies or busi-

nesses with small IT departments often lack the re-

sources and expertise of larger enterprises, but are still

eager to proﬁt from the aforementioned beneﬁts of

apps. They often have no experience with app devel-

opment and no department specialized in mobile top-

ics. This was the starting point of our research into the

state of mobile development. We contacted several

regional companies that proved to be interested in the

topic and set up the project Business Apps. As part of

the project, status quo and best practices of app devel-

opment were of a particular interest. The participants

were selected from a pool of companies managed by

the local chamber of commerce. All of them either

have IT-intensive business processes (e.g. as ﬁnancial

service providers), or offer IT services and software.

In other words: they share an interest to support their

business with IT. Participation was of course volun-

tary; therefore, not all companies we contacted actu-

ally took part in the project.

Our department was responsible for managing the

project and conducting the research. 11 regional ﬁrms

of varying sizes and from different industries partici-

pated. We chose to ﬁrst concentrate on a manageable

number of regional companies in order to allow for

in-depth conversations and insights. For a start, we

regard this qualitative approach to be preferable com-

pared to a quantitative survey, because a basic under-

standing of the current state of mobile development

is still missing and is better elicited through personal

interviews. With this paper, we intend to examine the

current state and provide results which can later be

used to plan larger surveys.

In order to investigate the status quo, gather typi-

cal requirements of business apps, and recognize best

practices, we conducted semi-structured expert inter-

views mainly with managers but also with develop-

ers. Based on a questionnaire that gathered quantita-

tive data of the respective company prior to the actual

interview, we discussed several areas: after an intro-

duction, we considered the company’s current state

of app development – how many apps, if any, had

been developed already?; if none, why not?; which

use cases did the apps support?; how (well) did the

development process work from a business and from

a technical point of view? This was followed by ques-

tions about the expectations and requirements on the

development process of apps. Lastly, we asked our

partners about their future plans.

Interviews were guided by an outline of questions,

but gave plenty of room for discussion. We did not

ask the questions one after another, but let our part-

ners talk guided by intermittent inquiries from our

side. This ensured a lively discussion, while still han-

dling all important topics. The outline was developed

based on our prior knowledge of the area and keep-

ing in mind general criteria for developing software

as described in the literature on software engineering

and information systems development. Moreover, we

followed the approach chosen for a project in a sim-

ilar setting: qualitative research with a small number

of participants and long, open inteviews (Majchrzak,

2010a; Majchrzak, 2010b). This combination made

sure that we did not leave out important aspects. At

the same time, the openness of the interviews made

sure that notable issues that could not be anticipated

would still be captured because they would likely be

named by the interviewees. As a consequence, inter-

views lasted about 90 to 120 minutes on average.

After the interviewing phase, we compiled infor-

mation on the status quo from transcripts of the in-

terviews and analyzed it for typical statements and

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

336

often mentioned wishes and expectations. Section 3

describes the result. We also aggregated success-

ful strategies mentioned during the interviews and

analyzed them for general applicability, resulting in

best practices (Section 4). Moreover, we found sev-

eral topics of particular interest to smaller IT depart-

ments concerned with app development (Section 5),

for which no satisfactory solution is available so far.

3 STATUS QUO

In this section, we describe the status quo broken

down into the state of development, requirements, and

future plans.

3.1 State of App Development

3.1.1 Apps Developed so Far

All participating companies had developed ﬁrst apps.

However, the number was small and typical projects

were proof-of-concepts. To categorize the apps the

level of heterogeneity was too high. In general, most

apps were designed to be used internally. Some of

them would normally target customers but were im-

plemented for internal assessment.

The described apps share a characteristic: very

limited functionality. Only some of them represent

new ideas. Many apps transfer existing functionality

to the mobile realm. Interviewees often told us that

functionality available as a Web site would be pro-

vided by apps more comfortably. These apps usu-

ally did not yet incorporate the full functionality of

the considered Web site but only its core services.

Those apps not based on existing functionality are

very simple. Oftentimes, only a single function is

provided, typically supporting workﬂows or enabling

easy access to information. A typical example is a cal-

endar tool for trash collection days published by a lo-

cal service provider. A majority of apps is concerned

with providing access to information. Managing or

even entering data still is negligible. We only learned

of few app for that purpose. One was a kind of virtual

clipboard used by mechanics to guide inspection ac-

tivities and send data to a backend. It also made plau-

sibility checks e.g. to make sure that all necessary in-

spection steps were followed. Another app was used

by ﬁeld staff equipped with tablets. It provided visu-

alization and simple calculation of tariffs of ﬁnancial

service products.

Some apps did not even serve a purpose in terms

of functionality. They were merely developed to as-

sess functionality and especially development frame-

works such as PhoneGap (PhoneGap, 2012) (now

Apache Cordova (ApacheCordova, 2012)) or the

Sybase Unwired Platform (Sybase Unwired Platform,

2012). The same applies for demonstration apps, e.g.

a management cockpit to observe real-time data.

Besides realized apps, many projects had been

driven to the design phase but not yet been imple-

mented. This can be explained with the complexity

of such apps. The participants described customer-

centric apps; some of them were supposed to include

cartographic services or make use of device-speciﬁc

services such as the camera. Realizing these apps

would be very valuable as novel services could be of-

fered to customers. However, the companies found

it very hard to estimate the actual effort required for

doing so. Some companies also scrutinize the pos-

sibility of adopting or adapting apps by third-party

vendors, speciﬁcally for Personal Information Man-

agement (PIM).

It has to be noted that the process for initiating

apps was versatile. Instead of being launched by cen-

tral management, several prototypic apps were built

on employees’ own discretion. These employees had

acquired the necessary skills in their free-time and out

of curiosity. Some companies realized the potential

and provided support by assigning some time for free

experimentation or by organizing workshops for ex-

perience sharing – the latter were partly held on week-

ends.

3.1.2 Platforms

Two approaches could be observed for platform

choice. The ﬁrst was to implement for one platform

only: Android or iOS, sometimes Blackberry. Usu-

ally, this choice was made for apps that were designed

for internal use or merely as prototypes. The second

was to support Android and iOS. Quite notably, al-

most none of the projects targeting customers sup-

ported other platforms while companies stressed the

importance of supporting these two. Not supporting

the platform chosen by customers was perceived as a

risk due to many peoples’ quite emotional attitude to-

wards “their” platform. One company noted that the

choice of platforms should target to “win and safe-

guards the trust by customers”.

Cross-platform development was only seen as im-

portant if customers were the target audience. The

participants usually did not support a bring your

own device (BYOD) policy fearing security problems

due to employee-maintained smartphones and tablets.

Particularly those companies that had provided staff

with devices (usually Blackberry units) even prohib-

ited BYOD. A common strategy for choosing mul-

tiple platforms was to take Android and iOS due to

DevelopmentofMobileApplicationsinRegionalCompanies-StatusQuoandBestPractices

337

their market shares and to develop an additional Web

app to support all remaining platforms. Some compa-

nies argued that they still could develop an additional

native version should another platform gain relevant

shares among their customer base. Some companies

refrained from multi-platform support despite its con-

ceptual merits. Reasons were high effort, problems

regarding usability and support of native appeal (e.g.

due to differences in gestures such as swiping), and a

highly increased administrative overhead.

We particularly wanted to learn whether compat-

ibility to multiple platforms would be sought in the

future. We found several, in parts strictly contrasting

approaches: The pragmatic point of view is to sup-

port whatever platforms are demanded by customers.

Several companies follow this paradigm. Prioritizing

usability means to weigh up between Web apps and

native apps while seeking to minimize effort. A Web-

based strategy neglects native look & feel and waits

for more device-support to be built into technologies

such as HTML5 (HTML5, 2012) (which can be used

to build fancy apps already (Zibula and Majchrzak,

2012)). The dual way proposes to support the most

important platforms natively while using a Web app

to serve all others. The desire to prevent effort may

strive for supporting relevant platforms but perceives

additional effort with skepticism. Following an ob-

servant strategy, one platform is picked for now but

market development is followed closely. Finally, for

internal usage a deliberate decision for one platform

in accordance with hardware investments is made.

3.1.3 Decision Processes

The kind of developed apps and especially the se-

lected platforms are strongly inﬂuenced by technical

underpinnings. However, due to our business focus,

we also wanted to understand which decision pro-

cesses lead to the development of apps. Hence, we

made this a topic in the interviews.

The simplest option is contract work for a cus-

tomer. This is only relevant for some of the partic-

ipating companies, though. Whether multiple plat-

forms are supported solely depends on the customers’

requirements – and budget.

In several cases, the companies developed apps

proactively to reﬂect anticipated requirements. These

apps were offered to key customers. Some of them

also regularly conduct workshops with customers in

which requirements are discussed. This in particular

is popular if customers are shareholders at the same

time (e.g. in cooperative legal entities).

Internally used apps are usually requested by the

departments that want to use them to support busi-

ness processes. Design is problem-drivenin this case.

The same is possible for external development, but

not typical. App development projects initiated by

management or even executives were not reported.

One large company had several app development

projects initiated by their department for innovation

management. The company provides IT services and

tries to keep up with cutting-edge development to of-

fer solutions that are mature and safe for business

in alignment with rapid technological progress. Al-

though this requires considerable effort among ac-

cepting the risk of following technologies that ulti-

mately fail, this company had an edge in app develop-

ment.

Regarding technological speciﬁcations derived

from business decisions, no clear picture can be

drawn. Most companies have not decided on a strat-

egy, yet. Choice of technology is project-determined.

Internal app development often is strongly inﬂuenced

by the hardware strategy. If a company e.g. ﬁxed to

equip employees with Blackberry devices, app plat-

form and development frameworks are mostly prede-

termined. Only some companies have decided on an

intermediate strategy for the next few years; this usu-

ally stipulates the support of Android and iOS.

The interviews were used by several company rep-

resentativesto utter criticism. For example, the closed

nature of the iOS platform was seen as counterpro-

ductive while the importance of it prevented compa-

nies from not adhering to Apple’s policy of acquir-

ing a developer’s license. Other representatives com-

plained about the level of investment security. The

(hostile) coexistence of a number of platforms re-

minds them of the browser wars of the 1990s. The

usability to decide which platform is worth to acquire

knowledge for is seen as a dilemma due to simulta-

neous customer demand. Finally, security was seen

as a main concern with only Blackberry providing

sufﬁcient support (also see Section 5.1). It has to

be mentioned, however, that all participants perceive

profound chances in using the new technologies.

To conclude this phase of the interviews, we asked

how satisﬁed the companies were with their current

progress. Not all companies wanted to take a clear

position but the general attitude was positive. This is

remarkable since experiences are still very limited. At

the same time, satisfaction reﬂects to some degree the

potential seen in mobile devices.

It has to be noted as a ﬁnal remark that some com-

ments on technical issues were contrary to statements

regarding decision processes. For example, iOS was

praised for its ergonomics and the low effort in coach-

ing employees in using it. This, however, at least par-

tially relates to the restricted nature of the platform

that enforces design standards.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

338

3.1.4 Distribution

Apps may be distributed differently than typical for

classical applications. Data storage devices such as

optical discs are inapplicable. Rather, users download

apps from Web sites or access them via app stores.

The latter are organized similarly to Web shops are

provide good overview and easy installation. For

commercial purposes, software distribution tools are

available. To our knowledge, these tools are not (yet)

as powerful as their counterparts for distribution of

software onto commercial workstations and servers.

In common, companies are in favor of app stores.

It is very comfortable for their customers to ﬁnd and

install apps. The possibility to rate apps is seen as a

positive enforcing to develop good apps. However, if

apps can be commented there also is the risk of un-

justiﬁed criticism. Some companies regard app stores

as the only interface to customers; providing them

for download on corporate Web site is seen as awk-

ward style. App stores are also considered for internal

deployment (so called enterprise app stores). There

have been critical remarks concerning the deployment

time of app stores. It would be “quite cumbersome”

for Blackberry and require “up to two days” – for each

deployment. The mandatory checks in Apple’s app

store could take up to a week.

Automatically keeping employee-owned devices

up-to-date is seen as a problem. It is vital to e.g. in-

stall security patches without user interaction. Mo-

bile Device Management might be a solution (also

see Section 5.1). Particularly Blackberry (or rather

its vendor Research In Motion) was described as ad-

vanced in this regard. Apple is seen as focused on

consumers but shifting to recognize business cus-

tomers.

In contrast with our expectation, virtualization

was not mentioned in the interviews. While virtu-

alization on workstations is used routinely and em-

ployees connect to the corporate network using ter-

minal servers, virtualization on mobile devices does

not seem to be considered. It might, however, be a

future way to offer access to resources and to increase

security. This speciﬁcally applies to allowing BYOD.

Finally, it has to be noted that enterprises currently

do not plan to offer premium services or to sell apps to

end-customers (i.e. consumers). Such services might

become available in the future but most of the com-

panies we interviewed see apps as an instrument for

customer relationship management or to support pro-

cesses.

3.1.5 Development

The next step was to have a look at the implementa-

tion of apps. No processes speciﬁcally tailored to

apps could be observed. Development is conducted

like for other application; due to the nature of apps

particularity methods of graphical user interface de-

sign are employed. It was noted that app development

should be rapid; therefore, agile-inﬂuenced processes

are used even if normally not used by a company.

A particularity is the team size: it typically is one,

i.e. one app is developed by one employee. If they

become larger,development processes ought to be ad-

justed. Roles might be aligned with the structure of

apps as determined by the platforms. Android ad-

heres to a modiﬁed model-view-controller(MVC) de-

sign pattern which would allow for differentiated de-

veloper roles. The “one developer” philosophy also

leads to a rather unstructured proceeding. At the same

time, there can be signiﬁcant effort for learning tech-

nologies. Mastering powerful libraries such as jQuery

Mobile (jQuery mobile, 2012) is not trivial.

Regarding the development for multiple plat-

forms, it was noted that there should not be multiple

projects. Rather, a single project would ensure persis-

tent quality on the different platforms. Moreover, it

was noted that apps should strive for a native look &

feel; Web apps would not be perceived as “real” apps

by customers.

App testing poses novel challenges. In partic-

ular, coping with the different contexts an mobile

application resides in is by no means easy (Schulte

and Majchrzak, 2012). An example is the transi-

tion between different network connections. More-

over, device fragmentation is a problem since func-

tions change with devices and there are great differ-

ences in available performance.

A ﬁnal observation is that only few employees

(and a small share of all developers) have experience

in app development, yet. It can be expected that this

will change soon.

3.2 Requirements for Developing Apps

Requirements engineering is an essential activity

(Hull et al., 2010). If it is not done meticulously, the

ﬁnal application will be different from what was ex-

pected. Therefore, we discussed the role of require-

ments for app development. Mostly non-functional

requirements (i.e., concerning an app’s quality) were

named, as we did not ask for requirements for one par-

ticular app but for expected general characteristics.

It was argued by the companies that require-

ments should be gathered in a context-dependentway.

Device-speciﬁc functionality like acquiring GPS co-

ordinates or using Near Field Communication is of-

ten important. A particularly named requirement was

DevelopmentofMobileApplicationsinRegionalCompanies-StatusQuoandBestPractices

339

to develop apps that would enthuse users. However,

we expect that this is just a temporary requirement

and part of the hype. Some general requirements

were named very often. Smartphones and tablets are

easy to use; thus, apps should be easy to use. They

should look good, provide sufﬁcient performance and

responsiveness, be adequately secure, and adhere to

privacy standards. There was no clear line regarding a

native look & feel. For several participants, this visual

criterion was the most important non-functional re-

quirement; for some, however, it was negligible. En-

ergy efﬁciency was a secondary requirement only but

we expect it to become much more important in the

future.

Special requirements could be observed for con-

nectivity. Originally, apps were supposed to either

be online at all times or to work ofﬂine. However,

for many scenarios, it is required to load information

if a proper connection is available but to be able to

work without a connection as well. This is not trivial

to realize and might furthermore require sophisticated

synchronization mechanisms.

In general, apps need to be robust regarding im-

proper input data due to the way they are used. Touch-

ing the display is considered to be more prone to erro-

neous input than using an application with keyboard

and mouse.

To ease the usage of apps, they should ideally pro-

vide a single-sign-on functionality. This might lead to

problems, though. Typically, smartphones and tablets

are used by a single user – but this is not always the

case.

Compliance with typical requirements for com-

mercial software might be impossible. For example,

many companies have policies that enforce anti-virus

software. Hardly any products are available for mo-

bile devices, though. It is unclear what the reaction

to this situation will be. Compromised customer data

should be avoided at all cost. Moreover, there might

be a need for speciﬁc privacy. An app that e.g. re-

quests location-based services might seem harmless.

If it, however, sends location data to a server reg-

ularly, an insecure connection or a data-leak in the

server would be dramatic as it would allow for creat-

ing movement proﬁles.

Asked about practices for requirements engineer-

ing or the creation of requirements catalogs for apps,

companies told us that is was too early to be speciﬁc.

3.3 Outlook and Conclusions

In the last part of the interviews, we asked companies

about their future plans and scrutinized the overall im-

portance theysee in apps. For all participating compa-

nies at least the usage of IT but in many cases also the

development of IT products has strategic relevance.

Asked about the relevance of apps, some companies

could directly take a position. Some companies see

apps as part of their corporate strategy while others

only consider them as operative tools. Some also em-

phasizes that it is not their perception that matters but

their customers’.

The companies for which apps have strategic im-

portance usually share a set of expectations. Exam-

ples are the

• estimation that PCs and notebooks usage will de-

cline,

• assumption that most people will have a perma-

nent Internet connection in the near future,

• believe that Web-based solutions have extremely

high accessibility, and the

• prediction that customer contact will increasingly

be bi-directional, involving them in product de-

sign.

Seeing apps as a mean to improve processes un-

derlines the great deal of optimism a number of com-

panies have.

About half of the participats plan to increase in-

vestments to put more emphasis on apps. The other

half plans to assign more budget to app development

but to cut down equally on other activities. The com-

panies do not expect apps to fully replace other instru-

ments e.g. for marketing, though. In general, prices

for mobile device hardware and app development re-

lated infrastructure are expected to plummet.

When asking for a conclusion concerning the sta-

tus quo of app development, the already reported

satisfaction was acknowledged. However, this was

mainly driven economically: current investments

were worth it. Technologically not all companies

were completely contented. Particularly the current

compromises between quality and effort were seen as

unsatisfactory. The economic satisfaction is driven

by ﬁnancial success: even some of the smallest app

projects paid off; learning curves were told to be

steep. Unsuccessful projects were not necessarily

seen as failures since the gained experiences had

value. Acceptance of apps among customers and em-

ployees beyond a hyped interest could not yet be fully

assessed, though.

Finally, we asked the participants to name room

for improvements and to provide us with their out-

look. Progress was desired in several areas. Firstly,

advanced language recognition would open up com-

pletely new possibilities. Secondly, security should

be improved. Companies would particularly like to

see more emphasize put on security on Android and

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

340

iOS. At the same time, not all of them considered the

concept of Blackberry as perfect since it was seen

as a kind of security by obscurity. Thirdly, multi-

platform support should be possible with small bud-

gets. Fourthly, data throughput during mobile us-

age should be increased. Fifthly, synchronization of

app and backend should be supportedby sophisticated

tools. Sixthly, enterprise support is trailing and needs

to be improved.

In general, technological innovation were sought

that would enable companies to accept less compro-

mises when developing apps. Moreover, companies

have a desire to learn about customer expectations. In

addition, they would like to see studies and evalua-

tions, e.g. of development frameworks.

4 BEST PRACTICES

In the following, best practices as derived from the

experiences of the participating companies are de-

scribed. Due to the early state of app development,

they are mainly meant to be thought-provoking im-

pulses. Best practices for cross-platform app devel-

opment are not given as the level of knowledge about

this is low in companies; work on cross-platform

best practices has for example been described in

(Heitk¨otter et al., 2012).

The ﬁrst best practice is to use apps to motivate

developers. Several companies reported employees

would acquire knowledge on app development on

their own. Obviously, the topic is seen as fun rather

than as work. While this cannot be universally as-

sumed for any kind of app development, it might be

utilized. If possible, app development projects should

be seen as an incentive for employees willing to work

on them. Ideally, developers should feel that they can

contribute to the success of their company in adopt-

ing a new technology. However, incentives should be

used with care. Employees that do not share the en-

thusiasm for apps should not feel like the work they

do is considered subordinate.

Secondly, focussing on component-orientation

and service-oriented architectures (SOA) is recom-

mended. While many apps were build as single en-

tities, they are suited to be constructed from standard-

ized components and to use SOA.

Many commercial apps display information and

are used to enter data. The functionality typically

found is quite similar. For example, several types

of diagrams will often be used for visualization and

many apps will need to process master ﬁle data of

customers. Therefore, such apps should adhere to a

common architecture and be built as far as possible

from standard components. The initial effort to cre-

ate such components will be higher than to develop

a single app but break even usually is reached with

the second app already. As a positive side effect, the

app landscape will become easier to overview. How-

ever, which components to provide as standardized

artifacts and which to design individually has to be

chosen with much care.

The usage of a service-oriented architecture

makes sense if the company is using SOA anyway

and apps rely on backend systems. At a ﬁrst look,

using services seems to be adverse for enabling apps

to work without a reliable Internet connection. How-

ever, having orchestrated services can be beneﬁcial.

Instead of relying on a great number of single re-

quests like in a typical client/server-architecture, data

is gathered by the backend and exchanged with the

app client in few service requests. This could also

save computational effort on the device and thus in-

crease battery life. Relying on data processing in

backend systems might also increase security. It is

considered to be simpler to secure the connection be-

tween app and backend then to design secure apps. A

ﬁnal critical remark has to be given, though: imple-

menting SOA solely for apps is not considered to be

a good strategy.

Thirdly, we found that enterprise apps might serve

to increase information availability. Mobile devices

are particularly suited for providing information. The

ﬁrst step should be to determine which information

can be made available, and whether it makes sense

to have it available mobile. Mobile in this case is

an elastic word: it starts with an employee sitting at

his desk and using a smartphone since data access is

faster or more convenient. It can mean that employ-

ees check their appointments for the next day after

returning home. It goes as far as working completely

remote.

The second step is to consider the level of criti-

cality of information. The more critical they are, the

more effort needs to be put into security for mobile

access. The third step is to provide access by means

of an app. It is advisable to make apps as customiz-

able as possible. Employees will then be able to use

them more effectively. While many companies de-

scribe this kind of usage as very rewarding, it is hard

to assess its monetary value. An expected increase

in employees’ working precision and speed is hard

to measure and even harder to attribute to such small

changes as introducing apps on mobile devices.

Particularly due to having several ﬁnancial service

providers among the participating companies, a fourth

best practice could be derived: the support of ﬁeld

staff and sales. Reports from usage of mobile de-

DevelopmentofMobileApplicationsinRegionalCompanies-StatusQuoandBestPractices

341

vices in this area were very convincing. There are

two possible usage scenarios: visualization and data

entry. The ﬁrst step usually is to provide visual access

to information. Tablet computer are well suited for

this task due to their larger screen, their convenient

size, and the less person-attributed feel in comparison

to a smartphone.

The vision of using tablets for visualization is to

replace pen & paper. They are essential for ﬁeld staff,

e.g. in an insurance sales scenario. In the course of

appointments with customers tariffs haveto be shown,

calculated, and adjusted. Calculating and visually

demonstrating individual options requires either im-

mense amounts of preprinted papers or using a lap-

top. However, the latter is a kind of barrier: while

adjusting numbers, the customer only sees the back

of it. Moreover, it will be perceived as the sales per-

son’s laptop and most likely not used without reluc-

tance. In contrast, papers can be handed over and

written onto. They do not allow for ad-hoc adjust-

ments, though. Tablets provide the ease-of-use and

low barrier of paper while enabling individual adjust-

ments and recalculations. They are easy to use and

even accepted by people with low technical-afﬁnity

(Majchrzak et al., 2011). To keep calculated data, an

additional app can be offered to customers that will

synchronize with what has been worked on with the

sales person.

Data entry has similar characteristics: paper is it-

eractive and personal but forms usually have to be

corrected once returned to the company; laptops are

comfortable and powerful, and enable checking data

in real-time. Again, using tablet computers can be

a convenient solution. However, in this case more

sophistication is required than for mere visualization

since data entry by touchscreens usually is inferior to

using keyboards – at least, if much text has to be en-

tered.

Linking apps to a backend not only provides real-

time veriﬁcation but also allows most activities to be

(pre-)computed on servers. This simpliﬁes app im-

plementation but again security concerns have to be

taken into account. Moreover, apps needs to be de-

signed to provide some kind of “user mode”. The

sales person might want to access data from all his

customers using the app. However, when handing the

tablet to a customer to show him some data, it should

not be possible to easily browse to the ﬁle of another

customer.

Despite all praises, investing into mobile technol-

ogy for sales staff should be done carefully. A lap-

top computer provides a large set of possibilities and

probably even terminal-server access to most of the

company’s resources. A tablet in contrast is bound to

the functionality realized in an app. Therefore, sales

processes have to be tailored to allow seamless work.

However, this can be used for optimizations at the

same time. It is advisable to keep laptops for a while

after introducing tablets.

5 DISCUSSION

Our ﬁndings regarding status quo and best practices

are useful in several areas. Having knowledge of the

current state of mobile development in enterprises is

important for research on new technologies. The de-

sign of mobile enterprise frameworks has to follow

the needs of businesses. It also has to be based on

the current situation typically found in software de-

velopment departments to be capable of being inte-

grated into their environment. Designing a product

for mobile development without regard for the needs

and capabilities of businesses will often prove unsuc-

cessful. The following subsection highlight some of

the needs most often mentioned during the interviews.

They are the basis for the open research questions that

we identify in the second subsection. The best prac-

tices that we compiled might serve as recommenda-

tions for companies with similar problems. They can

also inform further research in related areas, because

they highlight what has been successful for solving

particular problems and what might be transferable to

other areas.

5.1 Topics of Particular Interest

We explicitly asked our interview partners for topics

of particular concern. When analyzing the transcripts,

we additionally looked for problems that were consid-

ered not successfully solved up to now. As a result,

we compiled the most often found topics of particu-

lar interest for which so far no universal solution ex-

ists, at least for small- or medium-sized software de-

partments: security on mobile devices, mobile device

management (MDM) in general, cross-platform app

development, and testing mobile applications. They

are discussed in the following.

Mobile security is a highly relevant topic. It sub-

sumes the security of data and applications on mo-

bile devices used in an enterprise context and is hence

of utmost importance due to the critical information

present on devices. Security has to be considered

both in the administration of employees’ devices and

when developing apps for internal or external use. On

the one hand, standard security considerations also

known from PCs or laptops, for example regarding

wireless communication and application permissions,

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

342

are more prevalent on mobile devices. On the other

hand, they require particular security measures due to

their mobility, e.g., data protection in case of theft

or loss. This unique combination of security risks

along with a reduced awareness of users due to the

playful nature of mobile devices poses severe chal-

lenges. Furthermore, users often blend private and

business use to the point of using their private de-

vices for work (BYOD). First solutions to some of

the problems are available as part of MDM (see be-

low). MDM solutions often allow to specify secu-

rity policies and provide means to react to device loss.

Platform providers such as Google and Apple prepare

guidelines for developing secure apps (And, 2012;

Apple Inc., 2012). Nevertheless, a holistic security

approach still requires considerable effort and knowl-

edge.

Commensurate to the scope and versatility of mo-

bile devices, mobile device management increases in

importance. Due the proliferation of apps, smart-

phones and tablets need to be administered similar

to desktop PCs and laptops. This includes the con-

ﬁguration of (new) devices, installation of apps and

updates, distribution of relevant enterprise data, and

maintenance. Additionally, data should be synchro-

nized with other devices and data sources. Most func-

tions should be provided over-the-air, i.e., remotely

without the need to hand in the device to administra-

tion. The heterogeneity of the mobile device market

further complicates matters and necessitates a cross-

platform MDM, which is hindered by the closed na-

ture of mobile platforms with respect to administra-

tive functionality. The MDM market changes rapidly,

which makes orientation especially for smaller com-

panies difﬁcult. Abstract, strategic overviews of the

market like (Redman et al., 2012) do not offer enough

insight for deciding on a MDM solution. In gen-

eral, one can distinguish between on-premise and

cloud-based MDM. Especially for smaller compa-

nies, cloud-based solutions might be viable, because

they do not need to be installed and maintained by the

company itself.

The mobile market is fragmented into largely in-

compatible mobile platforms, most importantly iOS,

Android, Blackberry, and Windows Phone. In an en-

terprise context, at least the ﬁrst two, but often more,

need to be considered when developing apps. Imple-

menting an app separately for each platform as a na-

tive app requires a lot of resources. Cross-platform

approaches to app development promise to serve sev-

eral platforms from a single code base. Several cate-

gories can be distinguished (Heitk¨otter et al., 2012),

but all of them have some limitations. Depending on

the particular app, a mobile Web app – essentially a

Web site optimized for mobile use – might be suf-

ﬁcient, or a so-called hybrid app that has access to

device-speciﬁc features. However, these Web-based

approaches do not produce truly native apps with a

native look & feel. No mature cross-platform solution

with a native look & feel exists so far, although ﬁrst

steps in this direction emerge such as Titanium Ap-

pcelerator (Appcelerator, 2012). A novel approach is

to use model-driven software development (MDSD)

to build apps. MD

for example can be used to de-

scribe apps as a model using a domain-speciﬁc lan-

guage and to automatically generate native code from

this model (Heitk¨otter et al., 2013a; Heitk¨otter et al.,

2013b). Similar to the MDM market, cross-platform

approaches are an ongoing topic. Smaller develop-

ment companies need help navigating the confusing

market to pick a suitable approach.

During app development, testing is a particular

concern to ensure a defect free and smooth user expe-

rience on all supported devices. Again, heterogene-

ity causes particular problems. Devices, even with

the same mobile operating system, differ signiﬁcantly

with respect to screen sizes, input methods, and other

device functionality. These features have a direct im-

pact on the functionality and user experience of apps.

Hence, testing an app only on a single device type

will not be sufﬁcient. User interface tests, often man-

ually executed, become more important compared to

traditional applications. Due to the inherent mobility,

apps have to be tested with respect to their reaction to

context changes (Schulte and Majchrzak, 2012), e.g.

regarding device orientation, a loss of network con-

nection, or relocation. The emulators available for

most mobile operating systems are not sufﬁcient for

thorough testing. Testers need access to several phys-

ical devices with different speciﬁcations. Provision-

ing such a set of current devices is not feasible for

smaller app development teams. However, there are

some cloud-based solutions that offer manual or au-

tomated remote control of mobile devices, e.g. (De-

viceAnywhere, 2012). Up to now, companies are on

their own when developing a testing strategy that con-

siders the particularities outlined above.

Topics not discussed due to space restrictions

are mobile requirements engineering, motivating and

training developers, energy efﬁciency, and coping

with ofﬂine situations.

5.2 Open Research Questions

While our project has led to insights regarding the sta-

tus quo of using applications for mobile devices, it

also has shown that there is a large number of open

questions. This is a limitation of our work: we have

DevelopmentofMobileApplicationsinRegionalCompanies-StatusQuoandBestPractices

343

worked qualitatively and with a small sample; ﬁnd-

ings cannot be statistically signiﬁcant or may not nec-

essarily be true on a global scale. Therefore, open

questions can be derived but answers need to be dis-

covered in future research.

Some of the open questions have a practical nature

and stem directly from the ﬁndings and special topics

discussed above. It is beyond the scope of this paper

to provide solutions to the questions that we can rise.

In fact, there is much work to be done in a variety of

directions and with a number of disciplines to con-

tribute. Therefore, our approach is to rise questions

and – if applicable – to give ﬁrst ideas for paths to

solutions.

Firstly, practical problems have to be solved to

support companies. Several topics for research can

directly be taken from the status quo drawn in Sec-

tion 3:

• How can companies be supported in deciding

whether app development should be pursued by

them? How can the business value of using apps

be determined?

• For which areas does app development apply?

What are particular requirements that apply to

apps, and how can they be engineered?

• How should decision processes be adapted to al-

low more efﬁcient development?

• Which ways of distribution are reasonable? How

can companies safely use app stores?

• What are the challenges of app development and

what novel techniques might improve develop-

ment processes?

• Which strategical underpinning might app devel-

opment have for companies?

For many of the above questions, solution

sketches already have been presented. It is our be-

lief that there is no purely scientiﬁc answer to most of

these questions. In fact, we deem a close observation

of corporate practices along with scientiﬁc research to

be the most adequate path to feasible solutions. This

includes refraining from a hyped thinking about apps

and seeing them as one instrument to support internal

processes and customer-related activities.

Secondly, theory-driven work is required. This

particularly applies to the purely economical and the

purely technical topics. Regarding economical topics,

the value-creation by apps has to be scrutinized. It is

easy to estimate development effort and relate it to

sales ﬁgures if apps are offered for a premium. Mea-

suring the effect of process improvements by app us-

age or even of increased customer support is close to

impossible. Therefore, ways have to be found to sup-

port the processes that lead to investment decisions.

We consider this to be a theoretic question at ﬁrst:

explanatory models for the value of apps in different

situations and for varying scenarios have to be found

in a ﬁrst step. The second step is then to evaluatethem

qualitatively and eventually quantitatively in cooper-

ation with enterprises.

Regarding technology, there are a number of ques-

tions that require profound theoretical work before as-

sessing their application to corporate problems. There

are four particular areas that we deem to be especially

important:

Cross-platform development is supported by var-

ious approaches ranging from using Web apps over

Web technology-based solutions to sophisticated

frameworks based on cross-compiling or model-

driven software development technology. Which

framework to use in what situation is target of on-

going research (Heitk¨otter et al., 2012). The same

applies to the development of improved frameworks

with a focus on business problems.

There is no sound background for app develop-

ment. Companies require guidelines, best practices,

and a knowledge base similar to what they can draw

from for classical software engineering.

Projects such as (Zibula and Majchrzak, 2012)

have started with scenario-based evaluation of tech-

nologies applied to app development. Such work has

to be extended, put into a greater structure, and even-

tually uniﬁed.

There is no theory of app testing. At the same

time, testing apps is greatly different to testing of

desktop and server applications. Of course, many

techniques can be transferred and there is no need to

come up with completely new theories. After all, apps

are computer programs and underlie the same ramiﬁ-

cations as any other program. However, the context

they run in and the changes in user interaction pat-

ters and runtime model ask for amendments to exist-

ing theories. Based on this, tools and techniques need

to be developed and eventually evaluated on practical

examples.

Thirdly, a theoretical base for app development

has to be worked on. This is the most open challenge,

yet the hardest to work on. While no strong differ-

ences to classical applications development could be

observed, some inherent particularities became obvi-

ous. The need to deal with context changes falls into

this category. Moreover, the way that mobile technol-

ogy is used poses some profound differences in terms

of value to businesses and perception by humans.

This even related to the ongoing discussion of ubiq-

uitous computing (cf. e.g. (Bell and Dourish, 2007)).

Finding suitable “small packets” for research and pur-

suing theoretization in an interdisciplinary way will

be a challenge for the upcoming years.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

344

6 RELATED WORK

Due to the nature of our paper and the novelty of

the topic, relating to other work is no straightforward

task. In a narrow sense, no directly related work that

explores mobile strategies from a business point of

view and surveys the status quo exists. In a wide

sense, almost all papers considering app development

are related due to their involvement in the early ad-

vances in this area. Work that related a bit more

closely to particular aspects of our paper has been

cited at the appropriate locations. Therefore, we will

only highlight a few approaches that relate in a closer

sense.

WASSERMAN (Wasserman, 2010) gives an

overview of software engineering issues prevalent

when developing mobile applications. He draws on a

survey among mobile developers and highlights what

makes mobile development different. The main part

consists of a research agenda for software engineer-

ing, not a description of current practices, and hence

is a worthwhile addition to our work. In contrast

to our work, he focuses on the immediate environ-

ment of the developer himself, but not on the point of

view of businesses that decide on mobile strategies.

The work of DEHLINGER and DIXON (Dehlinger and

Dixon, 2011) takes a similar direction. HOLZER and

ONDRUS (Holzer and Ondrus, 2009) study the mo-

bile market from a developer’s perspective as well.

They intend to give advise to developers on howto en-

gage in mobile app development. Similar to (Wasser-

man, 2010), their work has a narrower scope than our

project, but provides additional insight.

TARNACHA and MAITLAND (Tarnacha and Mait-

land, 2006) take an entrepreneurial perspective on the

opportunities of mobile commerce and analyze the

dependencies between technology and business strat-

egy. Hence, they focus on businesses for which mo-

bility is a key factor, as their products entirely depend

on it. Our work, instead, looks at enterprises with a

modest relationship to software that want to expand

towards mobile applications supporting their regular

business. Published in 2006, the statements of (Tar-

nacha and Maitland, 2006) mostly apply to the pre-

smartphone area and are in detail not applicable to

today’s situation.

7 CONCLUSIONS

We presented work on app development by enter-

prises. Our paper summarized the status quo and best

practices learned from regional companies before dis-

cussing the ﬁndings and formulating various topics

for ongoing research.

Besides providing some insights, we hope to stim-

ulate research with our work. Research has to keep

pace with the extremely high speed the market for

mobile apps evolves with. Moreover, there are many

unsolved challenges for which solutions need to be

provided.

Our own work is not ﬁnished. We are currently

working on a project for cross-platform app develop-

ment, one of the challenges presented earlier. Our

idea is to provide a technically sound solution that

still keeps a domain-speciﬁc focus (on business apps)

in mind. Moreover, we keep contact to some of the

enterprises we worked with. Thereby, we will tackle

on some of the questions raised in this paper.

ACKNOWLEDGEMENTS

We would like to thank the companies that ﬁlled

out the questionnaire and particularly those that were

available for interviews. Their participation made the

underlying project of this paper possible.

REFERENCES

(2012). Android developers. designing for security.

ApacheCordova (2012). Apache Cordova.

Appcelerator (2012). Appcelerator.

Apple Inc. (2012). iOS Security. http://images.apple.com/

ipad/business/docs/iOS Security May12.pdf.

Bell, G. and Dourish, P. (2007). Yesterday’s tomorrows:

notes on ubiquitous computing’s dominant vision.

Personal Ubiquitous Comput., 11(2):133–143.

Dehlinger, J. and Dixon, J. (2011). Mobile application soft-

ware engineering: Challenges and research directions.

In Workshop on Mobile Software Engineering.

DeviceAnywhere (2012). Deviceanywhere.

Heitk¨otter, H., Hanschke, S., and Majchrzak, T. A. (2012).

Comparing cross-platform development approaches

for mobile applications. In Proc. 8th Int. Conf. on Web

Information Systems and Technologies (WEBIST).

Heitk¨otter, H., Majchrzak, T. A., and Kuchen, H. (2013a).

Cross-platform model-driven development of mobile

applications with MD2. In Proc. of the 2013 ACM

Symp. on Applied Computing (SAC). ACM.

Heitk¨otter, H., Majchrzak, T. A., and Kuchen, H. (2013b).

MD2-DSL – eine dom¨anenspeziﬁsche sprache zur

beschreibung und generierung mobiler anwendungen.

In Proc. der 6. Arbeitstagung Programmiersprachen

(ATPS 2013), number 215 in LNI. GI.

Holzer, A. and Ondrus, J. (2009). Trends in mo-

bile application development. In Mobile Wireless

Middleware, Operating Systems, and Applications-

Workshops, pages 55–64. Springer.

DevelopmentofMobileApplicationsinRegionalCompanies-StatusQuoandBestPractices

345

HTML5 (2012). HTML5.

Hull, E., Jackson, K., and Dick, J. (2010). Requirements

Engineering. Springer, 3rd edition.

jQuery mobile (2012). jquery mobile.

Majchrzak, T. A. (2010a). Best Practices for the Organiza-

tional Implementation of Software Testing. In Proc.

of the 43th Annual HICSS. IEEE CS.

Majchrzak, T. A. (2010b). Status Quo of Software Testing

– Regional Findings and Global Inductions. Journal

of Information Science and Technology (JIST), 7(2).

Majchrzak, T. A., Jakubiec, A., Lablans, M., and

Uckert,

F. (2011). Towards better social integration through

mobile web 2.0 ambient assisted living devices. In

Proc. 2011 ACM Symposium on Applied Computing,

pages 821–822, New York, NY, USA. ACM.

PhoneGap (2012). Phonegap.

Redman, P., Girard, J., and Basso, M. (2012). Magic quad-

rant for mobile device management software. Techni-

cal report, Gartner.

Schulte, M. and Majchrzak, T. A. (2012). Context-

dependent testing of apps. Testing Experience, (19).

Sybase Unwired Platform (2012). Sybase unwired plat-

form.

Tarnacha, A. and Maitland, C. (2006). Entrepreneurship

in mobile application development. In Proc. 8th int.

conf. on Electronic commerce, pages 589–593. ACM.

Wasserman, T. (2010). Software engineering issues for mo-

bile application development. FoSER 2010.

Zibula, A. and Majchrzak, T. A. (2012). Developing a

cross-platform mobile smart meter application using

HTML5, jQuery Mobile and PhoneGap. In Proc. 8th

Int. Conf. on Web Information Systems and Technolo-

gies (WEBIST).

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

346