Configurations, Streams and Control
At CMCrossroads I wrote that configuration management needs three things, which is explained in more detail by Brad Appleton.
In a reaction Robert Cowham wonders what a component is and what a stream is. From a scientific point of view we may need unambiguous definitions before we start reasoning about them, but as a practitioner I rather use fuzziness to create a common understanding and interpretation first. Afterall, we are not writing lawbooks here, nor scientific dissertations.
- Configurations, being the current content of a workspace. It may be complete or incomplete, but it contains everything the developer needs to work on or work with.
- Streams, to evolve configurations from their current state to a new state closer to the final state (the product release state)
- Control mechanisms to assure that the configurations evolve toward the goal in an efficient and effective way.
The 4+2 view of SCM principles as explained by Brad Appleton contains 6 different views:
- Project
- Environment
- Product
- Evolution
- Process
- Organization
- Static instances (i.e. physical reality),
- Dynamic interactions between these instances (i.e. birth, life, growth and death) and
- Rules (i.e. laws of nature, traditions) to which the instances and interactions must obey.
Let's assume that a development project is a single goal: a product that satisfies a particular set of requirements for a particular set of stakeholders. Or in more practical terms, a set of executables and manuals for the customer, and a set of source code, models and development documents for the development organization (for further development and maintenance). So the final configuration (static instance) is known. And suppose the project is starting from scratch, so the initial configuration is also known, you might think...
Wrong! The "initial" configuration does not contain a assets (static instances) to perform action (dynamics). We need to hire developers, acquire computers, install and configure the tools, set up and fill databases with our so-called "initial configuration", set up the organization of the project (roles, responsibilities, agreements, commitments), etcetera. Only then, the configuration is filled with everything a developer needs to work on or to work with, which makes the initial configuration. Yet, the initial configuration still is a set of static instances.
Then the teams start working. Basically, all they do is taking a configuration and transforming it in another configuration. If we consider a configuration a "point in time and space", then the continuous evolution of configurations as a "line in time and space", which we call a stream. Conceptually, each team or even each individual within a team (or project) has a separate set of streams, where at any moment in time a stream can be split (i.e. two actions on the same configuration resulting in two new configurations) or joined (i.e. an action is performed on two configurations resulting in one new configuration).
If this happens completely organically, following the rules of reality to perform the dynamics, without any level of control, it is likely that a Darwinistic evolution takes place where is it unpredictable when and whether any configuration comes anywhere close to the project goal within a reasonable time. Very likely, psychological and sociological rules will dominate economic and business rules.
So we need a form of control to assure that a (final) configuration matches the project goal. Typically, there are two dimentions to control from a configuration management perspective: content and quality. By combining them into a single attribute, we come to value. A rule of nature is that a stronger species survives a weaker species. For configuration management, we can translate this in: a configuration of a higher value survives a configuration of a lower value.
To take this more in a practice way, we can say that a team (or an individual) that is degrading the product, the environment, the organization or any other of the 4+2 views, then the resulting configuration should be rejected by configuration management. Of course, project management would be wise to not even allow a team to spend time and effort on a degrading activity, but sometimes (for example, when prototyping to determine added value in an empirical way) a team result may produce a degraded configuration compared to what they started with.
Another example of a degraded (lower value) configuration may occur when two teams create a new configuration of a higher value than their initial configuration (which makes both configurations acceptable for configuration management), but joining results in some many issues that the joined configuration is of lesser value than the initial configuration. In that case, we have the option of accepting one of the configurations and reject the other one (in spite of its added value), or work on the degraded (joined) configuration to created enough added value so that the overall value is higher than the initial configuration.
The mechanisms of controlling configurations and streams in a strategic manner is what makes configuration management an interesting profession. This way branching strategies, workflow strategies, integration strategies, etcetera are born.
Technorati tags: SCM, Software Development
3 comments:
Very nice Frank!
I am going to think about this and will probably post on CMCrossroads as a result.
Very interesting Frank! I actually read this when you first posted it, and was intending to comment but had put it off until now.
First a correction, the 4+2 views model that I proposed was a set of views of an overall SCM/ALM Solution Architecture. In my search for a relationship between OOD Principles and SCM Principles I had initially thought each one applied to at most one of my various 4+2 views. In the blog-entry you cited, I was wondering if perhaps each might apply to ALL of the views, but might manifest itself in each view as a different principle.
Despite the title of that blog-entry however, I wasnt meaning to suggest the views were of SCM principles, they were always intended to be of SCM/ALM solution architecture - I merely wondered if looking at the OOD principles from each view might reveal different principles rather than all the same ones all over again.
Second, I'm intrigued by your notion of preserving or degrading "value" from the perspective of any one of these 4+2 views. I remember in an Oct 2005 posting on the scm-patterns list, in response to one of my scm-principles proposals, you had counter-proposed a so called value promotion principle (or maybe it was an earned-value principle, or maybe it was both).
Is this particular blog-entry of yours taking this principle and trying to apply it to all of the 4+2 views, or is it something different? (something less? something more? a corollary perhaps?)
I understand that the 4+2 model comes from a different area and I think it helps to understand SCM better. Your attempts to define SCM principles definitely help too!
In this blog, I try explore my thoughts about SCM. I try to step out of the box, and I typically do this by questioning the validity of what we have achieved so far. So I don't mean to speak more (or less) about the 4+2 model, just see where my thoughts bring me.
I had my hopes on "ever increasing value" principle (earned-value principle) as an invariant for the development cycle. It seems not strong enough, yet I still like the idea.
My problem with understanding the 4+2 model, OOD principles and SCM principles is that it's too complicated for me. It's probably just me...
Post a Comment