Thursday, March 1, 2012

6 Things to Avoid as you Build Out Your Company App Store

Sixteen apps and what do you get? Another day older and deeper in debt!

I pay programmers and they ask me for more, now I owe my soul to the company store!

I can almost hear CEOs singing this song. Lamenting the loss of profits as their IT departments driven by business unit demands struggle to build out the company portfolio of enterprise apps. It’s a daunting task. Mobile smartphone preferences change dramatically within just a few months. No one single mobile operating system controls the market. And the cry of business users for enterprise mobile apps on any device, anywhere at any time gets louder and louder and louder. 

Until now, CIOs simply staffed multiple teams of programmers or outsourced development to large overseas development shops in the hope of getting some sort of consistent and usable business solutions for their mobile apps.

To make matters worse, business users expect mobile apps to be fully synchronized with back end enterprise software systems. These systems typically took years to develop and implement and many are only getting integrated to one another now. So how does a CIO find a strategy that doesn’t either put her in the position of constantly saying no to business units or taking on massive risk of development failure by bringing on large parallel development teams to work out solutions for different platforms? The answer lies in a mobile enterprise application platform. Only when development teams are developing on a platform that allows them to write once and deploy anywhere will the risks be reduced and the costs brought under control.

Still there are many things that can go wrong when selecting a MEAP platform. These are some of the pitfalls to avoid:

  1. Avoid Code Generation Schemes. The idea behind a code generator is that you work for awhile in a higher level IDE and then press a button that generates a code file. That program code is then compiled or run by an interpreter so that you can test the results of the code generator to see how well your development team created the app. Since changes are usually needed, the solution is usually to tweak the code making changes to the generated file in a native programming language for the mobile device. The advantages of the higher level IDE dissipate once this tweaking begins and it is far from simple because the developer wasn’t involved in writing the original and very tedious line-by-line text file. Often code-generators do not allow “round-tripping” of code so changes accomplished by tweaking the native code also can’t be seen back in the high level IDE. All future modifications therefore must be modified in the line-by-line text editor instead. 
  2. Avoid Integration Component SDKs. A library of available integration components in an SDK seem like a reasonable solution for the problem of integrating to back-end systems. The problem is that an SDK is very appealing to the people intended to use it: programmers. It is not very appealing however to the development managers or senior IT managers and certainly can end up as the hidden source of delays in your projects ultimately frustrating the business users of your apps. Why? There is a vast difference between an integration SDK library and an integration platform. With a component library, you have bricks but you have no mortar and no architectural plans. You just have a pile of bricks and when you are finished building out an integration scheme you will more than likely end up with a poorly designed and executed integration architecture or you will bust the budget by double or triple what the programmers originally estimated. A better solution is an integration platform that has all the built in servers, communication brokering, service orientation, messaging, security, monitoring and so on needed for an elegant integration approach to be implemented quickly. Suddenly you have a plan and you have mortar and the building goes together quickly.
  3. Avoid unified look and feel approaches. This is an easy mistake to make. A vendor comes in and demonstrates how you can quickly deploy an application via the web or some native approach that looks exactly alike on BlackBerry, Android, Windows and iPhones. Hmmm… Wait a minute, what’s wrong with that? Plenty! Your users will revolt. BlackBerry users are comfortable with their keypads and trackballs. iPhone users are in a relationship with their touch screen interfaces. Android users bought a specific flavor of Android because of the promises made by their vendor for special capabilities and now you’ve just taken that away. Unified interfaces are poorly adopted even by enterprise users and your business apps will end up underutilized or simply abandoned.
  4. Avoid approaches that force you out of current legacy apps. Many vendors let out a cheer when  business users started demanding mobile apps because they saw it as a way to finally pry IT departments off of environments like the IBM i.  The problem with this rip and replace approach to IT modernization is that you sacrifice years of built-up value and proven environments for reliability and security. It is simply not true that IBM i, for example, is unsuitable as a server environment for mobile apps. 
  5. Avoid long distance outsourcing. I’ve yet to meet the overseas development outsourcer who wasn’t trying to keep their clients as dependent on them as possible for as long as possible. If you engage in outsourcing, you should insist on approaches that are collaborative where the vendor is willing to deploy your people on the project, mentor them and provide all the training and know-how they need to take over the management of the project as soon as possible.
  6. Avoid Delay. Your competition is moving and the market is constantly changing. While there are pitfalls to avoid, the biggest mistake is to delay getting started with a MEAP platform vendor at all. It is not necessary to spend millions on an enterprise mobility strategy. 
Choose a vendor with a strategic mindset, a collaborative way of working and a smarter approach to technology. Then get started.

Glenn Johnson is a Senior Vice President at Magic Software Enterprises, Inc. Active in the software industry since 1984, he frequently speaks at industry conferences and writes for numerous publications.