Taming the Wild West of MobilitySo you're part of a successful IT Department that has mature infrastructure, a high performance website and integrated back end systems. Then your CIO asks you to look at the company's mobile offerings and the team that develops them. It seems a lot complaints have come in from the App store and the CIO wants to know what the problems are and how to fix them.

This is where we start.

Living on the frontier of the enterprise, mobility in many companies has taken on a decidedly anarchic flavor, existing outside the norms of software development. This article discusses how to bring these initiatives into alignment with best practices and proven processes while retaining their vitality.

The Big Picture

Mobile projects developed their unique characteristics due to the perception that they are a different technology requiring unique approaches and controls. Coupled with the rapid growth of mobile platforms, this resulted in companies organically growing their mobile environment driven by circumstances rather than planning. I'd argue that despite the newness of this paradigm, it shares many characteristics of previous technologies and its newness springs partly from the unfamiliarity of those versed in web based development with these earlier models.

Let's begin with some common traits that all software projects share. They must:

  • Reflect the goals of the business
  • Deliver value for the investment provided
  • Leverage the enterprise architecture of the organization
  • Provide transparency and accountability

How do we accomplish this? Through the application of what I consider central components of an enterprise architecture -- Standards, Processes and Values.

Let's define each of these terms before we use them:

  • Values reflect the institutional beliefs of the company and drive all activities.
  • Standards are the compilation of experience in specific areas and guide the choices made in these areas. 
  • Processes help guide execution through proven approaches and defined outcomes.

Defining the Approach

We'll begin with an example and follow it through to its conclusion. Let's work with privacy -- something that many companies claim as one of their core values. Protecting the confidential information of customers is not only a business necessity but a legal requirement. For example, California's Privacy on the Go initiative defines a variety of items as Personally Identifiable Information (PII) including a user's geolocation.

Protecting this information involves guarding both contextual items we retrieve from the mobile device and data about this user stored in the enterprise that we combine to provide functionality. Securing data in motion and data in rest involves a variety of design decisions:

  • How much data can be stored on the device and how much kept on our servers?
  • What communications protocols do we use and how can we encrypt the information that is stored locally?
  • How can we protect our code against known vulnerabilities that compromise user data?
  • How do third party libraries used in our development measure up to our expectations ?

These types of questions allow us to not only identify the tools we need but also to tailor our processes to meet the required standards and achieve our values.

Each time we go through this exercise we should use our experience to populate a database consisting of tools, processes, design decisions and lessons learned. This will become our reference architecture, one of perhaps several that address how we build a mobile product that meets our values.

Once we've gone through this exercise and achieved success it's time to look at how we can share our experiences to other members of our mobile community.

Socializing the Results

Assuming that we've gotten this far the next question is: How do we diffuse this knowledge to the mobile teams and show the value that can be achieved from our approach?

We're bringing order to a chaotic environment -- the situation is similar to the strategy that military theorists have developed for counterinsurgency. Develop fully functioning successful islands of stability and offer surrounding communities a chance to join. The keys to this approach are the ability to show reproducible results and clear steps to achieving the same thing with other groups.

In software this means achieving speed through reusability of patterns, tools and processes. In mobile, where form factors and platforms are evolving constantly, this creates a paradox. To address these ever changing targets, development efforts are increasingly driven by functional requirements that seek to reflect the target environment as it exists, despite their transience. The resulting solutions are very brittle and difficult to replicate as we move to the next project and its dramatically differing circumstances.

A better approach balances functional requirements with non-functional ones such as security, reliability, maintainability, upgradeability, etc. These attributes can be rationalized in each project and together provide continuity across development efforts -- whether Mobile or not -- regardless of the technology. To accomplish this, the architect must work with business stakeholders to help shape both development approaches and product characteristics consistent with the goals of the enterprise.

The resulting improvements in project velocity and technical sustainability will allow mobile projects to reproduce the successful features of the enterprise's software environment while meeting the challenges of an ever changing technical landscape.

Title image by Misty Adams (Shutterstock)