The way that large enterprises extend existing functionality into mobile apps must change the way they think about and manage the development process. Consider for a minute Yelp’s mobile app and the one your bank has offered you. On the surface, both apps seem to obsess over ease of use and having visually appealing interfaces. However, just beneath the epidermal UI they are fundamentally different animals.
Banking apps, as with the majority of enterprise mobile apps (expense filing, CRM, ERP or HR apps), navigate through a complex network of Web services and APIs in order to perform seemingly simple operations like displaying an image of your check. They must also deal with the constant threat of security breaches. I’m not saying that Yelp has it easy, but I doubt that Yelp is API’ing with a dozen COBOL programs written in the 1960s just so it can display the address of the closest sushi restaurant.
(Related: Five myths about automated UI testing)
The mindset that currently surrounds mobile application development focuses on speed, agility and a “get it out now” mentality. There may be challenges in a given version of an application, so the thinking goes, but they can be rapidly corrected in another revision of the app that’s issued tomorrow or next week. Add to that a laser focus on the customer experience: A recent article in Government Computer News said, “IT shops tend to focus on technical design aspects, but understanding user experience can ensure rapid user adoption.” True, but if the application doesn’t perform as promised, you can kiss “rapid user adoption” goodbye.
What’s missing from the popular rhetoric is an appreciation for the complexity behind the UI and how it affects the technical quality of the app. Is it robust? How do its interactions with internal enterprise Web services affect the stability of the existing enterprise infrastructure? Is it resistant to security breaches? These are questions that IT may be asking, but are too frequently overlooked by the business leaders at the other end of the continuum.
And, as a developer of mobile apps, you may well know the secret that too many others don’t: It’s far tougher than it looks. Forrester analyst Michael Facemire is quoted in CIO magazine as saying, “People that have done tons of software [work] say mobile is different… It’s more common to see folks that say they can do it, [but as the project goes on they realize] it’s not really working out.” In this environment, it’s easy to see how and why incompatibilities erupt. And it’s easy to see why trying to pin down the source of a glitch and fix it can be so frustrating.
What’s needed, in order to ensure that mobile applications are produced in a manner that helps ensure their success, is a renewed, fundamental focus on measurement and analysis of mobile applications and the infrastructure that supports them. Yes, I am talking about going back to the basics, but not at the expense of slowing down the pace of development.
The analyses of mobile applications, properly conducted, can examine the multiple layers of complexity presented by the different components. For instance, a new mobile application may be required to work seamlessly with legacy user interfaces, or existing middleware in the stack. Too often, different teams manage them… each of them, making their own silo work as well as it can. Injecting new elements, like mobile applications that access services from around the infrastructure, comes with risk to each component.
Even some of the most well-conceived and executed Web services cannot account for the non-functional defects that may be hiding in your legacy infrastructure. At best, the new element may not perform as advertised or desired. At worst, it can create chaos and fleeing users. Neither alternative is desirable.
Again, I’m not saying that the entire development process needs to grind to a virtual halt while each application is laboriously (and manually) examined. That’s not feasible in today’s business environment. The automated analysis of code, however, can rapidly identify potential challenges and vulnerabilities, enabling developers and IT staff to solve them and head off problems before they erupt into full-scale snafus. Visibility across different departments in the IT organization will naturally facilitate collaborative solutions, creating significantly more value in each iteration of the app.
This makes sense from the IT side of the coin, and from the business perspective as well. The cost of application downtime can easily run into the millions of dollars in lost sales at bigger firms; add to that the loss of reputation among customers, who increasingly have their choice of any number of services in any given area. CIO magazine quotes another analyst who says that a badly produced mobile application “ticks off customers. Once they try it and they don’t like it, the chance of them coming back is not real high.”
