We in the CM/ALM community rely on tools, but how do we pick the best tools for the job? These six requirements outline what we look for in our ALM tools and what we don't want to see. Vendors, take heed!
In this article, I will spell out what we in the CM/ALM community need in the tools that are being called ALM tools. I also call out the traits and tactics I'd like to see disappear from the tool selection process.
No More Plug-ins
There is nothing in the world that bothers me more than a vendor that has a tool that they claim is an ALM tool, but 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 when 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 plug-in requires the issue management plug-in as well. You then inquire about the release management tool, the deployment tool, the build tool, etc. All of these require that you have to purchase even more plug-ins. Now, all you have is a tool that looks like a Mr. Potato Head. Not only do you have to open one tool you also may be forced to open five 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 and neither does 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, an 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 Seamlessly with Other Tools
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. 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 is that 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 might never occur, but it would be beneficial to all.
Let’s Define ALM
Strangely enough, this has yet to be done. Merriam-Webster’s online dictionary doesn’t have a definition for ALM, but there is a Wikipedia page that has a definition for ALM. 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 forty-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
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 it’s difficult enough to get three people to decide where they want to eat lunch together, let alone getting ten or fifteen vendors to agree what a concept is.
