Planet SCM

Some of the discussion with my co-authors on our May 2008 CM Journal article on Agile Release Management spurred some additional thoughts by me that I hope to refine and work into a subsequent article later this year.

Release Management is about so much more than just the code/codeline (and it being "shippable") it's not even funny. Some other articles to reference and mention some key points from are:

• Breaking the Major Release Habit
• Release Management - Making it Lean and Agile

Kevin Lee has written some GREAT stuff on Release Management that relates to Agile. The best is from the first and last chapters of his book on "The Java™ Developer's Guide to Accelerating and Automating the Build Process" but bits of pieces of it can also be found at:

• Agile SCM in the Enterprise
• Software Release Management Best Practices
• Agile Software Delivery
• Architecting the Build Process

ANY discussion about Release Management also needs to acknowledge that there is no single "the codeline", not just because I may have different codelines (Development-Line plus Release-Line) working toward the same product-release, but ESPECIALLY because no matter how Agile you are, the reality is that you will typically need to support MULTIPLE releases at the same time (at the very least the latest released version and the current under development version, but often even Agile projects need to support more than one release in the field)

So, when dealing with multiple release-line, and any "active development lines" for each of those, and the overall mainline, we really should say something overall about how to manage this "big picture" of all these codelines across multiple releases and iterations:

• What is the relationship between development line, release-line and release-prep codeline?
• How do the above three "lines" relate to "mainline"
• What is the relationship between the different release-lines for the different supported releases
• What is the overall relationship between the mainline and the release-lines (and if the mainline is also a release-line, which release is it?)

The above questions and the ability to give some big picture "advice" on relating it all together (the stuff of pattern languages) is precisely where Laura Wingerd's writing on "channeling the flow of change" and her chapter on "How Software Evolves" fits in! It tells us

• The overall Mainline model
• The different types of codelines ("line" patterns), and what kinds of builds take place on each of them
• The relationships of those to the mainline
• When+Why to branch (and from which "types" of codelines)
• When+Why to merge across codelines (as a general rule)

These are where Laura's rules for "the flow of change" apply. And her concept of "change flow" is very much applicable to the Lean/Agile concept of "flow of value". The Tofu scale and "change flow" rules/protocol have to do with order+flow of codeline policies across the entire branching structure when it comes to making decisions about stability -vs- speed. One codeline's policy might make a certain tradeoff, but it is the presence of multiple codelines and how they work together, and how their policies define the overall flow of change across codelines, that forms the "putting it all together" advice that is key to release management across multiple releases+codelines.

In some way's you could make an overall analogy to the Laws or Thermodynamics and the realities of codeline management. Software and codelines tend, over time, to grow more complex and, if unchecked,
"Entropy" (instability) quickly becomes the most dominating force to contend with in their maintenance. See

• "The 8 'Laws' of Software Evolution", and ...
• "The Laws of Software Complexity"

The "entropy" (instability) doesnt just happen within a codeline. It can actually get far more hideous when it happens across codelines via indiscriminate branching from, or merging to, other codelines. This is what happens when you don't respect the principles and rules of "change flow" (from Wingerd) which ultimately stem from the rules of smooth and steady (value-stream) flow from Lean.

The Laws of Thermodynamics are about energy, entropy, and enthalpy. In the case of release management and codelines ...

• energy relates to effort & productivity
• entropy relates to stability/quality versus complexity
• enthalpy relates to "order" (i.e., in the sense of structure and architecture as Christopher Alexander uses the term "order"). It is the "inverse" of entropy.

We could call them them "Laws of Codeline Dynamics" :-)

Energy misspent degrades flow, creates waste, and hurts productivity/velocity. In traditional development, we often see "fixed scope" with resources and schedule having to vary in order to meet the "scope" constraint. IN Agile development we deliberately "flip" that triangle upside down (see the picture in the article at here under the title "The Biggest Change: Scope versus Schedule - Schedule Wins"). So we are fixing "resources" and "schedule" and allowing scope to vary.

