I will go ahead and warn you now, if you are expecting to find out what tools are the best of breed this is not your article.  In this article I will spell out what we the CM/ALM community need in the tools that are being called ALM tools.  I will not discuss ALM techniques that will be covered in other articles in the CM Journal.

No More Plug-ins
There is nothing in the world that bugs me more than a vendor that has a tool that they claim is an ALM tool and when you ask the vendor a question like, “So does this ALM tool allow you to track Requirements from the requirement document down to the code level?”  They answer “yes” and you say “That’s great where is it in the tool?”   They respond, “You have to buy the plug-in.”  Then you find that the Requirements plug-in requires the Issue management plug-in as well.    Then you inquire about the release management tool, the deployment tool, the build tool, etc.  All of these requires that you have to purchase even more plug-ins.  No all you have is a tool that looks like a Mr. Potato Head.  Not only do you have to open one tool you may be forced to open 5 different tools to achieve what you need.

Give Us Real Integrations
First and foremost an integration is not simply a link from one tool to another.  That does not pass the test of calling a tool integrated, neither is a short blurb about the action that took place.  Integration as defined by me is the following:  I can operate in one tool exclusively without having to invoke another to complete an action, i.e. I can checkout code from my requirements area and submit an issue from the version management area in my tool.  Opening up multiple tools to complete multiple actions is no longer acceptable.  We want to be able to operate in one tool and that is the end of that.  I think most people would agree that having “tabs” would be acceptable, so you could have a version management tab, a issue management tab, a requirements management tab, a release and deploy management tab, etc.  Improving the tools must take precedence over selling more product.

Make Administration Easier
It should not take a rocket scientist or a nuclear physicist to administer the tools.  It’s true that these tools are very complex by nature and administration can’t be too overly simplistic because of the nature of ALM.  However, the fact that some tools require very expensive server configurations and highly paid administrators is unacceptable.  Administrators of these tools have to have a wide variety of knowledge about ALM and every piece that fits together and this is not going to come cheap, but I have seen some tools that haven’t changed significantly in the last ten years.  The time is now, to make administering these tools easier and cheaper.

Integrate with Other Tools Seamlessly
Not since the Application Lifecycle Framework (ALF) died a few years ago has there been a serious effort to make all of the different tools work together.  Though some may argue that IBM’s Jazz framework is a positive step in that direction and it is a step in the right direction.  The keyword, however, is seamlessly.  If ALM tools are going to be marketed as such they should be able to run other applications from competitors in the same way they run their own tools.  This is one of the reasons that ALF failed, the big players never got on board except for Serena.  I challenge all companies to open your source to other vendors and let’s have integrations that are seamless, I know that’s asking a lot and may never occur, but it would be beneficial to all.

Let’s Define ALM
Oddly and strangely this has yet to be done.  Merriam-Webster’s online dictionary doesn’t have a definition for ALM; there is a Wikipedia page that has a definition for ALM though.  Microsoft has this on their website from David Chappell and Associates back in 2008:

“Defining application lifecycle management (ALM) isn’t easy. Different people (and different vendors) take quite different perspectives. Still, ALM is an important topic, and so understanding what it encompasses is also important.”

There are very few resources available for training and no one to date has stepped up and done anything to get all of us on the same page.  I think the main reason is that ALM is a progression of CM and as such, yet to be defined.  We don’t have one single definition of Configuration Management that all of us can agree too yet and our field is over 40 years old or older.

Unity in ALM World
My greatest fear is that no one will step up to the plate on this and we will be left in a quagmire like we are in the CM world.  Unfortunately, this process has already started.  I looked at five different vendors and got five different visions of what is needed to properly manage ALM.    This will result in practitioners knowing what is expected and what is desired in ALM based off of the tool that they use, and we will have multiple methodologies used to implement ALM solutions.  One could argue that Agile Methodologies have different solutions, to them I would say that is true but it appears to me that Scrum is winning that battle or at least the one with the most press.  So whether you prescribe to what I am saying or not, we need something or someone in the ALM arena to step up, define it, and move forward collectively or we can remain a dysfunctional group of people like we have in the CM world.

