Enterprise Data Mobilization, Part 1
By Armeen Mazda, CEO, Appeon
times have you needed access to your organization's line-of-business (LoB)
applications to carry out a key task, such as checking the availability of a
product before accepting an order or following up on an outstanding support
ticket for an important client, etc., but you find yourself away from a desk or
your laptop is without an Internet connection? What are you to do?
Tell the customer: "Sorry, I am on the road
right now so I'll get back to you tomorrow." Such a response may have been
acceptable in the past but is increasingly less so in today's "unwired" world. With
recent advances in mobile devices, application development, and networks, chances
are your competitors are preparing to or have already mobilized their enterprise
What is Enterprise
Enterprise data mobilization is much more than just emailing
from a wireless handheld device. In
order to truly mobilize an enterprise and reap the benefits, mission-critical
business processes and data need to literally be in the hands of key
constituents at all times in all locations.
Business processes are captured and automated in LoB applications.
Data is stored in the enterprise database or
data warehouse. Once key LoB application
functionality and data is brought down to the wireless handheld device, the
enterprise has effectively "unwired" itself.
For example, employees can carry out business in places and at times
traditionally not feasible. But true
mobilization takes it one step further: it ensures that wireless handheld
devices offer access to enterprise data even when offline (i.e. when a network
connection is unavailable). Such a degree
of mobilization enables the enterprise to be truly without boundaries.
An enterprise without
boundaries is revolutionary and enables new business opportunities. Of course enterprise data mobilization will
increase employee productivity, enable higher level of customer service, and so
on, but this is just evolutionary or incremental improvement. The truly radical change is that it empowers
enterprises to reshape the way they do business. In much the same way that mobile technology
has had a profound impact on people's everyday lives, this technology and trend
is poised to have an equally (if not more) profound impact on businesses.
How to Mobilize Enterprise
Mobilizing enterprise data,
at a high-level, is not much different from developing PC-based or Web
Decide what to
Deploy to users
But as the cliche goes, the
devil is in the details. We will use a
real-life example in the hospitality industry to walk you through each of these
5 major steps above in reasonable level of detail and provide useful
suggestions along the way. We hope this
will help you get started with your enterprise data mobilization project.
1. Decide What to Build
Our consulting company
(Appeon Corporation) was approached by a leading Hotel Management software
vendor in the USA
looking to "mobilize" key application functionality of their flagship
product. Their flagship product is already
available as Client/Server, Web, and SaaS deployment options.
However, hotel management and maintenance
staff are generally on foot for large portions of the day. Although Web-based and SaaS options are a
huge leap forward for hotel management software, enabling key hotel staff to
carry out their job anywhere on the hotel property was the real ticket. Specifically, the aim of the mobile
application was to ensure that maintenance staff know exactly what to do and for
management to know when it is done, all in real-time without being bound to a
desk or laptop.
2. Select Appropriate Technology
Now if you start to consider mobilizing
your line-of-business application and data, you will need to determine what
platform and technology you will use. There are different mobile devices
available in the marketplace utilizing different (usually proprietary)
operating systems with varying hardware and functionality.
A short list of some well-known mobile
platforms includes RIM BlackBerry, Apple iPhone, Windows Mobile, Google
Android, Symbian OS, Palm webOS, but the list goes on. Generally speaking, the operating system you
choose will dictate the programming language you will use and the devices that
you can choose from.
For the corporate user
segment, with over 21 million users, RIM BlackBerry is one of the leaders. As our client is a software vendor, the
mobile application needed to consider market demand.
Moreover, RIM BlackBerry has relatively
strong penetration in the hospitality industry, at least among management
staff. So in our case, the decision was
already made for us. All we had to focus
our energy on was selecting the appropriate technology for RIM BlackBerry to implement
The RIM BlackBerry is based
on Sun's Java ME (micro edition) platform with WML browser and HTML browser (on
newer models). In simple terms, this
means you will be developing applications following one of these three "modes":
developing Web-based applications that render HTML or WML (if you want to be
backwards compatible with older devices).
developing Forms-based Web service applications.
developing native Java applications with full access to BlackBerry's Java APIs.
applications are generally the easiest to develop and deploy. It doesn't require a steep learning curve,
specific RIM BlackBerry knowledge, and for the most part such applications are
cross-platform (i.e. can be run on any compatible browser regardless of mobile
operating system used). But browser apps
do have tradeoffs compared to BlackBerry JDE.
BlackBerry JDE applications offer the ability to fully exploit
BlackBerry's APIs, develop a rich user interface, deliver fast performance for highly-transactional
applications, and be run offline as well as online. In our case, we recommended BlackBerry JDE to
our client for these reasons.
3. Architect the System: Data Storage Architecture
Now that we've chosen the
technology, we need to decide how to architect the system. The BlackBerry JDE "mode" we have chosen
dictates certain things about the architecture.
The key question to answer is how will we manage the data? Generally speaking, the mobile application
data can be managed one of three ways:
only storing data
on a remote server, e.g. a news aggregator Website;
only storing data
on the mobile device, e.g. a text editor;
storing data on
both the mobile device and the server, e.g. a sales order management
application which synchronizes with the enterprise database.
Applications requiring the
ability to work offline and have consistent access to the enterprise data will
adopt the third model, storing the data on both the mobile device and the
central database server. So in our case
we went with this option.
The data can be stored in any
number of formats at the mobile side, for example, in a text file, in a lightweight
database, or even in memory (if permanent storage is not required). But the most flexible and easy-to-manage way
is to store it in a lightweight database. Utilizing a database is very intuitive for
enterprise application developers and most important it reduces the workload by
shielding the complexity and programming related to managing the data storage
There are many mobile
databases on the market to choose from, such as SQLite, Sybase UltraLiteJ, etc.
For us the decision was quite simple. We wanted to choose a mobile database that
was very lightweight, supported synchronization with our client's enterprise
database, and had the support of a large commercial vendor. The solution that caught our attention was
UltraLiteJ is a light-weight
database designed for the JME platform and supports the BlackBerry. It provides
a lot of intuitive SQL APIs to call. As
a mobile application developer, you can bring transactions, primary and foreign
keys, indexes, and other features of relational databases to the BlackBerry. But the key value of UltraLiteJ is in its
data synchronization capabilities.
UltraLiteJ, part of the
Sybase SQL Anywhere suite, includes a server-side data synchronization
mechanism called MobiLink, which works in tandem with UltraLiteJ to synchronize
data (bi-directional) with the enterprise.
This synchronization includes change tracking (e.g. if you delete a row,
you need to send that delete to the server, so you have to keep track of that)
and state tracking (e.g. when you send the delete to the server you need to
know if it got there, and if not, send again).
MobiLink synchronizes UltraLiteJ with all leading relational databases,
such as Oracle, Microsoft, IBM, MySQL, and of course Sybase. MobiLink together with UltraLiteJ provides an
easy, reliable, out-of-the-box data synchronization solution for the BlackBerry. This way, we can focus on the BlackBerry
application development and not get bogged down with all these nuts and bolts
or introduce additional risk into the project.
So what will the system
architecture look like with BlackBerry JDE "mode", both client and server data
storage, and the Sybase SQL Anywhere suite?
UltraLiteJ will reside at
each BlackBerry device, acting as the lightweight embedded database. The BlackBerry device will connect to the BES
(BlackBerry Enterprise Server) via a cellular service provider or WiFi (on
newer models). With the MDS (Mobile Data
Services) installed to BES, UltraLiteJ has HTTP connectivity to the MobiLink server,
which could be installed to the database server or separated out on its own
physical server. MobiLink will then
interface with the enterprise database via ODBC.
In Part Two we'll explore application design considerations as you architect your system.
Armeen Mazda is CEO of consulting firm Appeon.