Three things development leaders should focus on in 2013

Mobile was a top priority for companies in the last year, and for good reason. Mobile devices, including tablets, are becoming more popular than desktops for online access.

As a result, mobile projects are slated to outnumber PC development projects by 4:1 in the next three years. The number of mobile devices on the planet will outnumber people by 2016.

The challenge for development teams is how to adopt a mobile-first mindset. This approach requires you to put user experience at the center, offering a strong contextual and personalized experience. It also means offering that experience across multiple platforms and devices, introducing complexity and the need for specialized skills into the development process.

Plus, it requires expertise in how to build the right back-end infrastructure to support composite applications. today’s apps combine the context of an individual (using a mobile device) with a plethora of other information from multiple corporate back-end systems.

When you add to this the imperative of managing iterative app development across multiple client OS platforms, managing the development cycle has become ever more challenging. Companies are pressuring development leaders to rethink their mobile approach. In the coming year, it will become more important than ever to gear your development and operations teams towards mobile first. Here are the three pressing things to consider for 2013:

Bring mobile into your core dev team

With the range of skills required to support multiple mobile platforms, it is rapidly became common to outsource mobile development to companies with workers who have those specialized capabilities. However, the increasing prevalence of open web standards such as JavaScript and HTML5 linked to native mobile capabilities will make it easier to pull mobile development skills back in-house.

That is fortunate, because the development teams of the future will have to do short, ongoing iterations on mobile apps. Not having the right workers in-house complicates the development process and requires a sophisticated level of coordination and integration of external resource into your core development processes and tools.

It’s also important to think about whom you have to educate in order to execute a mobile-first development approach. Many web designers, for example, come from a desktop paradigm and may not have specialized in mobile user design. The changes in form factor, touch and contextual interaction do require a different interaction and design experience and therefore an evolution in designer skill set.

Tweak server architecture for mobile & web

Today’s composite apps have bigger implications for the back-end infrastructure that supports your apps. Most apps will depend on a range of back-end API services that enable interaction between the user interface on the mobile device and a back end that runs the business logic of the app, pulling information from multiple corporate systems.

This best lends itself to an API-centric cloud-service architecture, where your new back-end exposes APIs to the front end. This gives access to the information needed, and the mobile client has all of the user interface logic.

You gain the best of both worlds: A native experience on the mobile device, connected to a back end server that spits out JSON (JavaScript) data via REST-based services, as opposed to dealing with the presentation layer of the application.

It is important to note that these back-end apps are new apps (a.k.a. composite apps) and not just exposing existing back-end systems as is. These apps need to deliver new APIs that can support the personalized, contextual experience of mobile. Therefore, sheer pass-through technologies that do not aggregate and transform existing systems with business logic are not sufficient for true mobile-first development.

Increasingly, we see companies choosing a cloud-based infrastructure to run these back-end services. It is important to consider what your platform requirements for this infrastructure will be in 2013.

For example, how will you meet the fluctuating demand caused by volume of mobile devices accessing your app? This will require a new level of elasticity compared to previous back-end infrastructures. In addition, how will you support an agile development cycle that requires frequent app changes both to client-side (mobile user interface) and server-side logic? And how will you ensure the fault tolerance and redundancy of the back-end services infrastructure?

The key is to ensure that you have chosen an elastic, fault-tolerant cloud application platform that supports these new requirements created by your mobile and web apps.

Unify development & operations

Mobile-first strategies place new demands on collaboration and handoffs between development and operations teams. Although it emerged as a buzzword several years ago, “devops,” or the idea of improved collaboration between dev and ops teams, is no longer an optional area of focus. In fact, operations-related failures are among the most important points of application failure for mobile and web applications.

Research from Carnegie Mellon University has shown the leading causes of application failure today include failed software upgrades, inability to scale to meet unforeseen demand, resource exhaustion, and configuration errors. This means operational questions of how an application will perform once in production are just as important considerations as debugging an application’s core code before release.

