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.