Behaviorally Speaking Behaviorally Speaking – Beyond CM into ALM
|
ALM is hot! What About RUP/OpenUP? Touchpoints Develop Driven by Workitems Agile/SCRUM Status Accounting Conclusion About the Author Bob Aiello is the Editor-in-Chief for CM Crossroads and the author of CM Best Practices: Practical Methods that Work in the Real World, Addison-Wesley Professional (http://cmbestpractices.com).
Bob is the Executive Director of Practices and Services at Configuration Management, Inc. (www.cmi.com) where he specializes in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long-standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he has served as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at bob.aiello@ieee.org or link with him at http://www.linkedin.com/in/bobaiello
Set as favorite
Bookmark
Email this
Hits: 1841 Trackback(0)Comments (7)
|
This month’s topic really puzzled me. At face value, it sounds like we are moving from a limited function of CM to the wider function of ALM. Classic configuration management includes four specific functions including configuration identification, change control, configuration audits and status accounting. Often misunderstood, status accounting is following a configuration item throughout its lifecycle. So if we think about how to implement status accounting, we have to consider a full lifecycle approach – which leads us right to Application Lifecycle Management (ALM). It’s my view that CM already owned ALM. Read on if you would like to share some lessons learned from implementing what is now known as ALM!
TrackBack URI for this entry
Subscribe to this comment's feed |
... Colin, this is a good discussion to have. Let me ask you this question. How do we actually perform "status accounting" (one of the classic four CM functions) in a real life "leave-your-ivory-tower-behind" scenario? Bob |
Colin Doyle
said:
 |
... Regardless of whether you follow an ALM approach or not, configuration management should be active throughout the life cycle. CM is one of the core underpinnings of ALM. However I disagree that CM "already owns" ALM; CM is one of the essential functions within ALM, but ALM is more than just ALM. ALM is not so much a function, as a framework or approach to implementing ALL the development functions. ALM is a framework that recognizes that all development artifacts and activities are tightly related to one another, and need to be managed in a cohesive, coordinated manner. At the heart of ALM is comprehensive change and configuration management of all the artifacts involved in the development life cycle, not just the source code. It also ties the other disciplines, such as requirements management, defect management, test and release management together with those core disciplines. Requirements management entails more than managing the configuration of sets of requirements; there is analysis, elaboration and allocation activities that CM does not cover. That said, requirements management (or test management, or any other functional development discipline) is lost without good configuration management. In my opinion, ALM encourages these functions to be managed in a holistic manner, rather than as isolated disciplines - it is not a different discipline, but a different (and better) way of managing all the disciplines. |
Bob Aiello
said:
|
... I appreciate these comments guys. I recently spoke at the CMPIC Conference in San Diego and my message was essentially a "call-to-arms" for CMers. I believe that we need to make CM compelling instead of just assuming that "companies have to have CM." I think that our colleagues in the Agile, Lean camps along with Continuous Integration enthusiasts have done a better job of getting their message out. We need to take our promotion of CM Best Practices up a notch really show our colleagues that CM done right can improve productivity and quality. |
Dirk Wessel
said:
 |
... I fully support the view of Bob. CM and specifically CSA has always been geared to support the life-cycle of a system. But it was limited to the management of configurations related to CIs. Today, in more complex environments, we should try to get CM out of the dungeons and apply an holistic view which includes obviously ALM and even further it should also include PLCS and the enterprise itself. |
Bill Buie
said:
 |
... "Me too." Even if we ourselves understand how classic CM addresses software development issues in the 21st century, we still have to be able to communicate our concepts to our non-CM colleagues to deliver our value proposition. If learning to speak in terms of ALM concepts will help us do a better job of coordinating software development and preventing rework, I'm all for learning the language other people are learning to speak. |
Jack Repenning
said:
 |
... You're right, Bob: cm//crossroads' view of "CM" has always fully encompassed ALM. But as Bill Portelli just pointed out on Monday, this has been a learning process for the industry at large. There was a time when products claimed "Configuration Management" simply because they could relate "which version of that file goes with this version of this file": build configurations alone. Closing the loop with requirements versioning, traceability, impact analysis, and status accounting; encompassing the life*cycle* of multiple releases (not just the gestation of one)... it's all a big step. I think much confusion comes from dithering over how much of that progress can be called "broadening our grasp of CM," and when it becomes "approaching a vision of ALM," which is why it's good that this forum encompassed the whole vision from the outset. What I think we who've seen the full vision need to remember is just how grand and ambitious a vision it is. Many are still focused on the "software gestation" rudiments of file versioning and build-configuration identification. We could probably help them on board if we would agree on some terms for some of the stages between build versioning and full ALM. |