For example, in an iterative development cycle, with frequent client- and server-side application updates, how do you ensure there are no configuration errors when an application is passed from development to production? Historically, this process involved a developer writing detailed guidelines for their operations team that outlined the exact process, including versions and libraries to install, and in which order.

However, the key to taking the error out of dev-to-ops handoffs is to automate this process. A developer should be able to hand the operations team an executable package that has been tested to automatically perform the steps required.

When it comes to failures due to application updates, how do you deal with the possibility that a new application version introduces unforeseen errors into an application already in production? This requires better real-time troubleshooting tools for applications in production — as compared to the traditional approach of a development team trying to reproduce production errors.

It is also a good idea in an iterative world to invest in “insurance,” the ability to easily roll back to previous application versions when required. At a high level, the application deployment process must be both highly productive (supporting frequent iterative updates) and churn out quality results.

Making mobile-first work

Although approaching a mobile-first environment can appear intimidating, if you re-think your team at the same time that you re-think the way you develop, deploy and manage apps, the process will become easier. The skills and tools required of development and operations teams in a mobile-first world are different, whether it be a focus on mobile user interface design, the skills to implement an API-centric cloud service architecture, to build an elastic backend infrastructure, or to address the question of avoiding application failures caused by the difficulty of devops collaboration. Addressing each of these requires not only investing in improved processes and increased automation but good old-fashioned teamwork.

Andi Gutmans is CEO and co-founder of Zend Technologies. Founded in 1999, Zend was instrumental in establishing PHP. Today, Zend helps others create and implement back-end infrastructure for web and mobile applications. Zend Server and Zend Studio are deployed at more than 40,000 companies worldwide.

Image credit: Shutterstock/leedsn