This might be one way of viewing the law of conservation of energy. If we fix resources and time (and insist on "sustainable pace" or "40hr work week") then we're basically putting in the same amount of effort over that time-box, but the key difference is how much of that effort results in "giving off energy" in the form of waste ("heat" or "friction") versus how much of that energy directly adds value. Both "Value" and "Enthalpy" degrade or depreciate over time, and adding more energy (effort) doesnt necessarily mean value is increased.

To make sure that energy goes toward adding value (and minimizing waste) we need to focus on the flow of value, and hence the flow of change/efforts to create value (the latter is one reasonable definition of a "codeline" or a "workstream"). to ensure a smooth, steady, and regular/frequent flow, there are certain rules we need to impose and regulate stability within and across codelines to better manage all those releases.

Zeroth Law of Thermodynamics (from Wikipedia)

- If two thermodynamic systems are each in thermal equilibrium with a third, then they are in thermal equilibrium with each other.

Translation to codelines ... this law of "thermal equilibrium" is a law of "codeline equilibrium" of sorts. (Does this mean If two codelines are are "in equlibrium" with a third codeline, then they are "in sync"? and with each other? here "in sync" doesnt mean they have the same frequency, it means their is some synchronization pattern regarding their relative stability and velocity. In Lean Terms, this would refer to "nested synchronization" and "harmonic cadence"). This might imply the "mainline" rule/pattern or one of Wingerd's rules of change-flow.

First Law of Thermodynamics

- In any process, the total energy of the universe remains the same.

This is the statement of conservation of energy for a thermodynamic system. It refers to the two ways that a closed system transfers energy to and from its surroundings - by the process of heating (or cooling) and the process of mechanical work.

This relates to effort & changes expended resulting in the creation of value and/or the creation of waste. We have activities that add value (which we hope is development), activities that preserve value (which is what much of SCM attempts do, given that it doesnt directly create the changes, but tries to ensure that changes happen and are built/integrated with minimal loss of energy/productivity/quality), and then we have activities (or portions of activities) that create waste (and increase entropy rather than preserving or increasing enthalpy/order)

Second Law of Thermodynamics

- In any isolated system that is not in equilibrium, entropy will increase over time

