Planet SCM

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)

The November issue of The Rational Edge has three articles that are closely related to my ideas about applying what we know about software & enterprise "architecture" to the domain of SCM/ALM solutions (and another article about an SCM tool vendor "eating their own dogfood"):

• UML, RUP, and the Zachman Framework: Better together, by Vitalie Temnenco
• The four dimensions of system models, by Fredrik Ferm
• A RUP-based approach to developing a data warehouse, by Scott Ambler
• Change Management at IBM Rational: How those who develop ClearQuest use the product, by Robert Pierce

[Also see some interesting articles on Requirements Engineering in the December 2006 issue of Crosstalk]

Some of you may recall my 4+2 Model Views of SCM Solution Architecture. I've since updated the picture a bit as follows (which Ive now updated over there too), click on the small image below to see a much larger one:



Anyway - reading through the above articles (particularly the one on model "dimensions" and the one on UML+RUP+Zachman together) gave me some more thoughts about my 4+2 views model, such as:

• I have "scale & diversity" as a dimension of "concerns" that bridge all views. I wonder if that corresponds to the "scale" or "level" dimension referred to the in article on dimensions of system models?


• I also have change/creation time, and decision binding time as a "dimension" of concerns. It's not explained real well though. I suppose it corresponds to considering both a "static" and "dynamic" perspective for each view. In a sense there are lifecycles (e.g., promotion cycles) for the elements in each view, as well as important times when decisions are committed to, and/or when artifacts or changes are made. When dealing with variation (diversity) across a product or system, the binding-time employed by the solution can be of great importance.


• By adding a +2 view to RUP/Kruchten's original 4+1, I end up with something that sort of maps to the 6 columns of the Zachman model. Does this mean my 4+2views are really a subset of Enterprise Architecture (EA), or might it mean that its some kind of "bridge" between the two?


• Does it really make sense for me to have Organization and data combined into a single view, or is Data really a separate view (a +3 view?), or should I not go so far as to equate metrics, queries and reports with "Data", but rather as the requirements for data (and hence the possible "bridge" mentioned above)?


• What if I compare contrast my 4+2 views with the model or views put forth by any of ITIL, RUP-SE, DODAF, TOGAF, FEAF, or others (see below)? What value does mine add that warrants being its own "thing" instead of just some poor sawed-off wannabe clone of one of the others?

• The new, improved RUP SE architecture framework
• An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 1: Operational view
• An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 2: Systems view
• Estimation variance and governance
• Rational Unified Process for Systems Engineering -- Part I: Introducing RUP SE Version 2.0, August 2003
• Rational Unified Process for Systems Engineering -- Part II: System Architecture, September 2003
• Rational Unified Process for Systems Engineering -- Part III: Requirements Analysis and Design, October 2003
• "How does RUP SE apply to a system of systems?"
• "Leading modern systems development"
• "Thoughts on Functional Decomposition"
• "Organizing RUP SE projects"
• Development of Federal Enterprise Architecture Framework using the Rational Unified Process and the UML
• Introducing The Open Group Architecture Framework (TOGAF), Part 1: Understand TOGAF and IT architecture in today's world
• Introducing The Open Group Architecture Framework (TOGAF), Part 2: Explore an industry standard for defining an enterprise architecture
• Introducing The Open Group Architecture Framework (TOGAF), Part 3: Create an enterprise architecture with TOGAF
• developerWorks : Architecture : New to 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)

Back in May of this year I blogged about how Simple ain't Easy: Myths and Misunderstanding about Simplicity. That entry ended up being quite popular and very well received.

This month, a streamlined version of that entry is the featured article in the "Last Word" column for the November 2006 issue of Better Software magazine. The writing is a bit more compact, though I did end up having to trim a few thoughts I had really wanted to keep. The quotations and links from the original entry didn't make it into the article, but were instead made part of the online "Sticky Notes" for the November issue.

For those with access to the printed magazine who have a chance to read both the article and the blog-entry, I'd appreciate your feedback as to whether you like the article better, or the blog-entry better, and why.