Working with Enterprise ALM: Mobile, cloud and more
A comprehensive collection of articles, videos and more, hand-picked by our editors
When it comes to cloud ALM projects, most companies aren't starting from scratch. Nearly all of them have some application lifecycle management practices in place. This is a good thing, because migrating to the cloud and adopting new ALM tools at the same time is difficult. If you are going switch ALM tools, it's best to do so before moving the application to the cloud. That helps ensure that the tools and ALM practices work properly...
with internal IT practices.
In this tip, I outline what's involved in moving ALM to the cloud, identifying pitfalls to look out for along the way.
Make sure your chosen cloud platform is compatible with your ALM tools
The first step in planning an ALM cloud strategy is to identify the tools currently used to manage applications, and then establish their capabilities to manage the candidate cloud platforms. It's important to know whether your current ALM tools support each cloud platform under consideration; if they don't, you will need to customize the management interfaces or select new tools. Keep in mind, also, that ALM is likely to need both orchestration/provisioning tools and application integration tools, and both must be verified for suitability with candidate cloud platforms.
Tenants or separate apps?
There's also a risk that the test sandbox could leak customer or other private data.
Once you resolve the question of platform and tool compatibility, the second step in your cloud ALM strategy is to determine whether the cloud platform supports independent sandboxes as either "tenants" or separate applications. Each version of an application is considered a different user/application, and has its own sandbox. The pitfalls that come up in your cloud ALM project will likely be related to database and workflow integration issues. You have to make sure that test sandboxes don't access production databases and workflows. This is true for on-premises ALM tools, as well as those based in the cloud. But allowing access in the cloud presents additional concerns, because the test sandboxes might be exploited as a path to attack a production system. There's also a risk that the test sandbox could leak customer or other private data. If these leaks occur, the culprit is likely to be an application integration issue, where a production database or an application programming interface (API) was listed as a resource to a test sandbox. In many cases, this is the result of a scripting or integration tool parameter error, and so the testing of these tools is critical. Most users report the best results when they start with a sandbox that represents one of the early ALM phases (development, or changes to unit testing, for example). They move to later sandboxes only when the earlier ones have been fully certified. Be aware that cloud application instances may be addressed differently than in-house resources would be, and make sure these differences are reflected in the integration tools.
The other major area to consider in cloud ALM planning is the testing of the cloud-related processes themselves. Cloud management interfaces clearly have to be tested as a part of ALM. The testing may be as simple as verifying that the ALM tools operate properly through the management APIs. And don't forget to test special features like "rolling instances," where the cloud application accommodates multiple geographies as time zones change.
To the cloud and back again?
While most cloud applications reside in the cloud permanently, some companies want to switch back and forth between the cloud and internal IT resources. In some cases, the goal is to devise and test an orderly process so that the company can retreat from the cloud in the event of a failure or a change in business conditions. Others want to use the cloud as a backup or overflow resource for internal IT.
Using the cloud as a backup or overflow resource creates the greatest ALM cloud planning concern. The problem is that both the internal application and the cloud versions will require "pairs" of sandboxes, one pair for each phase of the ALM cycle. The failover or workload sharing processes of the application will have to be tested within each sandbox pair, with special care must be taken not to accidentally cross a pair boundary accidentally. Often failover and workload sharing is based on a front-end switch the user provides, and these systems will have to employ some form of synchronization between the database and transactions to keep both cloud and internal resources up to date. These processes will all have to be integrated within the sandbox pairs to assure ALM integrity.
The final issue is the significance of the cloud's "as a service" model in ALM. With infrastructure as a service (IaaS) the platforms on which applications are based are not standardized, and as a result the processes of management and integration are not standardized, either. This means that considerably more work will be required to integrate ALM tools and processes across IaaS than with PaaS or SaaS. It's also more difficult to manage application integration, a key requirement for cloud computing, when every application could use a different means of locating resources and components. With PaaS, the orchestration and integration processes tend to be standardized across the platform. With SaaS, only high-level integration is needed. Keep these points in mind when considering a cloud platform. Also bear in mind that most enterprises believe that in the long term their commitment will be to PaaS and SaaS. Starting there could save a lot of effort and make your ALM plans and your cloud plans more durable.