ALM, or Application Lifecycle Management, is here to stay – at least until the marketing types come up with a new name for it. But there is a “Critical Mass” where time, as a resource, is the limiting factor on its implementation and growth.

In its current form, ALM consists of a framework to do builds of one kind or another and stage them through deployment. It also provides a way of capturing electronic signatures for approvals and rejections at various procedural gates. There is generally some way of mapping procedural components to process ones as well and there are indications that Project Management functionality is, or shortly will, be incorporated into the higher-end ALM tools. For simplicity, I am ignoring DIET (Defect, Issue and Enhancement Tracking), separate integration with regression test systems, notification systems, deployment mechanisms, etc., though these too are important parts of the ALM solution. The three primary components of Version Control, Build Management and Packaging will be enough to illustrate my point.

ALM – Getting Started
The ALM framework provides the glue to integrate what we used to do manually. Take source from Version Control, perform a controlled build with a controlled tool-chain, send the resulting build off to be tested (or perform some of the tests automatically), and package the build artifacts into a release for subsequent deployment to either production or to a staging area for “pull” access. Unfortunately, it suffers from one of the same problems we are used to facing – time!

In the following graph, there is an assumption that a minimum of a 15% overhead time is spent with each product every week. In some cases this is more time than is actually spent, but it is a reasonable overall average for discussion purposes. There is also an assumption is that it takes ramp up time to get each tool in the ALM tool-chain working, and that it will eventually ramp back down to the sustaining 15%. There is also an assumption that each tool in the chain will have to be periodically updated or augmented.

Version Control
It all starts with getting a Version Control system in place and having Development use it correctly. This usually means creating triggers and managing interfaces with the development tools as well as providing documentation and training. And everything we do in this regard has to be maintained, thus taking time. Since it is the first of the tools, it is the easiest to take online, but it is also the one that will require the most rework as the other tools are brought into the mix.

Build Management
Then there are the builds. In these days of Agile development it is not uncommon that there are pre-flight builds (pre-checkin builds that can block commits of code to the repository), continuous integration builds (tells what is broke before a production build runs) and of course the production or release candidate builds (this is what will eventually be packaged into a release if all goes well). In larger codebases it is not uncommon that we will also have to perform development builds (for individual developers) upon demand since in these cases it requires too much “system” for the developers to get builds done in a timely fashion on their workstations. All of the build scripts have to be written, maintained and optimized where appropriate. I know that the most common response these days is that Development is responsible for these scripts, but very few developers truly understand the build language in use, whether it be make, ant, maven or whatever and we, as Configuration Managers, will take the blame for “broken scripts” or builds that take too long. More time spent and how much “maintenance” time will actually be spent will, to a large extent, be dependent on how “volatile” the build scripts end up being.

Packaging
Packaging is relatively simple, right? Well, for those lucky few it is, but the normal case requires subtleties that Development is unaware of as well as a knowledge of where (and when) to get the artifacts to use in packaging. If we are smart, we have also locked down the source of those artifacts so that only CM can modify them, and thus have locked ourselves into having to be active participants in the packaging procedures, scripts, etc. Again, more time spent.

So, Where Does That Leave Us?
At some point we will get to the point where we have no more time. The graph illustrates this when the needed time exceeds 100%. I this example, the spike to 120% occurs when Packaging is being implemented and the VC and Build tools are having to be upgraded. The three bars near the end are where all three tools in this ALM example are in maintenance mode – and are steady at 45%. As most realize, this does not mean that the solution is only a part-time job, but rather a time to do pre-upgrade testing and process improvement.

There are two other things to keep in mind:

1. This is a simplified example and not all of the possible tools are represented in this tool-chain; especially DIET. Defects and Enhancements are normally integrated with both VC and Build Management to provide the required traceability from “things fixed/implemented” through to the artifacts that are released into production.
2. There are a lot of ALM solutions, especially commercial ones, that come with most, if not all, of the tools in the tool-chain already integrated and ready to go, but they still need to be installed, configured and secured. This last is often overlooked, but is outside the scope of this article and left for as a future topic.
   

Summary
There are only so many hours in each week and, like everything else associated with product development, the tasks that can eat at that time will grow until there is no time remaining. ALM is supposed to make things easier to do and faster to implement, but that only means that development, testing and release cycles are collapsing to use this time. This is what I meant by “critical mass” - the point at which the tools overload our ability to keep everything running satisfactorily. Development wants thing to be fast, unobtrusive and easy to merge. Quality (both QA and QC) want things to be inherently and easily testable and the customer just wants the product to be delivered on-time with a quality and ease of use that exceeds their expectations. CM is the glue that is supposed to make all of this possible and the tenets of good CM are such that Development, being optimistic by nature, does not make a good owner for the process and procedures – so we are stuck continually trying to do more with less time.

Trackback(0)

TrackBack URI for this entry

Comments (2)

Subscribe to this comment's feed

Ben Weatherall said:

... Hi Joe, Sorry for the delayed response. It has been awhile since I had the time to do a comparative evaluation of SCM tools, but I am well aware of CM+. I have historically come into an organization that was in distress (no one calls in a consultant to brag about how well they are doing), and the most common situation I faced with integrated solutions was, "We are happy with the xxx part of our tools, just fix yyy." This may not have been the best solution, in fact it often was one of the worst solutions, but Management had their own ideas and agendas. In fact, when I proposes an integrated solution a few years ago I was treated to an analogy to the aerospace industry when the F-16 was first being developed. One of the primary bidders had a better solution, but it only had one engine (the bid specs called for 2 engines). The one engine solution was more powerful, more maneuverable and provided for better armor (including of the engine). They were rejected because the proposal only had one engine. Period. It did not match their expectations. To be fair, the reason for two engines was to allow the plane to fly if one of the engines was damaged, but I hear that flying an F-16 on one engine was a challenge! A more concrete example from the recent past was the desire of one company to do things a certain way. If you want to discuss the details off-line, I will be glad to, but the gist was that they wanted to replace the Version Control piece of a working solution instead of taking advantage of its strengths. I look forward to your next article. Maybe it will give me ammunition for future discussions. Regards, -Ben

report abuse vote down vote up

April 04, 2011
Votes: +0

Joe Farah said:

... Hi Ben, I think your point is well taken. If you are using a myriad of tools to implement ALM, you're going to get maxed-out. But what if you're using something like CM+ which has a single integrated platform (the STS Engine), near zero administration, trivial upgrade (not of each ALM tool function but of all together), common user interface (to reduce training), and rapidly defined custom task/role dashboards? OK, there are not many other tools out there that can do this, but you might want to look at CM+ or even my Next Generation article for this issue to convince yourself that there is an easier way forward. Regards, Joe

report abuse vote down vote up

March 22, 2011
Votes: +0

Write comment