Every time a new platform comes along it seems we forget everything we know about the software lifecycle. Each new environment we encounter is always easier to use, faster to deploy or requires less support, and there is the rub. In our enthusiasm to embrace the latest technology, we stop applying the basic disciplines we've come to hold dear. And these are invariably how we manage the development artifacts for this new wonder and how...
we make new versions available to the end users: with our twin disciplines of change and configuration management.
The latest craze of bring your own device (BYOD) has innumerable advantages for the corporation, for sure: no capital costs, no ongoing hardware maintenance costs, no complaints about inadequate computer capabilities -- the list is impressive. But when it comes to delivering enterprise mobile apps to these devices, the costs are frightening and largely hidden.
When it comes to delivering enterprise mobile apps to devices, the costs are frightening and largely hidden.
Most corporations set a standard for platforms. This minimizes the testing needed and maximizes the chance of deployment success. With BYOD, the target platform has potentially thousands of variants. In this scenario the resolution of a report defect will become much more expensive as platform factors may be a contributor to the error. The good news is that mobile platform vendors, such as Apple and Google, are doing their best to minimize this risk. But the end users of these platforms are not always aware of what it means to stay current.
So what must we do to ensure that we have the right change and configuration management policies in place for this new platform paradigm? First of all, we need to take a leaf from the app vendors. We are all becoming accustomed to the fact that every time we open up our devices, we get a message (or a "bug") saying that a number of apps need updating. Often, we get several updates to the same app in the same week. What we are seeing is an important trend: a move to incremental change rather than less frequent, wholesale changes.
Small, incremental changes are much tighter in scope and therefore much easier to test. The odds of a serious error occurring, though not zero, are very low in indeed. If an error is detected, it is usually easy to repair, and quick, because the amount of change is low and those fixes can be deployed fast (hence multiple changes in a week). In order to execute the release management activities at this speed, we must have as much of the process automated as possible, including, critically, automated deployment to the app stores.
For enterprise mobile apps, release management has become the fulcrum that makes it possible for business to compete more effectively. In order to sustain a business lead in any market, the change process has to be nimble, but still diligent. And, the configuration management process has to be slick and nonbureaucratic. But ultimately it is the release management and automated deployment aspects of configuration management that are most critical.
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result.continue reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts.continue reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.