Conclusion
To recap what I think needs to be done, I would like to see ALM tools that are a one stop shop and not a bunch of plug-ins resulting in a beast of several tools.  Real integrations no pointers or a blurb of data and make the administration as easy as possible so ALM practitioners can work on what’s really important.  If we can’t have one stop shops then let’s at least have seamless integration with different tools in the ALM Model.  Can someone please define what ALM is and unify the ALM concepts so we are all on the same page.  This may be a tall order since you can rarely get 3 people to decide where they want to eat lunch at, let alone 10 or 15 vendors to agree what a concept is.

Trackback(0)

TrackBack URI for this entry

Comments (4)

Subscribe to this comment's feed

Joe P. Townsend said:

... Thanks for your comments. Eric you stated: "I'm curious though if your distaste for plug-ins is based primarily on the behavior of plug-ins, or on the behavior of vendors who treat them as "up charge" opportunities? " I think both reasons are concerns for me and I am assuming many others as well. I don't think many people like to be sold parts to a solution they like the whole solution if possible. Granted their are some tools stronger than others in certain areas, but buying from different vendors is tricky at best, due to the way tools integrate and the level at which they integrate. So that leaves the industry in a dilemma, do we open our source up to allow tools from other vendors to more tightly integrate, do we go it alone, or is the current state good enough. I wish there was an easy solution, but there is not. Regards, Joe Townsend

report abuse vote down vote up

April 12, 2011
Votes: +0

Eric Minick said:

... Joe, I really wanted to cheer you on for your demand of tight integrations. I'm curious though if your distaste for plugins is based primarily on the behavior of plugins, or on the behavior of vendors who treat them as "up charge" opportunities? I started to write a more detailed response, but it went long. It eventually found a home on our blog: http://www.anthillpro.com/blog...ality.html . Thanks for the thought provoking post.

report abuse vote down vote up

March 21, 2011
Votes: +0

Joe Farah said:

... Nice article Joe. Hitting the nail on the head. Before I talk a bit about CM+, I agree that we need better ways to integrate tools, and better definitions of ALM. MKS implies that PLM should be part of ALM, and while I agree that the same tool should be used for both, in a seamlessly integrated fashion, this goes beyond ALM into the Enterprise Management System realm, which should also look after various other functions in the enterprise. MKS and Neuma both provide solutions that can be easily extended to seamlessly integrate functions of ALM, as well as custom functions defined by the organization. Integrating with other tools seamlessly will never occur using a framework unless the framework includes the common platform for the functions. In the case of CM+, this is the STS Engine. If you use only relational databases, you can't cover the breadth of engineering operations required. If your process engine is different for each function, or your Multiple Site operation, you won't get seamless. With CM+, Neuma took a different approach. Provide the framework and let the customer add functionality. This does allow a good level of integration of 3rd party tools, but if each tool has a different repository, process engine, administration, global operation, UI, etc. no framework is going to bring them together. One opportunity is to get rid of the high admin, the "Big IT". To do this, Rational tools, MKS tools, and other integrated toolsets, need a better platform. The STS Engine was designed to be exactly that platform. (See my article on Next Generation ALM Tools). Perhaps vendors wishing to eliminate the "Big IT" should consider the "STS Engine" as a new base platform. Tools that are primarily command-line in nature, with or without a token GUI, can use the STS Engine to integrate and expand their tools into a framework that includes ALM and other functions. Cheers, Joe

report abuse vote down vote up

March 18, 2011
Votes: +0

Matt Klassen said:

... It just so happens there is one product that does not resemble Mr. Potato Head. One that does "allow you to track Requirements from the requirement document down to the code level". It allows all lifecycle artifacts and relationships to be represented in a single data model. Many of our customers also find it very useful to integrate certain tools, they refer to as authoring tools, into the core engineering platform such that individual roles are "able to operate in one tool". In addition, within the realm of product engineering, seamless integration with PLM tooling is critical to ensure core processes, such as engineering change management, can be automated and enforced while providing complete traceability to all configuration items affected by the change. In terms of ALM definition, I would suggest that Dave West's most recent paper on ALM 2.0+ is the best I have seen to date. He suggests that ALM solutions have 5 core requirements: work planning, traceability, workflow/automation, reporting, and collaboration. These capabilities are definitely a good start. Once again organizations that develop software intensive products are pushing the limits with the additional burdens of cross discipline support for systems, software and hardware engineering, stringent compliance, a proliferation of product variants, extreme safety and quality standards, and high velocity software-driven change, just to name a few. www.mks.com

report abuse vote down vote up

March 16, 2011
Votes: +0

Write comment