Visitor Monitoring Mobile App Lifecycle: Managing the App Development Cycle | Keynote
Article

The New Challenges of Managing the Mobile App Lifecycle

A conversation with IBM's Leigh Williamson about mobile application management.

Any enterprise that depends on the Web typically has a working application lifecycle management (ALM) program in place. But when the enterprise turns its attention toward mobile development — as more and more are doing — not all of the Web best practices apply, and new mobile-specific ALM practices are required. Few people are so in the thick of mobile ALM as IBM’s Leigh Williamson, an IBM Distinguished Engineer whose primary focus today is mobile app development. Benchmark tracked Williamson down in China and talked with him by phone about the development challenges of mobile, how they’re being met, and what’s on the horizon.

Benchmark: What are the challenges that are keeping enterprises from devoting the resources needed to create a robust mobile presence for themselves?

Leigh Williamson: There are a lot of challenges to delivering mobile applications. The first thing the enterprise has to do is decide what of their services and data is really mobile-oriented, because not everything is appropriate to be delivered to a mobile device.

So deciding the mobile content is one of the first things, and then right after that, people have to decide on an implementation technology. People are still getting all tripped up over the debate about Web versus native versus hybrid, and the truth of the matter is that the right answer is different for every mobile app.

After they get past that challenge, the next thing they have to do is select some tools or maybe an application framework or platform and, of course, that decision is a bit dependent on the earlier decision about content and implementation technology. Then they probably have some existing IT services and data that they want to mold, to use as some of the content, and so they have to decide an approach to integrate or deliver those existing IT assets into the mobile channel. And that integration choice is another technology choice that's separate from implementation — maybe somewhat related, but separate.

And then of course, after they've figured all that out and they've got something running, they have to decide on a strategy for testing and quality assessment of the app, which has a whole dimension of challenges for mobile testing, including the notion of getting some feedback from the application even after it has been deployed into the field.

Then the final thing is that, besides all of those other challenges, they have to come up with a development strategy, or a life-cycle strategy, that allows their team to deliver all of that and the updates for the mobile app, much, much, faster than probably any other software that they've ever delivered previously. So there's a lot of challenges for these businesses.

Benchmark: How is the development and testing process fundamentally different between desktop, which we would assume we have pretty well down to a science by now, and mobile? What are the application lifecycle management practices that can extend from desktop to mobile? And which ones just don’t work?

Leigh Williamson: The interesting thing is that if you raise the level of observation high enough in an abstract sense, the development or testing is pretty similar for all kinds of software, even mainframe software. But once you start digging into the details of each of the activities in the lifecycle, that's where the differences are more obvious.

Mobile is more complicated than some of the previous forms of software because of the variety of device types that have to be supported. There's all these different mobile operating systems and more coming on onto the market even as we speak. So that's one dimension of fragmentation to deal with.

And then the range of human interaction to provide input for mobile applications is a whole lot wider than for desktop-type applications, where really all you have there is a keyboard and a mouse. But with a mobile device, you've got human gesture input, you get input from voice, you get input from services like GPS and a camera, and other forms of input if you're scanning barcodes or something like that.

The breadth of functional capabilities that you have to test and also support in the code for a mobile application is, I would say, at least one or maybe even two dimensional order of magnitudes greater than for most typical desktop applications.

Another thing that I think is worth mentioning — for desktop software, agile development practices are pretty well-recognized as good practices, but you can get away with not being strictly agile or maybe not agile at all. But to succeed with delivering a mobile app, agile development practices are pretty much mandatory in order to keep up the pace there. The other thing that comes into the picture as an important practice is what we call DevOps, or essentially automating the development process to the greatest degree possible. Those are some things that are not irrelevant to desktop, but are much more significant to mobile development.

Benchmark: Are there any examples you can describe of how some of your clients are successfully leveraging what they know and do on desktop into the mobile sphere? How are they extending that and adapting it?

Leigh Williamson: The answer to whether an organization can leverage their desktop or Web application investment and skills and tools for mobile depends a little bit on the organization that's involved and also on the application that's involved. We have clients that completely outsource their mobile development and testing, but we also have clients that do all of their mobile work in-house.

We've seen a number of financial institutions and other kinds of companies that have been able to leverage their existing in-house development resources and shift them to delivering mobile apps. We also have seen customers who've done this by creating a separate side team to focus on mobile and be shielded from the rest of the developmental organization. That's a technique that can be successful in the short run, but longer-term that disconnection can start to be a problem.

We've definitely seen other larger enterprises where they're pretty insistent on incorporating the mobile developers right into the main IT application development organization.

