Sunday, November 05, 2006

Practical Use of the Zachman Framework For Organizing Information System Requirements: Part 3 - Matrices

Finishing off my Row 2 artifacts, one thing that came out was that list of 40 to 50 candidate Use Cases. For my business audience, I have started calling them System Use Cases, so there was no ambiguity; these are the required ways to be able to use a solution/system. So, I think I have decided that these are row 3 artifacts, but they also remain in the People/Who column.

Having this list leads to my first cross-reference matrix, ‘User Role’ to ‘System Use Case’; this will be very handy in illustrating who can do what, and just as importantly, who can’t do what.
I am also finding it useful to xref the System Use Cases to the lowest levels of the Functional Decomposition, as mentioned and discussed in my earlier post. I am not sure yet what else the decomposition brings to the overall requirements; certainly many past methodologies used decompositions to get to the lowest level definition of functionality, and after that the higher levels were not used any further in the Requirements.

Another small but illustrative cross-reference is “User Role” to “Location”; from this, one can derive what System Use Cases would be performed at a Location. This is going to help going forward as it is already expected that the new system will be used at more locations than the current systems. This may also include defining some new User Roles as well, which will then drive the questions: “Which System Use Cases will this new User Role need to use? Do they need new System Use Cases?”

For my own satisfaction, I also worked out the classic “Data Entity” cross-referenced to “Function” (Use Case, really), and then manually performed Affinity Analysis to see if any different ‘subject areas’ were revealed. Since the business scope is really about one major entity, a Credit Application, the analysis essentially confirmed that. However, it also organized the functions around the its dependent entity types as well, so one can see how these groupings could possibly lead to de-coupled definitions of sub-systems or components… but that’s for the Developer/Architect to surmise!

And so… that is pretty much where I stopped in creating draft requirement artifacts before heading into requirements sessions with the business. Overlapping with the beginning of those sessions, I did consider what other Row 3 artifacts still might come into play in creating an overall requirements definition.

My current thoughts on Row 3 have been greatly influenced by having recently read “Requirements Analysis: From Business Views to Architecture”, by David C. Hay (Prentice-Hall, 2003). This book does two main things (and some others, too) that helped me:A) It reviewed that past 50 years or so of methodologies and artifacts, and categorizes the artifacts by Zachman Cell; even without that categorization, this is a great piece of IS history that I have seen nowhere else, thank-you Mr. Hay.B) It re-focuses Row 3 from the Designer View to the Architect’s view, and within that classifies Row 2 artifacts as ‘Divergent Models’ and Row 3 artifacts as ‘Convergent Models’, which I found powerful.

The best example of (B) is in the Data Column: your Row 2 model may have entities for Customers, Suppliers, Staff, and the like. Given that, your Row 3 model would be based on a Party/Relationship Model, where all the participants in the business (and new ones when they are defined) are supported by one common, flexible data model, and the data structures you would create from that model. Some call these meta-models, but I avoid the term with business people for the most part. So, the other columns may also have such convergent artifacts, such as Workflow models for the Function column, and Business Rule Models for the Motivation column.
I have still been working on these Row 3 artifacts as I have also been gathering mainly Row 2 level information during Requirements sessions with the business. So, my next blog entries on this will be about what happened in those sessions. It might be a while before I get to posting those, but they will come…


alireza said...

your posts are really practical and quite interesting.
I'm newbie in Enterprise Architecture and Zachman framework.But some ambiguities arised when i follow your comments.
As you said,the Zachman doesn't offer any specific models.But it can make work harder because 36 cells needs 36 models how you can aware of whether your are going to make right model for right cell?!Moreover,I got from your comment that you you are going to choose your diagrams in terms of your audience(e.g. boss,employee)it seems a little bit strange for me.

I'm looking forward to reading your next posts.

David Wright said...

Hey, thanks for reading. I actually have started blogging at the Requirements Networking Group

and at ITtoolbox

so I may shut this one down soon.

"36 cells needs 36 models". Actually , the lower rows are not inhabitated by models, they move through designs, code and eventually the executable systems in row 6.

"choose your diagrams in terms of your audience": Yes, especially if you have several to choose from. The modesl and diagrams are used for communication, not just documentation for its own sake, so you have to use a medium that your audience will accept and be willing to try to understand it.

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.