So this is the law of increasing instability/complexity/disorder. The "key" to preventing this from happening is achieving and then maintaining/preserving "equilibrium". How do we achieve such equlibrium? we do it with the "release enabler" patterns for codeline management (which help ensure "nested synchronization" and "harmonic cadence" in addition to achieving a balance or equilibrium between stability and velocity (to smooth out flow).

Third Law of Thermodynamics

- As temperature approaches absolute zero, the entropy of a system
approaches a constant minimum.

In our case, "Temperature" could be regarded as a measure of "energy" or "activity". As the energy/activity of a codeline approaches zero (such as a release in the field that youve been supporting and would LOVE to be able to retire that codeline sometime real soon), it's instability approaches a constant minimum.

This is perhaps another more polite way of saying something we already said in our article on "The Unchangeable Rules of Software Change", namely that "absolute stability" means dead (as in, "no activity"), and should serve as a reminder that our goals is not the prevention of change in order to achieve some ideal "absolute stability", for such an absolute would mean the project not just "done" but "dead".

On the other hand, it also speaks to us as a guideline for when it is safe to retire old codelines, and when to change their policy in accordance with their "energy level"

I started reading through the book Implementing ITIL Configuration Management, by Larry Klosterboer. I'm really not what I'd consider an expert on ITIL nor IT Service Management, but I've had more than my fair share of exposure to it and am certainly no "slouch" in that area either.

This book looks to be an overview of ITIL and to how it applies to configuration management. From there one can extrapolate how much of it relates to CM for not just IT assets and infrastructure but to the software development environment and to software development itself.

The book includes coverage of the following (from the back cover):

• Assessing your current configuration management maturity and setting goals for improvement
• Gathering and managing requirements to align ITIL with organizational needs
• Describing the schema of your configuration management database (CMDB)
• Identifying, capturing, and organizing configuration data
• Choosing the best tools for your requirements
• Integrating data and processes to create a unified logical CMDB and configuration management service
• Implementing pilot projects to demonstrate the value of configuration management and to test your planning
• Moving from a pilot to wide-scale enterprise deployment
• Defining roles for deployment and ongoing staffing
• Leveraging configuration management information: Reporting and beyond
• Measuring and improving CMDB data accuracy

To take the next step, and for a REALLY thorough treatment of how IT service management and CM comes full circle to embrace all of enterprise architecture and software development, I highly recommend Charles Betz' book Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children. As I mentioned in a blog-entry early last year, this book "really ought to be required reading for anyone that fancies themselves a 'CM professional' (especially Software CM) or an 'Enterprise Architect.'"

A colleague of mine had a question for me about Distributed Versions Control Systems (or DVCS). There are a growing number of such systems these days: Mercurial, Bazaar, git, svk, BitKeeper, Gnu Arch, darcs, Monotone, Codeville, Arx, just to name a few. I referred them to a good essay by David Wheeler that talks about the fundamental differences between distributed vs centralized VCS (among other things).

I also Googled on the topic and came across some interesting links:

• Distributed Version Control Systems: A Not-So-Quick Guide Through [link added 5/13/2008]
• Wikipedia page on Distributed Revision Control
  
• Eric Raymond's Understanding Version Control
  
• Ben Sussman on the Risks of DVCS
  
• Ian Clatworthy on Distributed Version Control: Why and How
  
• Ian Bicking on Distributed vs Centralized VCs
  
• Another blog-entry on DVCS vs VCS
  
• Introduction to Distributed Version Control Illustrated
• Choosing a Version Control System
• Distributed VCSes: git vs. Mercurial vs. SVN
• Why Distributed Version Control matters to you, Today!
• Distributed VCS for the other 80%
• Distributed VCS Shootout Redux
• The New Breed of VCSes
• Why Distributed VCS?
• Zooko's Quick Ref Guide to Free DVCS
  

Anyone else have any links they recommend on the topic? (please, no spam/marketing)

Peter Eeles and I must be subconsciously on the same page. Because at the same time I was blogging about Software Architecture Views and Perspectives and Software Architecture Quality Attributes and their direct applicability to SCM/ALM solution architecture (and software process in general), Peter was working on an article for IBM developerworks entitled The Rise of the Development Environment Architect:

[Development] environments present challenges; and, interestingly, these challenges are similar to those of the systems they support. For example, development environments have to deliver against the required functionality and properties (such as performance and usability), often have to coexist with legacy systems (such as, in the case of a development environment, existing methods and tools), and have to acknowledge other constraints (such as the distributed nature of development teams, and existing skills and infrastructure).

All in all, creating a well-oiled development environment that accelerates, rather than hinders, project performance is a science unto itself. This is why IBM® Rational® has spent many years specifically developing a services capability that understands the challenges faced by organizations that 1) want to improve developer productivity, and 2) regard their development organization as a strategic differentiator, rather than simply a cost center.

Our experience has led the Rational team to define a role within the software development lifecycle called the "development environment architect." In October 2007, one hundred of Rational's most experienced development environment architects from across the globe gathered together in the first conference dedicated to this role to share their experiences. This article is a result of that conference and the discussions that took place.

As you read the concepts presented here, you may well question whether the development environment architect should be a role itself, or whether the individual or team who normally functions in the software or systems architect role should simply add consideration of the development environment to their list of architectural concerns. I believe that both propositions are valid. Furthermore, whenever the role of the "architect" is discussed, it is always qualified with the domain under consideration; thus we speak of a "building architect," "software architect," "systems architect," "enterprise architect," etc. The development environment is simply one of these domains, and one that is not traditionally a concern for the "software architect" role. I therefore believe that the "development environment architect" role is one that hasn't been emphasized before -- hence this article.

This article has several audiences and objectives. It is relevant to organizations undertaking an improvement to their development environment and who need to understand the value of a development environment architect to help guide their initiative. It is also relevant to those who are responsible for the technical content of the development environment -- i.e., development environment architects -- because this article introduces this responsibility as a role not previously defined. Finally, this article may supplement material contained within a development environment, in helping communicate its content, the role of its architect, and the benefits of having such a role in place.

Read the full article here. I may blog later about the similarities and differences between the sort of architecture that Eeles describes versus my 4+2 Views Model of SCM/ALM Solution Architecture

