Consumerization of IT as it Relates to Developers

In my book, C# Design and Development, I discuss the need to consider the application environment in a number of places. For example, on page 106 you’ll find a discussion of the corporate environment on the requirements for application speed. A discussion on page 431 describes the need to achieve application goals while treading softly on the user’s environmental settings. Application environment can include a lot of different considerations. That’s the reason the ComputerWorld article entitled, “‘Consumerization of IT’ taking its toll on IT managers” struck a cord with me today. IT is now faced with a situation where users rely on personal devices more often than corporate-supplied devices, which is wreaking havoc in many ways.

The article will enlighten you about the woes that IT faces. What the article doesn’t describe are the woes that the developer faces. When an application developer creates a new application for the corporate environment or provides changes to an existing application, the testing process must consider the devices that the application will run on. When the developer works with a known set of corporate-supplied devices, the testing process is predictable. However, when the developer must also consider personal devices, the testing process is more like the environment for shrink-wrapped software, which means that the developer must now consider an open environment in which the user could rely on any device. In fact, developers must consider the following application design, development, and testing issues as a minimum due to consumerization.

  • Security: Early corporate applications didn’t come with much security at all. As government regulations, data breaches, and other issues have come to light, developers have added security to application, but not at the level of shrink-wrapped software and certainly not enough to ensure protection of corporate data.

  • Reliability: Every device that accesses an application has different characteristics. These characteristics determine how the device interacts with the application. Adding devices increases the number of potential interaction types and reduces overall application reliability due to issues with non-compliant devices. Obviously, testing can no longer have even a hope of finding every application interaction issue, so developer will need to create a robust application error handling mechanism with the organization.

  • Presentation: As device types increase, so do the presentation environments that the application must service. It isn’t just the fact that these devices will have different sized screens, but also the need to address audio and input characteristics of a wide range of devices. A developer must now consider how best to define an application interface so it works with the broadest range of devices possible.

  • Multiplatform Considerations: A development staff may begin designing an application to work on a particular platform, such as Windows, only to find that users also want the application to work on Android or the iOS. Even when the user sticks with desktop or tablet devices, the application may need to support Linux or OS X. In short, the development staff needs to consider multiple platforms when creating an application today. Unfortunately, Web-based applications aren’t always the best choice—leaving the development staff with some tough decisions to make.

There are other considerations to make, but you get the idea. Today’s development environment has become extremely complex due to consumerization. Unless your organization has firm policies about personal device usage in place and actually acts on those policies, you need to consider the idea that the user could access your application using just about any device on the market today. You have a number of ways to deal with this situation, including the following suggestions:

  • Create a list of tested configurations so that users know which devices are most likely to work with the application.
  • Make users part of the initial design process so that you hear about needed device support as early as possible.
  • Track new device releases because many users will get the latest gadget and expect it to work with your application.
  • Define a specific procedure for adding new devices to the application support list so that you don’t have to deal with user requests in a confused manner.
  • Keep an open mind because users will work with personal devices whether you support them or not.

This whole issue of consumerization could easily consume a chapter or more in a book. What have your experiences been with consumerization? Is the new application development environment becoming impossible to manage? Let me know your thoughts at [email protected].