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


Do Build Automation like Google Rock Stars

Build Automation at OpenMake Software and Google Build Automation a topic at Google Build Automation is what OpenMake Software has survived on for the last 20 years.  It is core to your software development efforts Read more...


Build Avoidance and Continuous Integration

Build Avoidance is a feature of Meister Build Avoidance a critical part of continuous integration In a recent article, the term “Build Avoidance” was referenced as if it was something new and improved.  NEWS Flash!  Read more...


Ear file deployment to Websphere Cluster

Steps to perform an Ear file deployment Steve Taylor provides tips on setting up and Ear file deployment I am often asked how to standardize a ear file deployment around a WebSphere Cluster.  Deploying an Read more...