The November 2007 issue of the CM Journal was devoted to the theme of "What Best Practice is Best?" Joe Farah's article on The Top 10 SCM Best Practices was quite possibly the best article on SCM best practices that I've come across to date!

Joe actually first lists his top ten "runners up" followed by his top ten. They are as follows (read the article if you see any terms that are unfamiliar to you):

1. Use of Change Packages
2. Stream-based Branching Strategy - do not overload branching
3. Status flow for all records with Clear In Box Assignments
4. Data record Owner and Assignee
5. Continuous integration with automated nightly builds from the CM repository
6. Dumb numbering
7. Main branch per release vs Main Trunk
8. Enforce change traceability to Features/Problem Reports
9. Automate administration to remove human error
10. Tailor your user interface closely to your process
11. Org chart integrated with CM tool
12. Change control of requirements
13. Continuous Automation
14. Warm-standby disaster recovery
15. Use Live data CRB/CIB meetings
16. A Problem is not a problem until it's in the CM repository
17. Use tags and separate variant code into separate files
18a. Separate Problems/Issues/Defects from Activities/Features/Tasks
18b. Separate customer requests from Engineering problems/features
19. Change promotion vs Promotion Branches
20. Separate products for shared code

Granted, some of these may not be particularly Agile (nor were they meant to be specific to Agile development or Agile CM) but it's still a pretty darn good list in my opinion!

I found a couple of great resources on Lean CM that are very compatible with the article we wrote last month on Lean-based Metrics for Agile CM Environments.

• Lean Configuration Management – Supporting Increased Value Delivery from Agile Software Teams
  by Jens Norin and Daniel Karlström, in the Proceedings of the 6th Conference on Software Engineering Research & Practice in Sweded (SERPS'06), October 2006 (and also in September 2006 as a Softhouse Whitepaper on Lean CM)
• Gain flexibility & speed with Lean CM
  by Joe Beckett, Plant Magazine, June 2005

I've added these and some others to the list of Agile SCM Articles on the CMWiki.

The May issue of the CM Journal is devoted to the theme of CM & Agility. Myself and Rob Cowham wrote an article for it entitled Defining Agile SCM: Past, Present and Future.

In our earliest articles on the topic, we defined Agile SCM as "the pragmatic application of sound CM principles & practices in accordance with Agile values, using Lean thinking, to serve the needs of the business!" We wish to elaborate what that means in terms of SCM for Agile development, but even more importantly in terms of how we should apply Agile, Lean and their related principles to SCM processes and procedures.

Basically, we try to emphasize that Agile CM is more than just CM for Agile projects, it also means making CM itself be Agile and using the principles tools and techniques of Agile, Lean, TOC (and even some Six Sigma) for CM. Give it a read through and then give us your feedback!

There is also (finally) a new forum on CMCrossroads.com specifically for Agile CM. Of course one of the discussion topics is "what is Agile CM?" and a lot of detractors saying there is no such thing - that it's just plain old CM for Agile projects and that CM is still CM. I contend it ain't the same old CM, and that Agile CM does more than simply apply classic CM discipline & principles to Agile projects, it also applies Agile/Lean principles, tools and techniques and is just as different from traditional plan-based CM as different architectural styles.

Almost a year ago I posted an entry on the "5 C's of Agile SCM Codelines". This time I'm posting on the 5 R's of Agile SCM Baselines. I think these are as follows (note that most of these are not unique to Agile/Lean):

• Repeatable -- The steps to create the corresponding Build (Configuration) from its sources should be repeatable: for any baselined configuration, I should be able to build it the same way, over and over again.
  


• Reproducible -- The corresponding Build (Configuration) should be reproducible: for any baselined configuration, I should be able to reproduce it whenever desired.
  


• Reportable -- The corresponding Build (Configuration) should be reportable: for any baselined configuration, I should be able to report all needed details about its content: what files & versions are in it, which changes/requests are in it, who made which change to what (& when), how it was built and with what tools & options, etc.


• Releasable -- The corresponding Build (Configuration) should be releasable: if I have "baselined" it, then almost by definition, it means it should be of 'releasable quality' to the next downstream consumer. (This implies it should be correct + consistent + complete to the extent agreed upon with the its stakeholders.)


• Repairable -- The corresponding Build (Configuration) should be readily repairable: if, for any reason, it is discovered to have some kind of problem, then I must be able to readily repair it either by retracting it and replacing it with it's predecessor, and/or by removing/repairing the offending content and releasing it as a new (corrected) baseline.

I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).

Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.

Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).

