Row 2
The Zachman Framework is notable first for being just that, a framework for different approaches to use to organize their artifacts; further, some writers have customized the framework to rename some of the rows/views. Despite this, Row 2 is still mainly about the Business specifics, be it the Business Model (conceptual view), or the Business Owner’s View. I am going to use the original “Business Model” terminology for Row 2, but may diverge when I get to Row 3…
As I write this part of my article, I have finished using all my source documents to flesh out a Business Model that I can take into requirements sessions with business staff and various subject matter experts. Those will be taking place shortly, so I expect to add to this article after the sessions, to document the experience and analyze for myself how much variance exists between my draft Model and the Model after the sessions.
Let us start with each cell in the row again, but after that, I also have some column-to-column cross-reference matrices that I expect to help me in actual analysis and validation of the Model as a set of Requirements.
Row 2 (Business Model) and Column 1 (Data / “What”):
The scope of this project is a major process of the company, one of five that have been defined. So, what I found is that the 14 things of interest I defined in Row 1 were not Subject Areas with many entities to discover; the business process is mainly concerned with the life-cycle of one core entity type and its dependent entities. At this point, I think I can identify that this core ‘thing’ is a Credit Application without revealing any proprietary information. The rest of the 14 mainly equate to single entity types as well, which fall into the following three categories:
o Entities for data that exists for the process to use but does not maintain, such as Product data,
o Entities for data that are dependent on the Credit Application, like the items/assets being financed (although these may turn out to be independent entities from a wider enterprise perspective),
o and Entities for data that is created by the Process that is used downstream in the business, like contract and account data.
Further, just applying 1st normal form would drive out a few more entity types, but I don’t think this is absolutely necessary in row 2, especially depending on your business audiences comfort level with ER diagrams. The business participants at my company are, as I have described, very comfortable with process flow models from six sigma process improvement efforts, but data models are unknown, and my previous use of them in smaller projects has been met with indifference. As a result, I expect to use an alphabetical list of entity types, with list of attributes for each one, all in business terms; relationships will have to be covered as statements, but business rule formats can help that (see column six).
I do have a lot of attributes already, given the detail in the process maps, current systems, and those previous data models. I have not started to define the attributes yet, many definitions already exist in current systems and glossaries, but I do plan to build a Glossary of Terms for this project in the sessions as needed, especially to document aliases, and resolve different uses of a term.
Row 2 (Business Model) and Column 2 (Function/ ‘How’):
The existing process maps relate to the six ‘boxes’ of the High-Level Process Map almost 1 to 1; however, they are several layers more detailed, each map having 40 to 60 steps, many decision points (diamonds) and dependence on use, and limitations, of existing systems. At this level, process maps are too detailed and too volatile to be useful information system requirements, so I tracked back to the six ‘boxes’ and started a functional decomposition. Groupings of process steps coalesce into more stable functions, and I derived a small functional hierarchy, no deeper than three levels, with about 20 root-level functions. At the same time, some of the process steps look like candidate use cases… or lowest-level CRUD functions.
Here I return to my previous thoughts that Column 2 has the most artifact choices, and I have been looking at process maps, a functional decomposition, and use cases… but looking ahead to column 4, some say that use cases are a Role/User artifact, and maybe they are Row 3(?). Perhaps those are the ‘concrete’ use cases as defined by RUP, but RUP also supports conceptual use cases for analysis of a domain before design. I do expect that I will end up with use cases as part of the Requirements, if only because they are a common artifact that my business users have seen in earlier projects, but at this point in the project it will may actually be a list of use case names and short descriptions; detailing them would come later after selecting the solution approach.
Use Cases can be considered as artifacts that span columns, as they (at least) document roles through Actors, and system activity. Again, the Framework does not dictate artifacts, so it is up to the analyst to categorize artifacts into the framework in the way that works best for capturing the business model, and then communicating the model as well. It is interesting that if one does categorize use cases as column 4 artifacts, I can see how it is useful to cross-reference them back to the root functions of the decomposition in Column 2.
Row 2 (Business Model) and Column 3 (Network / ‘Where’):
This cell is very skimpy at this point for my project. Is it because the ‘network’ is ubiquitous? Maybe, but the one thing one can highlight here is that the various locations communicate in multiple ways that might fall within the scope of an information system to manage.
This starts with good old snail-mail, and its rabbit cousins, the various express couriers. Even in the latter, the recording media is paper, which has not gone away; the ‘computer network’ as most perceive it does not assist with this communication (unless you count checking the status of your delivery at a courier company’s website).
A close parallel is, of course, the fax machine, which has been with us since the 1930’s. Again, a business’s own network requirements will probably still assume the perceivable separate existence of a voice network which can transmit faxes.
(Here’s my tech question of the moment; is anyone using VOIP to send faxes, presumably to take that cost off the long distance bill?)
… but what if paper documents are scanned to create PDF files? That can then be sent by email, or uploaded/downloaded inside a company’s VPN using Portals, and all that? Does that unstructured data file need to be managed by the business’s information system(s)? That’s one question I will be asking in this project, along with older-style imaging and document management. I can see how the requirements emerging from these topics will end up back in column 1, since not all data of interest to the business can be recorded as zeroes and ones.
That leaves email (in general) and voice communications between people at different locations, or within one location as well. I have already seen newer transaction systems being augmented by management of emails related to a transaction, especially in systems where transactions are generated by a field sales force and sent to a head office for completion. As for voice communications, we are all familiar with the phrase “your call may be recorded for training or other purposes”, which will be managed by customer call centre systems. Will recording and management of phone calls move beyond the call centre, and be part of transaction systems? I can’t see why not.
As I move into the requirements sessions with the business for my project at hand, I do already know that fax is still expected to be a primary means of communicating between any and all locations; everyone we do business with, within or beyond arms-length, will accept a fax and has a process for dealing with them when they arrive; that still can’t be said for email even at this state of its maturity.
Row 2 (Business Model) and Column 4 (People/Roles, or ‘Who’):
At this point, I think the Roles I had in Row 1 probably belong in this cell, with an overall Org Chart in the Row 1 cell; or, Use Cases are a Row 2 artifact. I am not overly concerned with the specific Rows, right now, only that I have the Roles that are going to be Actors in Use Cases. Again, maybe a list of candidate Use Cases is something to gather at this level, and they do appear to match to system-related steps in the Process Models.
Row 2 (Business Model) and Column 5 (Time, or ‘When’):
In this cell, I have looked at Entity Type Life-Cycles as the time view on key data. In this process, there is the one major entity type, Credit Application. The basic states are ‘submitted’, followed by ‘approved’ or ‘declined’, with a few other states mixed in for control.
Row 2 (Business Model) and Column 6 (Motivation, or ‘Why’):
As mentioned before, I already have collected a set of company policies, from which I can derive specific Business Rules. It was a this point that I dug out some previous R&D work I did on Business Rules a few years ago, with many of the Rules being related to this project’s business process. Again I am wondering, are the Rules a row 2 or row 3 artifact? I think this will resolve itself as I examine Row 3 completely.
Next, Row 3? Or Cross-Reference Matrices?
Row 3 on the Framework is noted to be a Designer’s view, but I have also seen some writers show Requirements artifacts in Row 3 of some columns, so I expect to look more at Row 3 next time, including the issue if whether Row 3 is simply a translation of Row 2, or if it the move from 2 to 3 involves some transformation as well.
I also have some of those matrices coming along, will have to see how to describe those in blog format…
