The highest expression of a system design is the framework. A business system framework consists of an end-to-end string of activities which together represent the data gathering, maintenance usage and dissemination activities which the business must perform to maintain a complete set of reference data about one family of data entities and a complete set of records of the actions taken by and against the members of that data entity family.
By extension an integrated business system framework represents the strings of activities for all the families of data entities of the firm and the interconnections and interrelationships between all the activities within and among the separate strings. The string of activities for a single family of entities is call the data entity (family) life cycle (of activities).
Tasks as the Most Detailed Expression of System Design
Each individual business system (or end-to-end grouping or string of activities) can be though of as being composed of a string of processes (or shorter groupings or more specific strings of activities). The individual activities are in turn composed of strings or groupings of highly specific and highly interrelated tasks or procedures. A business system is thus ultimately composed of many individual tasks or procedures which are grouped
into convenient and easy to visualize sets called processes and activities. A business processing system is thus a group of very highly related detailed tasks all specifically sequenced, grouped and organized to achieve a predetermined goal, that of collecting, maintaining and disseminating data which describes the business entities of the firm in terms of what they are and where they are located, and about the business actions taken by and against the business entities. Business systems collect and record the business transactions of the firm. These transactions are organized around the entity families and their members with which the firm interacts.
The processing tasks are thus the lowest and most detailed expression of the system design. Within a business system each task performed should support the goals and objectives of both a specific operational unit or units and of the business as a whole. In other words, each task must exist and be performed for a specific business reason. Within an operational unit a task, activity or process may be performed by one or more persons, and depending on how generally or specifically the task, etc., was defined, it may also be performed in one or more other areas of the firm.
The description and definition of these user tasks (and by extension the description of the task aggregations of activity, process and system) are the end result and the most detailed component of the system design process. Since each task description, including its detailed data requirements specification, is needed for a complete
system design, the techniques used must be heavily inductive in nature. Each user task and its accompanying processing procedure, all the data groupings and the detailed data element contents of each grouping, along with the access paths and index requirements for each grouping must be clearly defined and described.
Each of these detailed task descriptions, since they represent the processing and data of a task of a single user (or group of users) is called a user (task) view. By extension, the aggregates or groupings of these tasks or user views into high level groupings are also called user views (but of wider and wider groups of users, e.g. user (activity) views, user (process) views, user (system) views, etc.).
User View Components
A user view is thus the composite of the procedural description of a task and that portion of the firm's data required by and/or produced from that procedure, from the perspective of the person or group of people performing that particular task.
User views above the task level are subsets of systems, processes, and activities and are presented from the user's processing perspective within the systems, processes and activities, when and where they are performed.
A user view describes what the task is, what the task steps are and what data each of those steps requires. Task data requirements are stated in terms of the classification scheme for each family of entities in the framework model, and specifically in terms of:
User View Portrayal
User views are stated in terms of the sequence of processing action steps and the sequence in which the entities must be accessed, the entity occurrence identifiers which are available for use by the task, and the actual data required about each entity, or which is to be changed or stored about the entity.
Tasks are are grouped into multiple aggregates for ease of reference, and for purposes of management control.
User Views in Perspective
However, unless they are viewed in the larger perspective, individual tasks:
When integrated, the final system design must be a composite of all the user task procedures, task aggregates of activity, process, system, and data access, attribute, relationship and detail data element needs.
Although we think of a task as consisting of a self-contained, homogeneous work specification, in reality each task has two parts, one within the other. The inner part, describes the actual task processing steps (like the meat of the nut). The outer part, describes the importation of data from the central files or from external sources which the task needs to operate on and the exportation of processed data either back to the central files or to an external recipient (like the shell of the nut).
Common Data Resource Processing
Processing in a central file environment is more explicitly transactional than the more traditional structured operational systems. In operational systems, data files can be passed from task to task (in the case of source documents in manual systems) or can be thought of as being passed from task to task in the case of data files flowing from program to program in an automated system. In business systems centered around the central file concept, data doesn't flow from task to task but from the central file to the task and back to the central file. This transactional view is the same in both manual and automated environments.
This transactional orientation more closely reflects pre-automated processing in that business transactions tend to arrive randomly and unless there are specific business rules to the contrary, they can be processed immediately. Transaction processing, as with manual procedures tend to be shorter, more straightforward and all task steps and resources tend to be clearly identified. Transaction procedures also tend to be bounded with a definable beginning and ending.
Since most business systems include some existing level of automation, one of the conditions which affects a new system design is the effect of prior automation on the existing system, and the influences of the automation technology not only on where the processing occurs, but when and how the processing occurs. Automation technology may also have dictated how task were aggregated and may have dictated that some tasks be performed because of automation, to create processing efficiency, or overcome technical deficiencies.
These influences must be recognized and accounted for, but should be examined carefully when developing the design of the new system. Whether automated or not, tasks are usually aggregated around common data requirements. The designers must determine whether existing aggregations are natural or artificial with the goal being to develop aggregations which are as natural as possible. That is, they should try to develop aggregations that follow as closely as possible data commonality and natural entity life cycle processing dependencies.
The relationship between the business as a whole, the operational areas which comprise the business, the systems which are devised to organize the performance of the work of those operational areas and the processes, activities and tasks which in turn make up those systems conforms to the top down view of systems and should be developed as deductively as possible.
Classification View of Business Systems
The top down or deductive view follows the leveled view of the business where the components at each successively lower level are a decomposition or more detailed view of those at the higher level. Under this view work flows downward from the top of the organization to the bottom. Work assignments are divided, subdivided and delegated at each successively lower level until they can not be divided any more. This lowest level of work subdivision is the task or individual procedure. This division into finer and finer detail is in reality the development of a hierarchic classification of tasks based upon 1) managerial responsibility assignment and control needs and 2) entity life cycle activity processing needs.
This classification hierarchy view of work is incorporated in many structured analysis techniques and is also the foundation of most data modeling techniques. The structured analysis techniques start with an enterprise, unified, or corporate view and decompose that into smaller more detailed views based upon a set of well defined task delegation, entity life cycle and processing dependency rules. This view also assumes that all work within the firm arises from a single overall
business system, and work units at the lower levels are only connected through a higher level unit. It also assumes a traditional simple hierarchic view and not the polyhierarchic view which more closely resembles the real world
Different User Views
Although this simple hierarchic view is widely accepted, and in many respects is correct, it does not account for the view of the firm which is presented through the development of business entity life cycle of activity or work flows. Nor does it account for the interlocking managerial responsibility view of work assignment. The top down view presents a vertical view while the entity life cycle of activity or work flows present a horizontal view of the same systems. The horizontal view depicts work units (tasks or activities) at any given level of detail as being interconnected and interrelated by procedure, data transfer, data commonality, data dependence, process dependence, sequence dependence and transfer of control. These work unit or task interconnections at a given level of detail are not often portrayed in the decomposition diagrams.
One of the ways in which these seeming differences can be accounted for is that each view is in reality modeling a different perspective of the firm. These different perspectives correspond to the different views of the various user populations of the firm. They also correspond to different managerial and operational perspectives of the firm. At a minimum they account for the essentially horizontal managerial view of the firm and the essentially vertical operational view of the firm.
In order to understand these different user views we should review the definitions of some terms.
Specific functional responsibility and authority may rest with an individual, a group of individuals, groups of individuals, one or more areas of the firm, or with the firm itself. It may involve one or more distinct, dependent or independent activities. Functional performance criteria must be identifiable, definable, and measurable. A function may be identified and defined but may not currently be performed. A function must be definable in terms of responsibilities, authorities, accountabilities and measurable performance criteria.
Generally, a function can be equated to a management control point, with one manager equitable to one function. Thus functional decomposition follows the management reporting structure (which may or may not follow organizational lines), and a function is whatever a manager is responsible for. Function corresponds to managerial authority and responsibility which can only be delegated from above. A functional model could be represented by a simple hierarchy.
Higher level integrated systems may span lower level functional areas while lower level operational systems tend to be contained within a functional area. There is no necessary correlation between the functional hierarchy and the system life cycle flow models, especially in integrated central data base systems.
Activities are data driven, triggered by transactions or requests for data, are the active portions of functions, tend to be repetitive and formalized, and are usually composed of many tasks. activities are almost always portrayed horizontally.
Business System Component Hierarchy
These definitions create a hierarchy of concepts (Figure 15-1):
A business function is a managerial delegation of responsibility, authority and accountability that engages in a series of related activities, involving one or more entities, performed for the direct, or indirect, purpose of fulfilling one or more missions or objectives of the firm. For purposes of control a function organizes its activities into business systems which are groups of business processes. Business processes are groups of business activities organized around data or process dependencies. Business activities are groups of business tasks.
Business procedures are the documented forms and methods which specify the manner in which those business activities or tasks are to be performed
Business systems then are ultimately composed of groups of business procedures. A business system is the framework within which the individual and related procedures operate. Because they are developed for managerial convenience more than anything else, the task aggregations at the intervening levels between function and task are more or less arbitrary and dependent on business needs, user perspective and data and/or processing dependencies.
Generally, an activity is discrete, and part of an overall function. It is highly structured and task oriented as opposed to the control and management orientation of systems and functions. Generally functions are managed and activities are performed, although this distinction is far from definitive.
Activities, are data driven, in that they are triggered by transactions. These transactions either bring new data into the firm, modify existing data, or are requests for data from the firms files. Activities are the active portion of functions. Most activities tend to be repetitive and formalized.
To place this hierarchy in perspective and to illustrate the complexities of the user views we can look to the organizational pyramid. Although there are exceptions, most functions exist at the strategic and managerial levels although some may extend to the operational level as well.
Without an understanding of the placement of the user's processing within the overall existing framework of the function responsible for that processing, and perhaps within the organization as well, and without an understanding of the relationship of the user's processing with the other processing within the firm, it is difficult for the designer to assess the accuracy of his business knowledge and his understanding of the user's needs gathered during the analysis phase interview process and from the designer's own observations. It would be even more difficult to devise a complete and rational business system without this understanding.
Because they are based upon business entity activity life cycles, many business processing flows interact in ways which transcend, and cross, the hierarchic managerial or functional boundaries which are implicit in the table of organization. The various user view process models, both individually and in composite form, help to understand the overall interconnections of the flows of processing, data and information within the firm.
The designer must remain aware of a basic fact of business systems. Business systems must be capable of having components added, deleted or modified as the need arises, and these additions, deletions and or modifications must be made according to the same rules and within the same framework as the original system design with only minimal disturbance to the existing system.
In part II we presented two kinds of frameworks which could be used to scope the overall system design - the entity and entity relationship models for data, and the entity life cycle model for process.
In Part III we will present two additional kinds of frameworks that can be used to structure the processes of identifying the detail components of the system - tasks and entity attributes. As we present these frameworks we will attempt to show not only what they are and how they are developed but why they are used, why they are important and most importantly how they can be used to explain the process of detail design.
Each model fits within a unified structure, and serves a different purpose. Many readers will be tempted to position the models in both parts II and III in traditional categories of conceptual and logical, data and process. Although these models are leveled, and do present differing levels of detail, and we have discussed them in terms of data and process, closer examination will show that with the exception of the entity model, each model combines some elements of process and some elements of data, although each model is presented from a different perspective.
Again it is stressed that these models do not constitute a methodology nor are they presented as such, but rather as mechanisms for explaining the various processes and components of the system design process.
Data Directed Systems Design - A Professional's Guide
Written by Martin E. Modell
Copyright © 2007 Martin E. Modell
All rights reserved. Printed in the United States of America. Except as permitted under United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the author.