What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?

Here are all the other R-words I considered:

Recoverable Reliable Reversible Retractable Retainable Realizable Relocatable Remediable Repealable Replicable Revocable Relapsable Rebuildable Recapturable Reconfigurable Reconstitutable Reconstructible Recordable Recyclable Referable Retrievable Reusable Restorable Renewable Replaceable Representable Respectable Responsible Removable Reachable Readable Receivable Reclaimable Recognizable Recommendable Reconcilable Recreatable Remissible Rectifiable Recuperable Redeemable Reducible

If anyone cares, I looked it up at Dictionary.com searching for "r*ble"

The (hopefully) provocative title of today's blog-entry is inspired by Phil Armour's essay "Software is Not a Product!", which is one of many profoundly insightful essay's from his book The Laws of Software Process.

Armour maintains that:

The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product... The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).

Therefore:

Software is not a product, it is a medium for storing executable knowledge.

Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"—we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.

The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.

So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!

This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).

If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.

If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.

For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.

Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.

The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.

Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).

So there you have it:

Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.

What do you think?

The April issue of the CM Journal, and there is a FANTASTIC article in it by Austin Hastings about his Longacre Deployment Management strategy for dealing with database CM. It's long, but well worth the read for the insight into a new way of thinking about and doing CM of a database.

The April CM Basics issue has a companion/predecessor article a Case Study: Enterprise and Database CM the describes the initial problem, motivation and challenges that the LDM approach needed to solve. The LDM article goes into the gory technical details of the solution.

My paper in this month's issue of The CM Journal is about Lean-based Metrics for Agile CM Environments.

This month we take an "Agile" slant on metrics for CM, including the CM process itself. Agility is supposed to be people-centric and value-driven. So any metrics related to agility should, at least in theory, provide some indication of the performance & effectiveness of the value-delivery system, and how well it supports the people collaborating to produce that value. We borrow heavily from the concepts of Lean Production (and a little from the Theory of Constraints, a.k.a. TOC). Let's see where it takes us ....

Some readers will recognize some of the content from earlier blog-postings of mine on Codeline Flow, Availability and Throughput, Nested Synchronization and Harmonic Cadences and Feedback, Flow and Friction, but there is also a lot more content there too!

The folks over at SmartBear software have written a nice little book entitled The Best Kept Secrets of Code Reviews. It's free if you go over to their webpage and ask for it (you have to fill out a registration form, and it takes a few weeks to arrive, but they havent spammed me at all since I registered with them a few months ago).

This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]

SmartBear also has a pretty neat suite of tools that look to me like they would be REALLY USEFUL for an organization trying to streamline some of its otherwise heavyweight processes for peer-reviews and related quality metrics:

• CodeCollaborator - Automation for paperless peer code-reviews
  
• CodeReports - Continuous source code metrics over time.
  
• CodePickle - Suspend & resume code changes in local developer sandboxes (implements the PrivateVersions pattern without using version-control branches)
  
• CodeReviewer - automated peer-to-peer code reviews across remote sites
• CodeHistorian - Data-mining and visualizations for version control systems.

And "No!" they did not ask me to blog or say anything nice about them or their products! I'm simply coming from the perspective of someone in a large organization who has witnessed a lot of homegrown and heavyweight processes and tools for these kinds of things, and don't see too many commercial tools addressing the peer-review aspect of development and trying to make it lighter-weight and better-integrated with version-control and the rest of SCM.

The have some other nice resources too:

• Agile Peer Review: Methods, and Results (Powerpoint Presentation)
• The Case for Peer Code Review
• Brand New Information about Code Reviews
• 11 Best Practices for peer code review
• 2500 Reviews at Cisco® - The Largest Case Study of Code Review, Ever
• Why formal inspections fail
• Team-Building for the Cold, Dark, and Alone
• Compare 5 styles of review
• Pros & Cons of Four Types of Review
• Social effects of peer code review

