Practical Use of the Zachman Framework For Organizing Information System Requirements ... Part 1 - Scope (cont.)

...continuing from previous post.

That is just how I started, either gathering or copying existing content as needed. My main source was the Six Sigma process models, which in themselves can be a row a Two Process Artifact. They also typically show Roles, Items of Interest, Inputs , Deliverables and more, so populating the other columns can be started from these maps.

So, lets begin with…
Row 1 (Scope) and Column 1 (Data, although some writers prefer ‘What”)
I now have a ‘List of Things that are Important to the Enterprise.” It contains 14 items which, as expected contain items such as Customers and Products, and other things more specific to the in-scope process of the Enterprise. A data modeler would certainly look at this list and suggest they are all major Subject Areas of the Business, from which data models may be detailed. (I am going to be purposely vague about the specifics of the process, as I in no way wish to describe proprietary and private aspects of the company.)

Row 1 (Scope) and Column 2 (Function, or generalized to ‘Activity’, along with ‘How’ to align with ‘What’ above ):
This cell, and the rest below it in this column, are prime examples of one of the main concepts of the Zachman Framework; it organizes your artifacts by resource and perspective, but does not dictate the artifacts to use. Back in Column 1, the ER Data Model is pretty much the default, irrespective of some people still trying to use UML for persistent data requirements. Here in Column 2, there is some variety of choice, so you have to choose an artifact. A company may already have a standard, usually within a Methodology. I am finding you may need more than one to capture all aspects of ‘Activity’.

For my Feasibility Study, I have located a high-level Process Map that was used in a similar project in another country (my employer is a unit of a multi-national). It is six sequential boxes. In that sense, the boxes could also be the first level of a Functional Decomposition, so I have not decided yet which kind of artifact it is(!). In any case, the existing detail Process Maps can be cross-referenced fairly directly to these boxes/ functions, which will help greatly in subsequent rows.

Further, I have indications at this point that the Business Process Scope includes or interacts with Processes located at other sites or performed by other parties, e.g. the manufacturer of items being serviced by my company’s business process, and retailers of the items being serviced as well. Some half-dozen low level steps performed by these parties are shown the Process Maps, so I am listing these as other Row 1 functions, at least to start.

Row 1 (Scope) and Column 3 (Network, or ‘Where’):
The first and main location is the head office for the unit providing the service. As mentioned, other locations will include one (maybe two) locations for the product manufacturer, and many retailer locations (100+) as well.

The other interesting location of note is ‘mobile’. My unit has a sales team that is organized by geographic regions, where those team members are located and spend a lot of time visiting retailers, so they need to be able to carry out their functions from wherever they happen to be at a point in time. Yes, using the Web to connect our ‘traveling sales mean and women’ is pretty much a given, but treating ‘mobile’ as a location at the scope level illustrates its importance.

Sidebar: As far as I know, I don’t have to deal with physical locations that move; I worked with an insurance data model once that allowed P&C companies to insure buildings on the Arctic ice-pack, which moves about(!).

Row 1 (Scope) and Column 4 (People, or ‘Who’):
This column does not have any commonly used artifacts beyond the ubiquitous Org Chart. I do think its good to have the latest one on hand when you start, knowing that it will change, and that it will not really be used as you model your business in the way needed to support Information System Requirements; but you do need to know the names and titles of the people impacted by the Information System(s) that will eventually be delivered.

For this project, I am populating this cell with about a dozen different Roles played by various employees and other participants in the Process. I picked these up right from the swim-lanes of those detailed Process Maps mentioned back at the beginning of this article. One thing of note is that Role ‘names’ don’t match to current job titles, but past experience has shown that titles come and go, but basic Roles remain.

Row 1 (Scope) and Column 5 (Time, or ‘When’):
I am using this cell to list the major external Events that the in-scope Business Process must recognize and respond to. Again, the detailed Process Maps are the source for these Events, and there are actually only two. Each one fires process executions of some length, with a lot of internal events or hand-offs, but I am not concerned with the latter at this level.

Row 1 (Scope) and Column 6 (Motivation, or ‘Why’):
I am looking forward to driving down this column to the detailed Business Rules, but at this level, I have gathered already well-documented motivational items: Company Core Values, the Mission Statement, and Strategic Goals. I have also already gathered the appropriate company policies for row 2, but more on that later.

So, that’s what I have for Row 1 at this time, based on existing available documentation. When the project starts officially, the first thing to do will be to review these definitions of scope with the Business participants, and have them confirmed or adjusted as needed.

I am also well into creating Row 2 artifacts based on the available documentation, so I will write about those in future posts...