- 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?
Anyways, these questiosn made me want to go look-up some of these other models and views. I found some pretty good online articles for some of them (I'm sure I missed a few as well). Here they are:
- 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
I welcome feedback/comments on any of my thoughts above!
2 comments:
I honestly think that your really on to something here. Unfortunately, it hasn't crystalized yet. I'm thinking that you need to juggle around that 4+2 views a bit to better align w/ rup.
I would start w/ project at the center.
Logical View == Evolution
Process View == Process
Impl View == Environ
Deployment View == Product
just a thought.
Hi Carlos! Thanks for feedback.
I thought I had shown how my 4+2 was derived from 4+1 back in my my April 5, 2005 blog-entry. But on second look, it appears I didn't. I did in fact initially derive my 4+2 views from the 4+1 views that RUP uses, as follows:
* The RUP Logical View corresponds to my Project View: It is concerned with the entities and relationships of everything that is tracked: change-requests, change-tasks, changes, the changed-elements, the versions and projects they are all targeted to, etc.
* The RUP Implementation View corresponds to my Product View: it deals with all the the elements and artifacts that we create & update to capture knowledge in the form of requirements, models, code, tests, etc.
* The RUP Deployment View corresponds to my Environment View: it deals with the deployment architecture of databases, repositories, applications, and clients/servers/peers that our SCM solution is deployed upon.
* The RUP Process View corresponds to my Evolution View: rather than addressing issues of concurrent, parallel, and distributed processing among computational elements (RUP), it addresses issues of concurrent, parallel, and distributed development among people and teams.
* The RUP Use-Case View (+1), corresponds to my Process View: rather than scenarios for using a software system they are the process/procedures/practices for using the SCM solution.
My Organization View does not originate from the 4+1 Model of RUP. It arose from my own experience. The SCM solution has to be driven by communication structures among people and teams that define how CM-related entities interact and govern themselves (and how they use metrics & reports to do it).
To see how I derived my first 5 views from the 4+1 model, think of it this way ... supposing I viewed an SCM "solution" (one that encompasses people + process + tools/technology) as if the entire thing were one big software development project (where perhaps some of the code is instructions to be executed by a network of machine in a target environment, and some of it is "instructions" to be executed by a network of people in a target organization).
In this case, the 4+1 views end-up as follows:
* The "Logical View" is the class/object model of all the interesting objects in the system that I may need to track or manage
* The Process view still deals with concurrency, distribution and parallelism, but of the users of the SCM solution
* The "Implementation View" is pretty much unchanged ... it is still the set of artifacts and entities created that store knowledge in the form of requirements, models, code and tests, but of the software projects that are supported by the SCM solution.
* The "Deployment View" is still the deployed operating environment (but I eventually felt that "people" and social structures are important enough and different enough from computing elements and infrastructure as to warrant their own separate view :)
I didnt have an "Organization" view when I first proposed this on a few mailing lists back in 1997 (like the OTUG list hosted by Rational at the time). I added it about 5 years later after some hard experience made me realize it's an important dimension in its own right that can dictate across many of the others. After I added that, I realized I sort of had a match to the "who, what, when, where, why & how" columns of the Zachman model (albeit a very loose match in some cases).
Hope that helps! Thanks for making me write that down!
Post a Comment