Original article published on VentureBeat 

  • Mike Willbanks

    Mobile First works but only in select circumstances and not all circumstances. The largest thing to know about as you pursue a mobile first mindset is the items that you are giving up. How do you handle it?

    From the front-end? From the back-end? A hybrid? How do you mix in applications? How do notifications trigger between the application and how do they differ between an app? How do you send out email communications where the layout is a hybrid layout but if clicking a link and you have an app it launches the app and provides the content?

    There are always a ton of mobile type questions and the answers can always be different. If you talk to a UX expert they will tell you that all content should be mobilized and accessible (this is true is most circumstances) but can also be a pain in the neck.

    I’ve come to the conclusion that while you may not always want all of the same content; you still need to provide a form of access to all content. Meaning that accessibility is there for both a mobile form app or non-app and that you never force a user out of an experience where distinct content may be.

  • spabby

    I’m a firm believer in “API first”, and this comes from the CTO of a mobile web focused company.

    We’ve actively decided to have both a mobile and desktop version of our sites simply because the user experience for each context is so different. Our focus on mobile is to provide a lightweight, snappy site that provides the minimal information for a user to get a task completed as quickly as possible. On the desktop we’ve gone for a more “bells and whistles” approach, adding extra features and accepting that someone sitting at their computer with a cup of tea is more likely to wait for a page to load than someone sitting on the bus.

    The fact that both these websites (plus our Android, iOS and Nokia apps) share a central API is what allows us to be so flexible with the clients we produce.

    Because a huge percentage of our users are in emerging markets, and we actively want to work on any mobile device that can access the internet and handle streaming video, we decided to completely eliminate things like Javascript on our mobile web app. This isn’t for everyone and presents it’s own challenges, but the fact is, it works, we get users using devices most people wouldn’t event realise are still used in the world.

    There’s a lot of buzz around single responsive sites at the moment, and in my opinion, while a one-site-fits-all approach could work for you, you should ask yourself the question:

    “Is this the *best* we can do?”

  • Stefan Koopmanschap

    I believe we should not focus on mobile development. I dislike the whole focus on mobile. Mobile is just one of many applications that may consume the data you have. Instead, focus on building a strong API. The API will serve as a provider of data and functionality for mobile apps, but also for your website, and even integration with third-party websites and API’s.

    This approach does open up a whole world of possible abuse that should be considered before blindly opening up the API. But there are many ways of preventing that, many best practices already in place that can easily be used.

  • Aaron Saray

    I think a lot of this depends on what your actual usage scenarios are too. There are going to be some apps where the current iteration is just never going to be accessed via a mobile device. So, forcing a mobile development path into that project is just going to waste time, money and energy.

    However, not being a negative-nancy the entire time, I do like the idea of encouraging programmers to focus on mobile first. I would agree with most other commenters, though, and suggest API First as an alternative. I think of the business application as an API that exposes certain pathways of information. We shouldn’t be spending time forcing business process to conform to user interface and usability choices (that’s how some of our businesses get into trouble – we can’t update the IT, so let’s change the business… that’s always bad). Instead, business processes should be simplified and only one set of APIs, ever, should be created. Then mobile app, website, or API access is another layer. Those might have their own use-cases, and that application level is responsible for gathering together the data in a way that is usable. Some would argue that this may take longer or require more processing, but that’s fine. We have a near infinite amount of power available these days… the business core is the most important thing to keep pristine and precise. Let’s not forget that our applications support business, not the other way around.

    Good article, keep up the good work of evangelizing “the right way” of doing things.

  • Michelangelo van Dam

    Yes, nowadays we get more traffic on mobile devices than on regular computers so mobile is important. But behind each mobile interface there’s a full API and service layer serving the information consumed. To build such an architecture, you still need to rely on some of the basic understanding of how applications are being build for the web. Separation of responsibilities is still key here and building applications in general requires today’s developer not to just implement a project but to decide where responsibilities are being put.

    We have made dozens of internal applications mobile by just building an app using same end-points we use for our web based interfaces.

    As said, a good application requires a good architecture to serve multiple consumers.

  • Faraz Ahmed

    “As a result, mobile projects are slated to outnumber PC development projects by 4:1 in the next three years. The number of mobile devices on the planet will outnumber people by 2016.”

    Wow! These are eye-staggering stats. I will make sure to tell my colleagues about it.

    As long as elastic, fault-tolerant cloud application platform is concerned, do you think Amazon EC2 will do the job?

  • Asgrim

    To echo others that have commented, the difficult thing is not the front-end, but untangling legacy systems to introduce stable back-end APIs that will allow things like native applications and HTML5/JS powered web applications to actually work effectively. Let the front end teams concentrate on the mobile web apps, and mobile developers concentrate on making native apps, but most importantly ensure your back end team are making functionality available through well documented and stable APIs.

    Well documented!! I can’t stress that part enough. It’s no good writing a great API if it doesn’t come with good, well defined documentation to help developers consume it. It doesn’t really matter whether it’s REST, XML-RPC, HTTP POST requests, or even dreaded SOAP (*shudder*), as long as it’s well documented, preferably with code examples depending on how close you work with the consumers of the API, and you are able to support the API for as long as required.

  • jcarouth

    I can only echo what other people have already said. Mobile first as an idea is great when you’re talking only about font end stuff, but API first is where all the power is. Great mobile sites and applications are about data not design. I’m glad the article touches on this topic.

  • Sharon Levy

    Thought provoking article. Enjoyed it all except for the “spit” metaphor. Whatever happened to vocabulary like “output” or is that term too old-fashioned in a mobile world?

  • mikestowe

    100% Agree with Mike Willbanks on this one… rather than going with a strict mobile-first strategy, I am a fan of API first, allowing you to meet the needs of desktop applications, desktop web, mobile web, mobile applications, and other devices (tvs, gaming devices, etc) that will eventually become more and more popular as technology progresses. Sticking to a mobile-first concept presents in many ways the same issues of a desktop-first concept, in that we are focused primarily and initially on one platform and not necessarily creating the best experience for our users, or providing ourselves with the flexibility needed to expand our application’s platform over time.

  • Christian Wenz

    I agree with moving to a SOA and “API first” to facilitate different form factors and clients. However mobile first is not always the best solution. For some applications, only a certain form factor might be used. For others, different form factors require entirely different approaches and technologies. A service-oriented architecture helps here, but the one-solution-fits-all dream is, often, just a dream.