Tag Archives: Apps

Enterprise Mobility is No Game

EA games (Electronic Arts, Inc.) recently released Plants vs. Zombies 2. Plants vs. Zombies has to be one of my favorite games to play on my mobile device. For those of you that don’t know, Plants vs Zombies is what’s known as a tower defense game. The object is to eliminate enemies as they attempt to cross a map. This is done by strategically placing artillery, mines, walls, etc. in the path of the approaching enemy. In the case of Plants vs. Zombies, instead of artillery, players place objects like pea-shooting plants to defeat zombies as they try to reach your house and eat your brains.

This follow-up to the extremely popular first version achieved over 16 million downloads in less than a week. However, there is one catch—it’s only available on iOS. For those of us on the Android platform, which by the way has almost 80% of the global mobile market share, we are out of luck. And with no Android release date in sight, non-iOS users are left in the lurch (bad zombie pun intended).

There are definitely financial reasons for this approach with consumer apps. For example, iOS users spend more money on apps and in-app purchases. Also, many organizations are allowing consumerization practices to influence business methodology and decision making. However, this single OS approach to app development should, categorically, not be followed by the enterprise.

Enterprise app development must take a very broad device approach. In the world of Bring Your Own Device (BYOD) there is no guarantee what devices employees will show up to work with. In order to achieve the most return on your mobile investment you should aim to support the most number of users. The allure of the simplicity and controlled nature of devices’ homogeneity is a limited strategic approach. The popular device of today will be replaced by the next cool device of tomorrow. This will lead to a never-ending cycle of playing catch-up that will be cost prohibitive.

Enterprises need to anticipate supporting the vast array of ever-changing devices on the market. Combine BYOD with the notion of the Internet of Things, and enterprises have even stronger justification for a diverse mobile approach. Anything short of a heterogeneous approach to mobile devices, apps, data, and management will paint your mobile strategy into a digital corner where you will be stuck waiting for the paint to dry.

When it comes to mobile app development, how can businesses overcome and address an ever-expanding ecosystem of device proliferation? There are platforms available for developers that do a decent job of bridging the gap between the different mobile operating systems. Platforms such as PhoneGap, Appcelerator, and Sencha allow developers to write the application in a single language that then compiles to a native app. There are some drawbacks to this approach. As much as we love the development process to be write once, use many times, cross-platform development tools still require some tweaking per OS. However, these platforms will get you 95% of the way there.

Your device management strategy needs to be heterogeneous as well. While Samsung and the upcoming iOS 7 release will offer device management and enterprise services, a single platform approach to managing devices is a step in the wrong direction. This convenience of built-in services that are vendor-based is greatly outweighed by the need to have an enterprise mobility management strategy that is flexible for the future. Organizations would be better served to explore one of the many mobile management solutions available to support a wide variety of devices, have app management, and ultimately provide information management.

As hardware diversity increases, organizations need to not only display data on various devices, but also collect data from an ever-increasing range of devices. This could include IT infrastructure, manufacturing equipment, and even display cases. The cost of embedding Internet connectivity is approaching negligible. With this hurdle removed, the matrix of connected devices in an organization is only going to grow. Is your organization prepared for this sort of dynamic addition of mobility? Are you thinking A to Z or just Apple and Android?

The consumerization of IT does not have to mean that the enterprise takes every aspect of the consumer approach and translates it directly into a business strategy. Enterprises that approach BYOD as BY-iOS-D will find they have a left-out and frustrated user base alongside an inferior position for the future. Like tower defense games such as Plants vs. Zombies, organizations need a broad heterogeneous strategy to anticipate and manage the onslaught of mobility. The inability to predict new devices and methods of connectivity necessitates this approach. There is and will be no single dominant mobile end point. Why play like there is?

Benjamin Robbins is a co-founder at Palador, a mobile consultancy located in Seattle, WA. He can be followed on Twitter @PaladorBenjamin.


Leave a comment

Filed under Apps, Future, Mobile, Strategy

Mobile Apps and Analytics – The Devil’s in the Data

I have been involved in many discussions lately about enabling employees/end-users with data. The thought is if we can get the right data in the right hands of the right people at the right time, then we’ll see interactions, efficiencies, and opportunities like we never have before. Mobile devices are going to buoy this experience as they represent an always accessible data delivery mechanism. I couldn’t agree more!  There is, however, one small catch. Much of the data that business want to use/share is not stored in the same way that data needs to be consumed.

While there are tools and platforms, such as Hadoop, that work well with unstructured data, many of the data stores that exist today store data in a relational way. For those of you who are not Database Administrators, here’s a simple example of what that means. Let’s take a customer. For any given business, the idea of a customer is someone who has bought a product from the company. If the employee needed to gather information about a customer he or she would probably want information such as number of customers per products. However, in the database there is likely no such thing as a customer. Customer is a concept that could be represented in the data by the following tables:

  • Person
  • Address
  • Order
  • Product

Each table has its associative fields such as name, date, etc that would be tied to other tables by an ID (which is usually not readable just by looking at IDs). If the employee was given access to the raw data it wouldn’t make much sense to them.  A customer is a business concept, not a way of storing data. Much of the data that exists today is stored in this format. If an employee wants to look up all the customers who ordered product X in the last 90 days, there is work that needs to be done to prep the data in a business consumable fashion.

This problem is multiplied when a business desires to tie together multiple systems and their associative data. The way a customer is stored in one system is probably not how it is stored in another. Each application has slight differences and has slightly different data fields. If you need to merge the data sets together from various applications it will take some tweaking on the data side.

This isn’t by any means a deal breaker, but organizations need to begin to include the effort required in conversations, planning, implementation, and support. The problem isn’t that data can’t be tied back to business concepts in a consumable state, but that data transformation is time-consuming and expensive. It takes not only application knowledge, but business knowledge with the ability to merge the two (not the natural modis operandi of Application and Database Developers). This is also an on-going process that needs to be updated with each change to the database schema.

The way that data is stored in an application is why the notion of an “information Worker’ that Microsoft touted for years never panned out. Microsoft advocated the use of many of their data consuming products by this ‘information worker’ – a quasi-technical individual capable of mining and manipulating data on their own. The trouble is, even if you have a great tool, like Microsoft’s Report Builder, which allows you to drag and drop data sets into a WYSIWYG editor, you still need data in a ready-to-use business state.

What does this mean for mobile? Many of the advantages that we were going to see with the “information work” are now being used as reasoned advantages for consuming data on the phone. For example, users will be able to perform their own analytics or users will be able to build their own apps. I’m not saying this isn’t possible, just that we need to make sure we include in our dialog the amount of effort that will be required to prep the data so that is it readily consumable by an average user.  Our discussion around builing a meaningful mobile ecosystem can’t just be to say create we need to create an API and all will be copasetic. Yes, API’s will create the gateway to the data, but the data needs to be transformed into a business consumable state. Delivering a meaningful experience to the end-user will take bridging the gap between the business and structure of the data.

Benjamin Robbins is a Principal at Palador, a consulting firm that focuses on providing strategic guidance to enterprises in the areas of mobile strategy, policy, apps, and data. You can follow him on Twitter or connect on LinkedIn.

1 Comment

Filed under Ecosystem, Mobile, Strategy