No one answer seems to work for all organizations. It's probably not as much a technical consideration but more of a cultural one. But I do have to say one thing that, even if the implementation technology lends itself to reuse of Web development skills, there are still some mobile-specific skills that have to be understood and put into practice. A good Web application isn't always a good mobile app.

I've seen not-very-desirable results in several cases, with clients that began by having the expectation of taking an existing Web application and just turning it into a mobile app without any serious design reconsideration, and that does not work very well. You have to go back and look at the design of what you're trying to produce on the mobile device, because a lot of Web applications are implemented in a way that doesn't work that well on mobile.

Benchmark: IBM is using the “mobile first” phrase very prominently. What does that idea mean as IBM uses it?

Leigh Williamson: Actually, for IBM, MobileFirst is the name of an identifiable brand that we've defined within IBM. We rolled this out at Mobile World Congress earlier this year, and the idea encompasses all of the assets of IBM that are related to mobile computing. We have assets such as software, like our mobile application platform and mobile management solutions, mobile security, analytics, mobile development tools, and so forth.

Our MobileFirst portfolio also includes a wide array of consulting services — everything from assisting our clients in formulating their enterprise mobility strategy to consulting services for outsourcing application development testing, and even network and application management services once the application is ready to be put into production.

The third part of MobileFirst is our partnerships. We have strong partnerships all over the globe with large and small business, such as AT&T, Apple, Duestche Telecom, Ford — and Keynote, with DeviceAnywhere, is another one of those important partners.

So for IBM, MobileFirst really represents what we believe to be the broadest and most comprehensive portfolio of mobile solutions and services that are out in the industry today.

Benchmark: From a bigger philosophical perspective, obviously a lot of your clients have legacy systems in place, so MobileFirst is a moot point. But for developing new systems, new operations, is it your philosophy to say, ‘we’ve got to look at mobile from the get go’?

Leigh Williamson: Yes. But for modern applications — I refer to them as systems of interaction — we have an application architecture in mind that includes those existing investments in systems of record, those transactional systems, the databases, etc. But there's a whole other component now to modern applications, which is where the end user interacts with the application — whether it's on a mobile device or laptop or kiosk or some other smart 'Internet of things' enabled endpoint device.

Mobile is a good rallying point, and it's sufficiently different than PCs to force developers to design the application with an omni-channel focus. It can't be just a simple PC form factor anymore. You really have to consider an application architecture and an application design that, if it will work for mobile, then you can ensure that it'll work for the traditional PC, and it's likely to work for these other kinds of enabled smart endpoints that are increasingly going to be part of the picture.

Benchmark: What are some of the unique challenges that you see in quality-testing mobile apps, getting them to market, making sure that they’re going to perform out in the field?  And could you also comment on emulated versus real device testing?

Leigh Williamson: I think we can address the emulator versus real device testing right upfront. We view emulators as reasonable facsimiles of what an end user might experience, but I don't know of any customer that would ever release a mobile application only having tested on emulators. They have their place in the testing taxonomy — for instance, they can be useful in the creation and authoring of automated test scripts, because there you're just trying to get the automation created. But then you would want to replay those scripts against real devices so that you can get the real behavior of the application as an end user is going to be more likely to experience it.

In terms of the challenges overall for quality-testing mobile apps, there are things that are unique to mobile — for instance, the need for an organized and methodical way to access this wide range of devices that your mobile application is required to support. You want to test your app on all these different kinds of devices.

It is an unrecognized cost and complexity to manage all of those devices for the purposes of testing and to ensure that you get maximum utilization of those test devices across everybody who's going to need to perform testing. Solutions like DeviceAnywhere, that provide that organized remote access on multiple different devices, are the way to address that challenge.

Another unique mobile testing challenge is just the functional test automation of the mobile apps themselves. Since they are implemented differently, with different languages than Web applications, you can't really reuse the same functional test automation that we've worked out for Web applications. Some of the techniques are the same, but the implementation has to be specific for the mobile operating system and the application structure that mobile apps are written to.

So IBM has a technology for functional test automation that we ship in our Test Workbench as well as the IBM Worklight development environment because we recognize that, in mobile, a lot of times the developers are the ones that are creating the test cases.

Performance testing for mobile is pretty interesting. It's kind of a two-directional question. There is the traditional load and stress testing, just like for Web applications — the only difference there for mobile is to make sure to get the load characteristics to reflect what a mobile app would deliver for a payload as opposed to a Web browser.

But looking in the other direction, there's a whole range of performance testing necessary for the app on the device itself, where you're trying to understand how well or not well the mobile application is using the resources of the mobile device.

