Managing Your Software Release Process with Software Configuration Management
Bringing media, analysts and the software change and configuration management community together for open and lively discussions about the industry, its changes and direction based on the more complex development scenarios of today's parallel, geographically distributed and Agile development world. See http://blog.accurev.com for more technical ramblings on SCM Best Practices.
Tuesday 20 November 2007, 8:46 PM
Where is SCM Headed?
Once upon a time there was version control and then there was software configuration management (SCM). Now we're talking about Application Lifecycle Management (ALM) and ALM 2.0. But let's focus a moment on what's really happening, not just what's the latest hot topic or flavor of the year.
Not long ago, organizations of all sizes and industries were wondering, 'Just what size version control or SCM tool is right for my shop?' Some were buying tools they didn't need, with functionality never unlocked. Others weren't buying enough functionality, struggling to get an open source tool with man years of scripting and in-house add-ons to do what a commercial SCM tool could do out of the box.
Now it seems to be 'Best-of-Breed vs. 'Single-Vendor One-Stop Shop' - Should we lock-in to one vendor to harrass just one support organization and have tight integrations with all the lifecycle tools (regardless of whether some are decent, good or great) or should we choose the absolute best tools in each category and use the APIs to integrate them (those not already integrated by the vendor) ourselves? Some are learning the integration piece wasn't as hard a problem as they thought it was going to be. Others still think there is a good marketing message in it.
Many software development groups in the world (and this includes Entprise IT as well as ISV) still don't even integrate a version control tool with an issue tracking tool. Even when the integration is done for them or it's inherent in the SCM tool itself. Now others of course have their own homegrown issue-tracking system, and we all know how many years of business logic and processes can be tied up into that and lost forever. The better SCM tools allow teams to work by issue instead of by file without batting an eye or thinking of the old days with that dreaded CRM and defect managment system.
Other organizations associate SCM with bureaucratic process, but there are types and degrees of process. If I had another word for process that would smell of sunshine, I would use it, because that's just what the SCM tool I am most familiar with is like compared with the word you probably associate with process.
I work for a software vendor that introduced a paradigm shift in SCM over 7 years ago, with an architecture built on streams instead of those antiquated branches that branch and label version control tools of yester-year developed before today's complex parallel, geographically distributed, and Agile development scenarios became so prevelant. It greatly simplifies managing multiple releases in parallel for one, but also simplifies the development process (think of moving it off the whiteboard and into your SCM tool, but then actually being able to quickly make changes to it without disrupting your teams) that can be associated with all things big, heavy and bureaucratic. This tool makes it anything but.
SCM, SCCM (software change and configuration management), and ALM ("the tools") regardless of their divergent and similar paths, must be simple to use, elegant and powerful, and be easily adopted by both management and developers alike. They must improve productivity, not introduce additional overhead or complexity, be transparent to the fullest extent, yet drive adherence and compliance to ensure what is requested is delivered, on time and on budget, with the highest quality possible. Yes, change has happened, is happening and is coming.
SCM is a discipline not often found in universities, vastly misunderstood in organizations, and with confusing terms often confused by its own masses (CM, SCM, SCCM, change management, configuration management, etc.). But one thing is for sure, it's headed to a development shop near you, because without it, in one form or another, there is only chaos.
Not long ago, organizations of all sizes and industries were wondering, 'Just what size version control or SCM tool is right for my shop?' Some were buying tools they didn't need, with functionality never unlocked. Others weren't buying enough functionality, struggling to get an open source tool with man years of scripting and in-house add-ons to do what a commercial SCM tool could do out of the box.
Now it seems to be 'Best-of-Breed vs. 'Single-Vendor One-Stop Shop' - Should we lock-in to one vendor to harrass just one support organization and have tight integrations with all the lifecycle tools (regardless of whether some are decent, good or great) or should we choose the absolute best tools in each category and use the APIs to integrate them (those not already integrated by the vendor) ourselves? Some are learning the integration piece wasn't as hard a problem as they thought it was going to be. Others still think there is a good marketing message in it.
Many software development groups in the world (and this includes Entprise IT as well as ISV) still don't even integrate a version control tool with an issue tracking tool. Even when the integration is done for them or it's inherent in the SCM tool itself. Now others of course have their own homegrown issue-tracking system, and we all know how many years of business logic and processes can be tied up into that and lost forever. The better SCM tools allow teams to work by issue instead of by file without batting an eye or thinking of the old days with that dreaded CRM and defect managment system.
Other organizations associate SCM with bureaucratic process, but there are types and degrees of process. If I had another word for process that would smell of sunshine, I would use it, because that's just what the SCM tool I am most familiar with is like compared with the word you probably associate with process.
I work for a software vendor that introduced a paradigm shift in SCM over 7 years ago, with an architecture built on streams instead of those antiquated branches that branch and label version control tools of yester-year developed before today's complex parallel, geographically distributed, and Agile development scenarios became so prevelant. It greatly simplifies managing multiple releases in parallel for one, but also simplifies the development process (think of moving it off the whiteboard and into your SCM tool, but then actually being able to quickly make changes to it without disrupting your teams) that can be associated with all things big, heavy and bureaucratic. This tool makes it anything but.
SCM, SCCM (software change and configuration management), and ALM ("the tools") regardless of their divergent and similar paths, must be simple to use, elegant and powerful, and be easily adopted by both management and developers alike. They must improve productivity, not introduce additional overhead or complexity, be transparent to the fullest extent, yet drive adherence and compliance to ensure what is requested is delivered, on time and on budget, with the highest quality possible. Yes, change has happened, is happening and is coming.
SCM is a discipline not often found in universities, vastly misunderstood in organizations, and with confusing terms often confused by its own masses (CM, SCM, SCCM, change management, configuration management, etc.). But one thing is for sure, it's headed to a development shop near you, because without it, in one form or another, there is only chaos.
