Top 5 pitfalls to avoid deploying Enterprise Mobility Solutions - Episode 5

Release Management, it will make or break your global mobility solution

Mobile solutions are expected today to come with frequent updates, solution improvements and requested functionality. Especially if your particular solution is being built along an agile development methodology, clearly advocated in my previous article, don't assume your business know what they need in this brave new world - this is an interactive requirements cycle. This setup drives the needs for an accompanying Release Management (RM) methodology which allows for these frequent updates to take place. The topic I’m about to cover is really aimed at enterprise mobility solutions which are integrated with at least one back-end platform.

For all of you who have spent years on other enterprise platforms such as SAP, oracle, etc. you know by now how important a flexible release strategy is to support and help advance a growing and ever-changing business. In the world of mobility such RM strategies are not necessarily built into the product from the get-go as it typically only becomes relevant once the solution reaches multinational or global scale.

Another key topics also bound into the same discussion is the governance and management of a common template for these mobility solutions so that you’re platform does not start forking into multiple different ones each requiring its own specific support setup and hence driving Total Cost of Ownership (TCO) through the roof.

In my experience the tendency is that at design time of the release management methodology especially at large corporations with a global template in mind, too much weight is given to global governance and template standardization – this is my personal opinion and I’d be glad to hear your view! These are all good objectives to have in mind and should be defended. But there is a balance to strike here in terms of the supportability, speed and flexibility the solution provides to the real user community in the field.

At best the solution from the start has been technically structured very flexibly where sub-components can be independently updated and deployed. For those who speak SAPanese this is achieved very efficiently in SAP netweaver’s transport technology. Even though it’s ancient, it’s amongst the best on the market in terms of providing release flexibility for globally templetized solutions. – Hint to SAP: why don’t you include the mobility layer as part of a robust release methodology?

Here we are talking about mobile solutions which may not contain the same robust flexibility and are typically much less mature. In this case when the global release management methodology is set for your organization a detailed study of the solution at hand needs to take place analyzing:

Modular packages for independent deployment

• How granular will the solution at hand deploy sub-components of the total system? How are the dependencies between these modules handled? Is versioning of the individual sub-components supported? Can dependent sub-components be packaged together for joint deployment? Is the mobility layer included in the release strategy managing also the deployment to the mobile devices?

Solution core components vs market modification

• How is the internal architecture of the solution setup to support core templetized functionalitiy and local modifications under a logical structure? Are all elements of the solution under the same or at least some form of release structure? Can data elements be used to satisfy local needs rather than code changes?

Release Management best practices.

• Does the vendor have a set of best practice procedures to manage release on the solution at hand based on experience from other large deployments on the same technology? Will you need to develop these from scratch and hence learn about the child diseases in the RM solution during deployment.

Find a ground where the expected template and its core components can be maintained and governed into process standardization but where detailed updates can be done flexibly by each local market needing support. A key factor to enable such operation is to allow for markets to work and move ahead under compliance rather than controls based governance – There is a vital difference here:

• Compliance based governance allows a local team to make change to the solution at hand under certain guidelines, rules or possibly a certification you run. The local support team is empowered to take the required decisions to support and enhance its local market. Such a setup can be linked back to concepts resembling Speed of Trust.
• Controls based governance typically makes each proposed change pass through a control often centrally held and checked hence slowing down the overall speed and flexibility of the support and enhancement process.

This will allow markets to flexibly resolve critical incidents and deploy compliant additions to the core product in a speedy way, whilst this is still structurally fed back to the main solution or kept as a local add-on, however not necessarily with a preemptive “approved” stamp prior to deployment.

This finalizes the series of Top 5 pitfalls to avoid deploying Enterprise Mobility Solutions. However there are still plenty of goodies coming up. Stay tuned...