There is a bunch of stuff that you can do badly. The application may be functionally perfectly fine, but it's keeping the connection to the network open too long, it can drain the battery down because the radio chip is running too much…or if your application is not set up with a really long time-to-live for the cache, you're going to be reloading the same data more and more frequently and that's going to suck up the user's cellular data plan and they're not going to be happy about that. So there's all of those performance aspects of the app on the device itself that are important aspects that are unique to mobile.

One last thing that's an important and unique aspect for mobile is that all of these mobile apps are essentially front ends to some enterprise services that are sitting back in the data center and that you've integrated or connected with your mobile application. When you are testing out the mobile app itself on the phone, it can be really costly and complex to keep a full production system behind that mobile application.

So there is this technique that we call service virtualization that allows your test organization to simulate all of the back end services that the mobile app interacts with, so you don't have to have those systems actually there running and getting usage charges or charge-backs or just administrative overhead.

The other thing is that you can inject corner cases responding back from the back end systems that would be difficult to produce in a real system. So, service virtualization is another important element there.

Benchmark: You have written in the past in favor of doing hybrid apps, in HTML5 or Javascript, for example, wrapped inside a native package. Do you still advocate that approach?

Leigh Williamson: The implementation choice for any mobile application really should be based on unique requirements of that app and what it is expected to do. There is no one answer that's going to work for all cases. There are a number of apps out there that are just serving up a bunch of content over the Web, and a mobile Web implementation is probably ideal for that kind of app.

If you look at things like games, where there is a lot of responsiveness you need, and performance and efficiency — a native implementation is just undeniably the right choice for that kind of app.

But the thing is, there's this huge middle ground of business applications that don't need that level of performance that a game would need, and also they're expected to support multiple mobile operating system environments for the same application. If you look at that particular group of applications, the economics of the development costs really are a significant factor why businesses are finding that the hybrid approach is a good one. I absolutely advocate that approach and there's a lot of those applications out there. But it's not the only answer, and certainly not the right answer for every mobile app.

Benchmark: Knowing that going forward, we're all going to have to be mobile-focused, what do you see as the ideal clean scenario in terms of applications life cycle flow?

Leigh Williamson: Making any kind of software reminds me of the old saying about politics being compared to sausage making — you don't really want to look too closely inside the factory because there might be some things that you probably don't want to see. There's always some kind of not-ideal aspects in software development but we still manage to make it work.

But we do have an idealized view of the mobile application development life cycle and this would be a process that's highly automated. We think more and more you're going to see these DevOps capabilities being brought to bear. Developers will still be producing the creative innovations just like they do today, but the activities that come after they produce the code — the activities that process that code like build it, test it, scan it, deploy it and so forth, will be all highly efficient compared to how things are done today. You can really see this trend accelerating all around, not just in mobile, but mobile will really get it because of the time to market expectations placed on mobile apps.

I really think that mobile is pretty quickly just going to be one channel of delivery for content and services. Already we are seeing a lot of interest in wearables, and some of the implementations related to those actually leverage the power of a mobile device. Mobile devices are getting more and more powerful with every release. They're almost being used now as an intermediate computing platform that bridges between some cloud-based backend services and a smaller wearable device like a wristwatch or an eyeglass device. The mobile phone or tablet becomes a powerful middle tier, with the ultimate endpoint being even more interesting and different than what we see today.

The other thing that's going to be a big factor in the lifecycle for mobile applications is mobile backend-as-a-service, where things like push notification or couponing services are actually cloud-based services that the application developer just subscribes to and links into their app. You see that a lot.

Ultimately we're going to see a complete cloud-based development solution for mobile applications, where the tools and the components and everything are actually available in the cloud, and the developer doesn't have to install anything on their local workstation, but instead just uses a regular Web browser to access all these software-as-a-service offerings and use a variety of them together to create the application totally in the cloud and deploy it from there also.

Benchmark: Is that the kind of solution IBM is working on?

Leigh Williamson: It is indeed. We are, working towards that, and we’re not alone by any means in the industry.

Benchmark: Very good. We will certainly be keeping our eye on that as you develop it. Thank you for your time.

About Leigh Williamson

Leigh Williamson is an IBM Distinguished Engineer who has been working in the Austin, Texas lab since 1988, contributing to IBM’s major software projects including DB2, AIX, Java, WebSphere Application Server, and the IBM Rational portfolio of solutions. His current role is as a member of the Chief Technology Officer team, influencing the strategic direction for products addressing the needs of software development teams. Leigh’s primary focus is on tools and best practices for mobile application development. His blog on mobile development topics is http://bit.ly/ibmmobile-frontier-blog. You can follow him on twitter @leighawilli. Leigh holds a BS degree in Computer Science from Nova University and a Masters degree in Computer Engineering from University of Texas at Austin.

Back to Top