One size fits all ALM Tool Prevent Enterprise Automation

One size fits all ALM tool might not solve the problem

It may be time to retire the one size fits all ALM tool.  Many organisations have “corporate wide” tools intended for large groups of users, designed to standardize and centralize processes, management and enforcement. Software Configuration Management and Application Life Cycle Management (ALM) are just two disciplines where “one size fits all ALM” is commonplace.

While the concept of a corporate wide, one size fits all ALM tool is logical, it is impractical to assume that ‘one size’ can ‘fit all’. In fact, I can almost guarantee that whoever you are, you probably work for an organization that has implemented a “strategic tool” (or a “tool of choice”) that was intended to satisfy your organization’s business or operational requirements.

If we focus on the ALM tool, Software Configuration Management (SCM) and software engineering, then we could use IBM’s Rational products or CA Technologies’ Software Change Manager (Harvest) product as examples. These products are typically implemented with the view of enforcing and managing SCM-based processes (source code control, life cycle management, etc) across the IT organisation. Whilst these tools are more than capable of addressing SCM and ALM requirements, there are factors that alienate users, such as:

  • Product Administration; requesting product configuration changes takes time and delays users, such as:
    • User Administration
    • Project Configuration
    • Repository Configuration
    • Build Configuration
    • Administration & Housekeeping
    • Process Configuration
  • Process Automation; recognizing repetitive processes that can be automated.
  • Tool Integration; integrating the product with other enterprise systems (Change Management, Service Management, etc).
  • Product Education; understanding how to use the product and what the product is capable of.
  • Product Usability; do the end users actually feel comfortable using the product.
  • Product Familiarity; simply, end users prefer something that is familiar to them.

The above example illustrates Git as the ALM tool and how the output from Git – the source code – is propagated through the life cycle, to be deployed to the various QA and Production environments. The illustration also highlights the manual processes of an Environment Manager and Release Manager utilising Microsoft Excel to [manually] manage the application changes and deployments.
This example might be reasonably typical for smaller organisations, but what inevitably happens in larger companies is that additional tools are adopted over time. The following example illustrates how individual teams and projects might ‘break away’ from the “IT Standard” and adopt their own tooling, which finds a place within the organisation and contributes to the overall tooling complexity.
The number of tools expands and the role of Environment & Release Managers becomes even more complex as they attempt to co-ordinate change from numerous tools, locations and processes. This is where the majority of large organisations have difficulty in implementing automation – automation is achieved by assigning computational resource to undertake manual, repetitive tasks. If the processes are fluid, the tooling non-standard and the scale vast, then achieving full Release Automation is impossible.
To achieve full Release Automation in this scenario, one would have to have a solution that could dynamically link to all the various tools and their underlying repositories (where the system changes are made by the developers). What is also important to note is that any given Application is not simply a collection of compiled binaries; an Application consists of configuration settings (application and environment), technology frameworks, services, packaged solutions, etc.
Each one of these Components has to exist somewhere, whether the Release process is manual or automated. For Release Automation, however, the tool responsible for managing the end-to-end deployments has to be capable of dynamically linking to various distributed sources.
Essentially, by modelling the Application, its Components and the location [tool] of those Components, the ability to achieve full Release Automation is attainable.
The above example illustrates how the logical definition of Applications, Components and their sources enables large organisations to achieve Release Automation. Notice that a Component’s source could be a source code control tool, a file system location or a binary repository – it’s not uncommon to have elements of a Release that do not adhere to the “Strategic Tooling” initiative.
By implementing a tool – such as Release Engineer from OpenMake Software – it is possible to achieve full Release Automation with very little cultural impact, operational risk and without ripping out existing tools and processes.


Ms. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that were common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

0 thoughts on “One size fits all ALM tool is just a dream”

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts


Release Engineer for ARA

OpenMake Software enters ARA DevOps Market OpenMake Software drives release management with Application Release Automation (ARA) Chicago, IL – June 25, 2014 – OpenMake Software today announced the July 15th , 2014 GA date of Read more...


Accelerated Builds – are they fact or fiction?

Accelerated builds – critical to agile development Accelerated builds for continuous integration Accelerated builds have been a topic for OpenMake Software since Meister was first created. The October 2013 issue of SD times has an article Read more...


Continuous Delivery Vs. Application Release Automation

Continuous Delivery and Application Release Automation Understand the difference between application release automation and continuous delivery Application Release Automation is a set of tools while Continuous Delivery (CD) is a process. Continuous Delivery is an Read more...