Framework Considerations
Framework development concentrates is on the identification, selection and definition of the real world data entities of interest to the firm, and the fundamental flows of business activities which follow the data gathering, maintenance and usage life cycles of those entities. Resource constraints and practical business considerations do not permit all possible data to be captured and maintained, nor every possible business condition to be included within a system. The final system design must therefore identify and include the most important items (data entities and their life cycle business activities), and identify the items with the best cost/benefit ratios.
The creation of the framework models begins with the development of lists of all possible data entities and all possible life cycle activities for each entity. These lists contain the candidate entities and activities from which the final selection will be made. By examining those lists and categorizing and prioritizing their respective contents, the design team can make the final selection of entities and activities to be included in, and handled by the final system.
Viewed in light of business requirements, business priorities and resource limitations, some of those candidate data entities and events will remain of interest to the design team, and some will not. However, since they all have in common that they are real, and important or not, they exist within the corporate framework, they must be accounted for within the business procedures. The company is defined by those entities, the data the firm must gather and maintain about them, and the business policies, standards, rules and procedures which govern the interaction of the firm's employees with those entities, and how the firm's employees handle those business activities
Additional Entity Discussion
Now that we have examined the development of the data entity models and their life cycle activity models, it is appropriate to further discuss the entities we have identified and modeled. We have used the term data entity and entity interchangeably, although the term data entity is more appropriate. Each of the entities as they appear on the framework model is a generic entity and represents a label which is used to identify a family of entities, such that if the entity is labeled Account it represents all things which are kinds of accounts. The more specific the label (e.g. Customer Account) the smaller the family represented by that label. This also implies that their may be other kinds of accounts, but the firms wishes to treat them as separate families rather than as kinds of entities within the same family. The implications of family labeling are extensive within the model. If we assume that the design process will result in a composite model for each family of entities, and that each composite model will be the model for a subject area or reference data base (to use Data Processing terms), then by segregating entities into families we are making the decision to keep the data within each family permanently separated (with possible implications in terms of redundancy and lack of synchronization between data about similar entities which are now in different families). If we combine sub-families into higher level or more generalized families (e.g. Accounts) we are implying that we do not wish to segregate the data and we must therefore create a more generalized composite model to handle all of the different kinds of entities which now populate this extended family.
End Result of Data Design Model
The end result of the data portion of the design is the development of a composite or generic model for each family of entities. This composite model must specify all data groupings and all data elements which relate not only to the family as a whole (to all members of the family regardless of what kind of member it is) but to each specific subgroup of members, kind of member, down to the most specific kind of family member that the firm recognizes. While this specification of entities to the individual kind of member is referred to as typing and subtyping, in reality it represents an activity which is natural and desirable in both individuals and corporations - the activity of classification. Whenever we deal with large groups of things which are made up of smaller subgroups, we are classifying. Whenever we recognize something as a kind of something else we are classifying. whenever we apply labels to groups of things as a means of dealing with things which are similar in some respects but not identical, we are classifying. Whenever we catalogue, categorize, index or sort things we are classifying them.
Data modeling is the process of classifying data from the very general level (families or enterprise level entities) down to the individual groupings of data elements and finally the data elements themselves which make up the full classification schema of the data model. Each entity family, with its groupings of members within the family, the unique kinds of members within the family and the unique groupings of data which are needed to describe each member in total form a unique composite model. This classification process is a very important part of the design process and it is extremely important to identify each component of each of the family classification structures since it is these which are used to determine the composite family models.
Each family of entities in turn, has a life cycle which begins when the firm recognizes a new occurrence, continues which the firm sequentially or randomly gathers the information it needs about that occurrence and ends when the firm no longer needs records about that occurrence. Just as the entity at the enterprise level represents a composite entity, so to the entity life cycle represents a composite life cycle. The activities within the life cycle must account for the gathering, maintenance and dissemination of data about any entity within the family.
Model Context
It should be obvious that entity data models and business activity life cycle flows can not be developed in a vacuum. Nor do they represent a complete description of the firm from which a system can be designed. They do however, represent a first cut, or high level view of a system design, specifically the design of a business data processing system. A business data processing system represents the predetermined response of the business to both internal and external stimulus. The representations of these stimuli are data transactions which inform the firm that something has happened, that new information is available, or that revision or modification is available. These responses represent the predetermined manner in which the business reacts the actions of others or the manner in which the firm records actions which it has initiated on its own.
A system must be capable of handling both routine and exceptional conditions. While a system must be able to correctly handle known activities, it must also be flexible enough to be able to accommodate itself to conditions which were not planned for. Therefore, the more that is known about or that can be predicted about what can happen and the variety of exceptions which can occur, the better the systems designers are able to anticipate and prepare for unusual conditions.
Three Time Frames of New Systems Design
Design of a new system must accommodate three time frames. The new system design must change the old ways of business processing, must incorporate new processes which have become necessary since the old system was designed, and it must attempt to the degree possible, to anticipate future business requirements and business conditions and allow for them. Business system design involves prognostication. It is the process of generating ideas and innovation, of projecting current conditions into the future, and of anticipating future changes. It is the process of asking the question "what should be...." It is the process of questioning what we do, why we do it the way we do, what should we be doing, and how should we be doing it to achieve maximum processing efficiency control, etc. In other words, how can we structure our processing of business data to achieve maximum satisfaction of our business goals and objectives.
The Test of a Good Design
The test of a good design is whether it works as expected and as defined. A better design produces more of what is needed and useful than was asked for. The best design is that which produces more of what is needed than was asked for for the longest projected time frame.
A business system is composed of related processes and activities. These activities together are expected to accomplish one or more missions for the firm. Business systems normally operate within a single operational area. They represent the collection of procedures which determine how the work of the area is to be accomplished. They also assist the routine work of that operational area.
Business systems framework designers attempt to organize the processes and activities of the operational area(s) in a manner such that the interaction of the individual components is smooth and efficient. If successful, the work flows smoothly between these activities and processes with little if any wasted or redundant effort.
System Design Objectives
The system design framework must accomplish a number of purposes:
To be effective and useful, the frameworks should be designed around general cases and standard data events. Exception processing while necessary is just that exceptional. The majority of processing within a system is standard and routine.
Frameworks serve the same function for the system designer as outlines do for the author. They lay out the form and structure of the product to be produced, for the former the system, for the latter the manuscript. Frameworks can be as general or as specific as necessary to convey the necessary information. They should convey a picture which reflects the business which are and which should be performed.
The frameworks components when combined should present a complete overview picture of the business processing as it will be performed when the system is implemented.
Because most systems design projects are centered around a particular application, it is critical that the design team recognize the relationship between the business system framework and the application or user area.
Business system frameworks represent end-to-end flows. Business systems may or may not follow operational or user area lines. In most cases applications are not full business systems but chunks or portions of systems. Business system flows follow the central data foci (entities) of the firm - its products, customers, orders, employees, etc. Each data (entity) flow runs through the business and touches each area. In fact those areas exist because they have responsibilities with regard to some of gathering, maintaining or utilizing data about those focal entities. Operational areas perform their activities in predetermined methods, methods which are consolidated into procedures.
Classification View of Business Processes
The relationships between the operational areas and the systems, processes, activities and tasks or procedures are hierarchic. This hierarchy represents classification activity similar to that which occurs on the data side of the design. That is, the operational areas identify their routine tasks in terms of aggregations of tasks called activities, aggregations of activities called processes, and aggregations of processes called systems. When designed around data entity processing life cycles (needed to create integrated databases or common data resource environments) a redesigned, integrated business system may incorporate many processes from many different existing operational areas. Each process may incorporate many activities, each of which may incorporate many tasks.
A operational area however may also have many different wholly internal processing systems which it uses to accomplish work belonging exclusively to the area. While these internal operational systems may appear to be freestanding, it is more likely that they are or should be interconnected. These interconnections will either be through the use of common data files or through the use of processes which can be generalized to perform work which is similar but not totally identical to all. Typically the processes which can be generalized relate to data gathering and reference data maintenance, rather than to data usage or recording of business activities.
From the overall perspective of the business the system work flows operate on an end-to-end basis and transcend operational and user area lines. From the perspective of the user area, many different systems are active at any given time. While each of these systems are complete end-to-end, they may not either begin or end within the specific user area. The perspective of a given user is that of a system fragment. These system fragments, sometimes called applications or user views complicate the design of new systems since it is the user area which develops the specific procedures which govern how it performs its particular part of the work.
These user specific procedures assist the user in performing his part of the overall business system flow. Since a business system typically spans many user areas this fragmented procedural development results in disjoint pieces which may or may not work in harmony. Since the data gathering and maintenance responsibility lines between operational user areas is blurry at best, it is often not clear where the responsibility for a specific task lies or should lie. Many tasks, in some cases whole processes, are either duplicated in different user areas, or worse, they are lost. In many cases the differences in perspective between the user areas may put the different users in conflict with each other as each attempts to perform its work.
User Focus
The focus of each user area is its particular work. It will attempt to make the performance of that work as easy as possible, and will also attempt to make itself as self contained and as operationally self sufficient as possible. One major factor for this is that most operational area managers are evaluated on how well their areas perform their own work, not necessarily how easy they make it for other areas to perform theirs. This drive toward operational self sufficiency leads toward separate user files, separate user controls and separate user methods for performing their work.
The organization structure of most businesses is such that user areas are encouraged in this self sufficiency and separateness. Managers are authorized and encouraged to organize and control their work themselves. Most user areas strive for autonomy in as many areas as possible.
Since business processes change more frequently than the data about the things being processed, data centered designs are inherently more stable than process centered designs. Business processing tasks can be designed separately from corporate organizational and operational structure and can be rearranged and resequenced without disturbing the files of the firm.
The entity-relationship models are a way of organizing, categorizing and classifying data and using that data classification structure to determine the firms data requirements. Those data requirements can in turn be used to determine the firms processing requirements using either inductive or deductive techniques.
The primary classification of data is at the entity or kind-of entity level, with secondary classification occurring at the facet, characteristic, property or attribute level.
The entity-relationship approach is used because it is far more natural for users to seek data about things than about processes or actions, and because the entity-relationship models follow natural user classification schemes.
Although we portray systems in nodular form, as strings of processes, or large units of work, in reality a business system is a string of small tasks each of which is its own small system. Each has its own input and its own output. That is each receives its own raw forms, reports, documents or other data carriers, each performs some work on those documents, etc., and each produces some output, in the form a another report, form, document or data carrier. In some cases, the output is in the form of revisions, corrections or approvals of the work of others.
A given business system may contain hundreds of discrete tasks, and may employ almost as many forms, reports and documents. It is difficult to comprehend such complexity, thus the need to create a classification structure of business tasks by grouping them into modules or aggregate these tasks into activities, processes, systems and life cycle work flows.
Tasks are aggregated into activities (labels for groupings of tasks) which are in turn aggregated into processes (labels for groupings of activities) . It is obviously easier to visualize and talk about a few activities and processes than it is to visualize the hundreds of component tasks. In the same manner it is easier to visualize individual kinds of data entities or data entity families (representing people, places, things, etc.,) than it is to visualize the hundreds of component data elements which are needed to describe the members of the families or the hundred component forms, documents and reports which contain data about them and the actions taken by or against them.
Frameworks are Common to most Methodologies
For these reasons most development and design methodologies advocate the development of a high level or framework design. This high level design usually consists of a combination of diagrammatic models and narrative explanations of those models.
Although the systems design components of data, processes and work flows are common to each of these methodologies (collections of techniques), each presents the information in a different manner, and with differing results. The fact that the same environment can produce different design results when different methodologies are used or when different design teams use the same methodology is troublesome. The difficulties with many of these methodologies is both with their manner of presentation, and the lack of precision and clarity in the definition and identification of the components of the design.
Although we can watch a task being performed, most people have difficulty in grasping an entire process. The same holds true of data, but in a slightly different manner. We can easily view the individual documents, forms and reports, but we have difficulty in organizing these documents in files where the documents may be similar but not identical. Additionally, data as it appears on a specific form or document is easy to visualize. Data we are using at the moment is easy to visualize. Data we have not yet acquired is more difficult to visualize. Since a system design is a plan for the future, a large part of the task is to anticipate future requirements and allow for them.
Vagueness of System Frameworks
Any discussion of system design and especially system design frameworks must be relatively vague. The reasons for this vagueness lie in a number of areas.
There are few general guidelines for the designer, which can be stated outside of the context of a specific company, function, system and management structure. System designs are abstractions. They are representations of an environment which does not yet exist. They are representations of changes which have not yet been made. System frameworks are attempts to visualize those abstractions.
Every system design consists of both narrative and graphics, words and pictures. They complement each other. Each level of the design has a different set of narratives and graphics. At the framework level they portray the interaction of processes and scope of the work which is included in the system.
The discussion so far has referred to the framework level. This term should be explained so that the remainder of the discussion can be placed in context. Just as data models are developed in a leveled manner, with each successive level being a decomposition or further classification breakdown of the prior one, so to the process portions of the design are developed in a leveled manner.
Frameworks at the Enterprise Level
The framework level corresponds to the enterprise level of the data model. The components of the data framework are the aggregate, composite, or families of entities around which the processing of the business revolves. The activity life cycle or processing framework model depicts how those major processing activity aggregates interconnect or relate. In many respects one can view this model as the process version of the data entity-relationship model where the entities are not data entities but process entities.
Business systems, business processes, activities and tasks form a hierarchy, with the systems being the most complex and the tasks the least complex.
The systems are the most global, tending to cross organizational lines. Processes tend to reside with single organizational units although they may cross those boundaries as well. Activities and tasks, are the most localized and almost never cross organizational lines. Being the smallest unit of work, tasks are performed by individuals or by very small groups.
Frameworks should represent systems in the most global context possible. They are graphic representations of the descriptions of the business. Frameworks are semantic models, not logic models. They do not represent the decisions which are implicit in the business processing, but rather the sequence of processing events which occur in the life of the business. Although business systems are depicted as having a beginning and an ending, as straight line sequences, in reality they are more recursive, almost circular in nature.
Business system models represent ideas and concepts, abstractions. One can not walk through the offices of the business and see the systems being performed in the same manner that one can see the tasks being performed. The abstract nature of systems make their design very difficult.
Systems are composites of processes and activities. Because these processes and activities are the domain of a wide variety of individuals and organization units it is difficult to get a consensus of the system description or components.
Each responsibility are has a different perspective of the activities being performed. These differences in perspective have been called user views. The concept of a user view and the principles and techniques which can be applied to the design of the procedures which govern their routine data processing activities will be discussed in more detail in the next part of this book.
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 publisher.