Looks like a lot of "good stuff" to me!!!

Charles Betz' book Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children really ought to be required reading for anyone that fancies themselves a "CM professional" (especially Software CM) or an "Enterprise Architect."

I've been following his erp4it blog for over a year now (and his corresponding erp4it YahooGroup). Those looking for a taste of what the book is like can look there, and also at the paper ERP for IT which I understand was an early precursor for the book that has since been vastly updated and expanded in the latter.

Even though the subject of the book and the blog doesnt explicitly scream "CM", the content in the book and the blog are filled with often fundamental and profound insights about CM from the enterprise view (not just IT/ITIL) and where software CM, infrastructure CM, and network/element CM all fit in to the bigger enterprise picture. Several of his post that are among my favorites made their way into the book in some form or another:

• A Data Architecture for IT Service Management -- you'd never know it from the title, but this is practically a primer on what is a configuration and what is a configuration item (and much more)
  
• A Configuration Management Maturity Model
  
• Element versus Enterprise CM
  
• Two key distinctions to help scope your CMDB -- about the difference between Configuration Items and Events (quick - what's the difference between a "release" and a "baseline"?)
  
• Is CM a process?
  
• DBMS Configuration Management -- and the difference between Software CM, Element CM and Enterprise CM
  
• Model-Driven CM
• A Value-chain approach to IT
• A simplified ERP for IT architecture -- the CM system figures prominently in this one
• IT portfolios, service catalogs, and enterprise architecture -- change management (at all levels of scale - including governance) links them all together across the value-chain
• Fundamentals of integration metadata
• A story of too many tools
• A metadata rant
• CMDB Chaos and Confusion: Making Sense of the Madness

And if that weren't enough, the book also puts together three of my favorite topics: CM, patterns, and architecture.

Every January at CMCrossroads.com the CM Journal focuses on CM predictions for the coming year. My contribution for this year is Agile SCM January 2007 - Looking Back to Move Forward where I reflect on the previous two years' predictions and update them just a bit, with lots of emphasis on Rational Jazz and MS VSTS:

ALF and Corona? or Open-Sourced Jazz?
While there has been activity on the websites for the ALF and Corona projects, we havent been hearing so much about them in the media outside of Eclipse-centric conferences, and press-release announcements from yet another vendor with an Eclipse "compatible" release of their software. While this certainly doesn't shatter the prediction, there has been more attention (perhaps due to more marketing?) about the upcoming ALM collaboration framework from IBM Rational called "Jazz."

Based on the RDSC 2006 Day 2 Keynote presentation (and also at JavaOne), Jazz is touted as the next generation of the Eclipse platform and the team based software development platform. Rational will of course provide a tool-set to go with it, but says it plans to release the overall framework (and code/APIs) under Open-Source. The claim is that the result is an ALM collaboration architecture which is inherently scalable to provide true support for geographicall dispersed development projects in a true collaborative fashion. Well known names from Rational have been presenting Jazz at various conferences throughout 2006 and generating lots of "buzz," as evidenced by articles and blogs like the following:

• IBM is Revamping Rational
• IBM Jazzes Collaboration
• JavaOne 2006: Keynote on Agile Eclipse, Transparency, Honest, and Retrospective
• Rational Jazz Soon to Eat More of It's Own Dog-food: Transparency
• Jazz is the news
• IBM Jazzing up Rational Offerings, from InfoWorld
• IBM to employ open-source development style for tools, from eWeek
• Online Collaboration and Agile Software Development, from Dr. Dobbs Journal
• Big Jazz News on IBM developerWorks blogs
• Agile Requirements Engineering in the Jazz Collaborative Development Environment, from Rutgers 2006 Software Engineering day
• Hot Jazz vs. Cold Beans, blog-entry

Interestingly enough, with all that marketing buzz, Rational was also very clear about that fact that Jazz would not be released until after 2006. So look for even more "hype" and "hope" in 2007 when the first releases of Jazz become available, and especially when the core Jazz infrastructure is released as open-source under the auspices of Eclipse project. It will be interesting to see the impact this has on the Eclipse ALF and Corona projects (which Jazz doesn't currently use, althought it could conceivably make use of Corona in the future) and the Eclipse BIRT project (which Jazz does make use of). Current marketing would suggest that Jazz is the new vision, or more aptly, more likely, the new open-source hope to slay (or at least compete with) MS VSTS

The site founder, Patrick Egan, usually also initiates a discussion thread to engage the readership into the topic, and this year was no exception, as Patrick asked us What needs to change in CM and ALM for 2007. At the end Patrick added "How does CM fair in an increasingly Agile world?"

This sparked the perennial debate about "Agile CM" and whether or not it's any different from more traditional/mainstream CM. Folks wanting to read the whole thread are certainly welcome to do so. I'm going to excerpt what I think are some relevant thoughts from what I posted ...

My thoughts are much along the same lines as Frank's posting. I think we need to raise the level of abstraction of our thinking and problem solving. There are tools that do this, but the problem is that until the "lowest common denominator" tools catch-up, the majority of the state of the practice won't move too far past that (IMHO).

I do think its a good thing that two of lowest common denominator tools on the version-control side seem to be in the process of being supplanted with successors that go further in this direction (CVS -> Subversion, and VSS -> MS VSTS). I don't see as much on the change-tracking side, and integrations still aren't very integrated for the most part.

Regarding "an increasingly Agile world" ... as more and more shops and companies (and vendors) say they are "Agile", the more the term "Agile" becomes diluted and branded, and more of a marketing term than anything else. And that does do damage (as Joe mentioned); In fact it does the most damage to those that are doing it justice.

I do however think that the increased emphasis & visibility on frequent automated integration is a good thing, and that the trend of not only doing more of that, but using that as a mechanism of generating and reporting more (and more accurate) metrics is also a good thing. ...

The term "Agile" and the ideas behind it is no better or different from other "fads" like Object-Orientation or [software/design] Patterns. They had lots of hype and buzz, they had some legitimate improvements to contribute to the state of the practice (even if the ideas themselves weren't new - that's not necessary in order to have great impact/influence), and once everything was all "hyped out" they faded into the woodwork, as a natural, acknowledged, part of the fundamental knowledge we should use+apply everyday.

Increasingly, software CM implementations & deployments will need to better accommodate an increasingly Lean/Agile world (and it will be more important to know the difference between the pretenders and the real-thing). While I agree with Joe and others that the basic tenets of what CM is and what it is supposed to be don't change because of Agile, the fact remains that the norm for how CM is actually practiced and implemented in many shops will need to change.

Many tools/vendors are already headed in that direction, and have recognized the trend foretold by Thomas Friedman (The World is Flat), Peter Fingar (Extreme Competition) and others like Dan Pink, John Seely Brown, and more. With CollabNet, MS VSTS and Rational Jazz, the emphasis is on connecting and collaborating. And ways of doing software development and CM that fail to acknowledge that, and at least the first five of what Steve McConnell calls The Ten Most Important ideas in Software Engineering are going to have a tougher go of things than they have in the past.

As to whether or not "Agile CM" does (or will) exist, that will be determine by the people who end up actually doing it, and defining it. Anything claiming to be "Agile" will need to legitimately embrace the ideals of collaboration and the human element that Agile emphasizes, as well as at least the first 4 of the 10 ideas McConnell identifies. It will also need to embrace Lean principles and techniques. And if I get to have any part in shaping it, I think it should also include heaping helpings of Theory of Constraints (including Critical Chain) and Six-Sigma as they apply to CM and the "throughput" of change-flow, and change management.

All those things have something useful and important to offer us, and for those that can sift thru the hype and wannabees, there are huge gains to be had (whatever the trendy term end up being). I also agree with Bill Langston that there are some relevant standards (as well as "classic" ideas & methods) that are important to maintain, and which must "temper" the application of the newer and trendier (instead of always going back and forth between rigid and unyielding extremes).

Maybe it should be "Jeet Kune Do" CM instead of "Agile" CM :) Because we need to look at the new things and "keep what is useful" without abandoning the old so we can adapt and change as the speed of business and technology mandates.

Happy new year to all! I thought this would be appropriate for my first blog-entry in 2007 ...

Here are my top 10 blog-entries of 2006. This is based not on hit-counts, but rather on reference counts (number of mentions in other blog-posts, forums, articles, etc.) in some form or another. Note that there was a tie for the #10 spot.

1. Dimensions and Views of SCM Architecture
2. Scaling Agility: Summary of Resources
   
3. The Unchangeable Rules of Software Change
   
4. Agile SCM Principles: From OOD to TBD+CBV+POB
   
5. Trustworthy Transparency over Tiresome Traceability
   
6. Simple ain't Easy: Myths and Misunderstandings about Simplicity
   
7. Codeline Flow, Availability and Throughput
   
8. Impacts of Extreme Globalization and Extreme Competition
   
9. Agile vs MDE: XP, AMDD, FDD and Color Modeling
   
10. Nested Synchronization and Harmonic Cadences and Feedback, Flow and Friction
    

Some of the above surprises me. Some of it is close to what I was expecting ...

• I'm truly astonished at the #1 post - both because it was so recent and also because I'd seen very little indictaion of interest in my 4+2 views of SCM architecture (most folks probably just liked all the links that went along with it).
• The #2 and #3 entries don't surprise me, and I'm happy to see them there.
• I'm very surprised the "Simple Ain't Easy" post didnt rank much higher. I personally liked that one and my "Unchangeable Rules of Software Change" the most in 2006. And I saw so much discussion and mention of the "Simple Ain't Easy" post, I honestly expected it to be the #1.
• I am surprised by the ranking of the posts on codeline flow & throughput, and nested synchronization & harmonic cadences. I had the impression that struck most folks as rather esoteric.
  

For anyone interested in what the next ten most popular ones were ... here they are:

11. Business Agility Defined
    
12. Extreme Traceability
    
13. Nutshell Definitions of Agile Development
    
14. 5Cs of Agile SCM
    
15. Cost, Cruft and Constraints
    
16. Pragmatic Multi-Variant Management
    
17. Agile IT Organization Refactoring
    
18. Trends in SCM Predictions for 2006
    
19. Everyone Wants to be LUVed
    
20. Lean Principles for Branching
    

Here's hoping I can do as well or better in 2007!

In my last blog-entry I wondered if the interface segregation principle (ISP) translated into something about baselines/configuration, or codelines, or workspaces, or build-management. Then I asked if it might possibly relate to all them,

Here's a somewhat scary thought (or "cool" depending on your perspective), what if the majority of Robert Martin's (Uncle Bob's) Principles of OOD each have a sensible, but different "translation" for each of the architectural views in my 4+2 Views Model of SCM/ALM Solution Architecture? (See the figure below for a quick visual refresher.)




Thus far, the SCM principles I've "mapped" from the object-oriented domain revolve around baselines and configurations, tho I did have one foray into codeline packaging. What if each "view" defined a handful of object-types that we want to minimize and manage dependencies for? And what if those principles manifested themselves differently in each of the different SCM/ALM subdomains of:

• change control (project-view)
  
• version control (evolution view)
  
• artifact (requirements, models, code, tests, docs) hierarchy and build management (product view)
  
• workspace/repository/site management and application integration & synchronization (environment view)
  
• workflow and process design (process view)
• teaming, inter-group coordination and interfaces/expectations (organization view)

What might the principles translate into in each of those views, and how would the interplay between those principles give rise to the patterns already captured today regarding recurring best-practices for the use of baselines, codelines, workspaces, repositories, sites, change requests & tasks, etc.

The current issue of Communications of the ACM is focused on Software Product-Lines for software engineering. It has a number of interesting articles on software product-lines and product-families for large-scale reuse.

It even has a few articles related to CM of product-lines, particularly change-management and variability-management:

• Feature-oriented variability management in product line engineering
  Jaejoon Lee, Dirk Muthig


• Multi-level customization in application engineering
  Krzysztof Czarnecki, Michal Antkiewicz, Chang Hwan Peter Kim


• Product management for software product lines: an unsolved problem?
  Andreas Helferich, Klaus Schmid, Georg Herzwurm


• Change management patterns in software product lines
  Kannan Mohan, Balasubramaniam Ramesh