Automating ALM – time we did

Worn, full of holes and beaten up

The irony is, we are the cobbler’s children. And now our shoes are worn, and full of holes and frankly all too shabby. The development infrastructure we have allowed to evolve in our organizations is no longer meeting the needs of the methodologies we use, the technologies we are developing and the governance we now have in place. The world of siloed tools and point-to-point integration between hinders our development efforts more than it supports them.

Process is the heart of ALM and today’s savvy app dev executive is buying tools that are process centric first and foremost, feature and function are far less important. The tools we buy today have to support our development process, not one imposed by the vendor, support our interpretation of the best practices, not some idealized subset from the vendor, and they must integrate with all of our other tools, irrespective of their authors, at the process level. Indeed integration must make it possible for us to swap out tools that no longer serve us so we can replace them, with no disruption, in minutes not months.

Once we can automate the stages of our software development lifecycle (SDLC) we fundamentally change the game of application delivery. Dashboards are springing up everywhere with real time data about the most detailed stages of the development process. One client told me “We’ve gone from fighting fires to finding out who is starting them!” after they implemented the automatic generation of KPI’s and SLA’s monitoring in the SDLC.

Never before possible automation of process exceptions is now commonplace. When a requirement changes, a requirement in the requirements management system from one vendor, the traceability enabled through ALM automation, means that the developer working that requirement in their IDE from another vendor, and the tester working in their testing tool from yet a third vendor get notifications. Approvals for the changes are automatically routed to the project leads and the project plans updated in yet a fourth tool. The seamlessness of the integrations in support of our process eliminates vast quantities of manual steps, thousands of emails, hundreds of meetings and billions of Excel spreadsheet cells.

If you are not automating your SDLC you are accepting as much as 20% wasted effort in your development processes. Find a workflow tool designed to automate IT processes, make sure it is one that works with all your existing tools, even the ones you’ve developed yourself, and get automating. I guarantee you will wonder why you didn’t do it a decade ago.

Oh, and if you are trying to get ISO, CMMI or any other certification … without automation you will fail.

About Admin

Web Admin
This entry was posted in Business and Technology and tagged , , , , , , , , , . Bookmark the permalink.

2 Responses to Automating ALM – time we did

  1. As always, a great post, Kevin. I’ve spent the last 6 months helping a client to identify meaningful metrics and KPIs, start automating their capture, and considering how best they can be used. What I have seen repeatedly across many organisations is that where metrics are captured, they will almost always later be used to give benefit in ways that had never originally been envisaged. Thus there is huge benefit in capturing as much information as realistically possible.

    The risk of course is that where metrics are only captured across a subset of transactions flowing through a given process, perhaps because it is easier to do this for some transactions than others due to toolset limitations necessitating manual capture, the results will be skewed. Experience shows that this is more likely to be a problem with a bunch of elderly tools, loosely cobbled together, exactly as you describe in your problem scenario above.

    It seems then that there is real merit in automating the SDLC as you advise, not just to deliver the obvious immediate quality and cost-saving improvements, but also to put the organisation in a position where it can easily automate the capture of KPIs and consequently possess sufficient data about itself to be able to use this as the basis of as-yet-unconsidered process improvements at some future time.

  2. Derek Pappas says:

    The chip design development process is in dire need of retooling. They are using the Verilog language, which is 25+ ears old, and lots of home brewed scripts. Fastpath Logic (FPL) built a solution to modernize the design flow. Many senior design and simulation engineers said that Synopsys and Cadence should have built this tool 15 years ago. Some folks at Intel told us that if they adopted the tool and methodology, Intel would save $25-50 million per year. The only problem is that the political will to change the methodology and tools in the chip design companies does not exist. As a consequence FPL went out of business and code is sitting in a software repo online doing nothing for the designer. Architecture and methodology sales take time, money, and political will to make.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s