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"?)
No comments:
Post a Comment