SCM Plan or SCM Architecture?

In an earlier blog-entry I described a 4+2 Model View of SCM Solution Architecture.

Much has been written about what a CM Plan should be. If an SCM Solution is really a work of "architecture", then wouldn't an SCM Plan would actually correspond to an (initial) architectural description or "blueprint" for an SCM solution? It would have not only descriptive text, but should show models/diagrams sketching the overall strategy for each of the various 4+2 Model Views, showing the key entities and their interrelationships and dependencies.

If Martin Fowler is correct about Software Architecture as an "emergent property" (see "Is Design Dead?"), then an "Agile" SCM solution should also have emergent properties. Granted there still needs to be some amount of up-front planning and design, but some of that should also be concerned with "emergence" and how to let the architecture be adaptable, extensible, and resilient in the face of change.

And if Josh Kerievsky is correct about Refactoring to Patterns (Josh's book won the 2005 Jolt Productivity award in its category), then it should also follow that many of the SCM Patterns are simply recognition of an SCM anti-pattern that violates one or more SCM Principles, and applies an SCM refactoring to resolve the imbalance. Other SCM Patterns would be about how to successfully grow and extend a simple SCM solution whose requirements become more complex in the face of increasing scale and diversity in any or all of the 4+2 model views.

This raises some interesting (to me at least) questions:

• Would you agree that an SCM Plan is really the initial overview or blueprint of an overall "architectural description" for your SCM solution?
• In what ways do you think such an architecture can and should be "emergent?"
• In what ways shouldn't it be emergent? (What and How much really needs to be planned and designed "up-front" versus emerging later "on demand"?)

The Principles of SCM

I think many of the principles of good system/software design apply to the design of an "SCM Solution Architecture". In particular, I think many principles of sound Object-Oriented Design (OOD) are applicable since a lot of OOD deals with managing and minimizing dependencies through the use of techniques and mechanisms like: encapsulation, abstraction, information hiding, modularity, composition, delegation, inheritance, and polymorphism.

One set of fairly well known OOD Principles was written by Robert Martin in 1996-1997 as part of a series of articles in "The C++ Report". (See the ObjectMentor webpage for their OOD Principles training course -- halfway thru the page it has an "articles" section with links to copies of the original articles that appeared in the C++ Report.)

These Principles of OOD were also in his 1995 book "Designing O-O Applications Using the Booch Method". Then Robert started evolving and developing them more, and also working with patterns, and then eventually extreme programming practices. And what was going to be a 2nd edition of the book instead became a 10 year "project" that combined these principles, with patterns, and agile development "practices" into a new book that came out in November 2002 called "Agile Software Development: Principles, Patterns, and Practices"

These "Principles of OOD" are ...

Principles of Class Design:

• (OCP) The Open-Closed Principle
  
• (LSP) The Liskov Substitution Principle
  
• (DIP) The Dependency Inversion Principle
  
• (ISP) The Interface Segregation Principle

Principles of Package Cohesion:

• (REP) The Reuse/Release Equivalency Principle
  
• (CCP) The Common Closure Principle
  
• (CRP) The Common Reuse Principle

Principles of Package Coupling:

• (ADP) The Acyclic Dependencies Principle
  
• (SDP) The Stable Dependencies Principle
  
• (SAP) The Stable Abstraction Principle

Maybe it would be the case that, when "translated" into SCM concepts and terms ...

• Class design principles would translate into baseline and/or configuration derivation and composition principles?
• Package cohesion principles would translate into change-task and/or change-set cohesion principles?
  
• Package coupling principles would translate into codeline and/or variant management principles?

And these would give me guidance on things like ...

• How small or fine-grained should my change-tasks minimally be?
• When & how often should I commit and/or promote new baselines?
• How should baselines relate to other baselines and codelines?
• How should codelines relate to other baselines and codelines?
• How should I manage dependencies between changes/branches/codelines?

These guidelines would (ideally) manifest themselves as various "SCM patterns" for a given problem and context. Each "problem" would correspond to a situation that is a potential violation of one or more principles (anti-pattern), and the pattern solution would figure out which principles are being bent or broken and how to resolve that without bending or breaking one of the other principles too much as a result.

What do you think are some of the principles of Software CM?

Traceable + Transparent = Trustable?

After some more reflection ... I think Ive changed my mind regarding someting I wrote about Traceability and TRUST-ability:

Traceabilityis a means of providing transparency while facilitating impact-analysis, conformance, compliance, accountability, reproducibility and learning. I stopped short of including transparency as one of the goals because I guess Ive seen it fall far short of that too many times. I think that if done well, transparency is an effect of traceability. And at the same time I think Ive seen enough examples of people managing to achieve those other goals without being terribly transparent, that as much as I wanted to include transparency and as an overarching goal of traceability, I just couldn't do it!

I think Joe Farah's response in the "Why Traceability" discussion thread on CMCrossroads was right on target. Transparency is supposed to be a by-product of traceability, if its done "right." It's not a "goal" the same way that facilitating impact-analysis, conformance, compliance, accountability, reproducibility and learning are goals. Achieving transparency in each of those areas is what facilitates those goals:

• Architectural (structural) transparency facilitates impacts analysis
• Functional (behavioral) transparency facilitates product conformance
• Process (procedural) transparency facilitates process compliance
• Project (managerial) transparency facilitates project accountability
• Build/Baseline (physical) transparency facilitates reproducibility
• Decision-making (logical) transparency facilitates organizational learning and root-cause analysis

If my attempt at traceability (including the kind mandated by Sarbanes-Oxley) didnt achieve transparency, then I'll go so far as to say it wasnt done "right" or it wasnt done effectively. Traceability may not imply trustability, but traceability done "right" should achieve transparency, and it is transparency that engenders trust by visibly giving an open, honest, accurate and forthcoming accounting of decision-making and work-efforts.

So how can I do that without creating so much additional manual maintenance and administration as to become insurmountable and/or unwieldy? How do others feel they have achieved this?

A 4+2 Model View of SCM Solution Architecture

My interests in CM, architecture, and agility all overlap in my day-to-day work. I think the convergence is in developing what I call an "SCM Solution Architecture". Some might regard it as the SCM "component" of an overall Enterprise Architecture that includes SCM. I believe many of the principles, patterns, and practices of system architecture and software architecture apply to such an SCM solution architecture.

If we take the 4+1views approach of Rational's Unified Process (RUP), which defines the critical architectural stakeholder "views" as: logical, physical (implementation), processing (processing & parallelism), deployment, and use-cases/scenarios, and if we enhance those with one more view, that of the organization itself, then we arrive at a Zachman-like set of RUP-compatible views for an SCM solution architecture that I call a "4+2" Model View of SCM Solution Architecture.

The "4+2" Model View of SCM Solution Architecture contains 6 different views, that I characterize as follows:

• 1. Project {Logical Change/Request Mgmt} -- e.g., change-requests, change-tasks, other CM "domain" abstractions and their inter-relationships, etc.)



• 2. Environment {Solution Deployment Environment} -- e.g., repositories, servers/networks, workspaces, application integration



• 3. Product {Physical/Implementation/Build} -- e.g., repository structure and organization, build-management scheme and structure/organization



• 4. Evolution {Change-Flow and Parallelism} -- e.g., tasks, codelines, branching and merging/propagation, labeling/tagging



• +1. Process {Contextual Scenarios/Use-cases} -- e.g., workflow, work processes, procedures and practices



• +2. Organization {Social/People Structures} -- e.g., organizational structure for CCBs, work-groups, sites, and their interactions, and corresponding organizational metrics/reports for accounting and tracing back to the value-chain. (Mario Moreira's "SCM Implementation" book has a great chapter or two on the importance of this and some best-practices for it)

The fact that many of the views closely align with RUP suggest that UML might be a very suitable diagramming notation for modeling such an architecture. And I think that much of the current best-practices of enterprise architecture, agility, object-oriented design principles, and service-oriented architectures apply to the creation of an agile CM environment that represents such a solution architecture.