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...

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

I am doing some pre-project gathering of Requirements for an upcoming Feasibility Study to implement a new systems solution for my employer’s main process for delivery of its services to its customers. The scope and options of this study were drafted, debated and changed, until they basically aligned with my favourite phrase:

“Re-Use before Buy, Buy before Build, Build for Re-Use.”

Some even earlier pre-work to the Study has already identified several alternatives across the Re-Use and Buy options, so the study will evaluate two most ‘popular’ alternatives in order to select one as the recommended solution approach. It is possible, though not probable, that neither of these two alternatives will be recommended, after which we will move on to other identified alternatives.

So, here is what I have in terms of existing documentation to help me draft some Requirements before working with the business;(I hate a blank page as a starting point):

… Detailed Process Maps of the Business Process created by Process Pros in Six Sigma improvement projects.
… documentation on current systems (implemented before I joined the company), and my own experience on a couple of fix and enhancement projects on those systems.
… as an application, the main current system is somewhat unwieldy; I have been told it was developed based on an even earlier system without much user involvement, and was implemented before it was finished, not a great start.
… on the other hand the data model and physical database used by the application is very good, pretty much in 3NF that I can see; it was developed separately from the application, and the application is worse off because of this.; but the detail data requirements that will eventually be needed will be able to draw much from the current model and database, but this will be after the Feasibility Study.

The Feasibility Study will define high-level requirements, considered sufficient to evaluate alternatives. I have often seen such High-Level Requirements delivered as pages and pages of Requirement Statements: “the System/Solution must (do something, store something, etc.)”. The quality of a group of such statement can be very high, but the volume makes them hard to manage.

As a result I am going to use the Zachman Framework (www.zifa.com) as way of , having gathered Requirements in some form, to document them using various models/artifacts, and organize them by the rows/columns (“cells”) of the Framework. I have yet to decide if I will eventually extract a list of Requirement Statements from the artifacts, but it is quite possible I may need to so in order that a wide audience can review the Requirements without having to understand ER Models, for instance.

From a Business Analysts’ perspective, we are talking mainly about Row 2 for Requirements artifacts, what David C. Hay calls the Business Owner Viewpoint. However, if Row 1 (Scope) artifacts don’t yet exist for the business domain to be analyzed, it is best to create them for reference; the Row 1 content may already exist in various places and forms, but gathering and documenting in Row 1 is a good place to start the requirements activities for a project.

That is just how I started, to be continued...