of today’s environments also plays a major role. The code is not the same software code we were developing 10 years ago. It’s not just C++. Now there’s Ruby on Rails, Java, PHP and so on relying on a lot of components that you need to have when building such systems, making for very complex software infrastructure. Typically the ALM process focuses on the software piece, while now dependency on the infrastructure is much higher. You depend on the database, depend on the operations system, depend on the messaging platform and so on. So without understanding all the components and embedding them into the build process, you can’t actually deliver a high quality environment.
Virtualization and cloud now impacts ALM as well. For example, you can leverage these technologies for your testing, like increasing the diversity and flexibility of your testing lab, while enhancing the independence of the developers so they can actually manage their own servers and not wait until a required server is provisioned. In terms of the way you package your deliverable, virtualization and cloud have a significant impact, as well as in terms of design and architecture of the applications.
At the same time virtualization and cloud introduce a number of challenges impacting effectiveness of ALM. Challenges to successfully managing the process in virtual servers come from limited visibility into virtual machine content, the dynamic resource allocation constantly changes physical topology, and the proliferation of virtual images and virtual machine sprawl.
On top of these virtualization issues, cloud adds a self-service automation layer. This layer exacerbates the management challenges because you need to address:
- how do you verify correctness of automatic activities?
- how do you get visibility into the result of automatic actions?
- how do you ensure that right actions are applied?
- how do you integrate automated and manual actions?
The introduction of the cloud will separate the development and operations teams even further. Self provisioning based on rollout of virtual images hides development activities from the Operations team because Operations provides just an infrastructure used then by the Development team, allowing them to set up application environments. While, the Development team has limited visibility into Operation’s services, which are provided as a catalog.
This adds another gap between the two sides, exacerbating the management challenges from not sharing a consistent view of the environment.
Transitioning through environments and managing environments is part of the ALM process, and is even more important when dealing with virtualization and cloud.
ALM Tools for Closing the Development/Operations Gap
Considering the trends happening and the gaps between development and operations, what can you expect from the ALM tools? First of all, we expect that the tools should close these gaps in the process. There are tools for requirement management, for project management, for development, for test management, software configuration management and so on, but you don’t have the tools that will ensure control of the change, analysis of the change, and validation of the change, through the entire path. Not only over the development process but also for what happens when the change is actually deployed. What happens to the changes that take place in production and operations, how do they get backreflected into the pre-production steps of the ALM process. That is a toolset that is definitely missing. The existing tools for ALM and also operations don’t provide integrated control of the change.
To reach this level of control of the change in this complex system consisting of heterogeneous and dynamic environments, there are certain requirements to expect from the tools. The requirements are for tools to