Data Entity Life Cycle Frameworks
Business Perspective
One of the major framework activities facing the design team is the development of a business perspective from which to begin the design of the new system. This perspective must depict the various life cycle of documents, data, material and other work within and across the user area (or areas in the case of a multi-user system). These life cycles are the horizontal intersecting flows of activities which must be performed to gather, maintain, disseminate and use data about the central business focuses of the firm. Each activity in each life cycle can be described in terms of a shorter life cycle of shorter activities all of which are subsumed within the higher activity.
There are three categories of entities of interest to the firm each of which has a distinctive kind of life cycle:
The systems analysis and subsequent examination and study phases should have identified all of the major or primary activities performed within the user area, and should have produced a detailed description of the tasks performed within each activity. There should also be some documentation as to the data which initiates each activity and the data which is produced as a result of that activity. Even if the system design team is not composed of the same personnel who performed the systems analysis, the systems analysis documentation should provide a good grounding of "business knowledge."
Specifically, the design team should understand not only what the user's current activities are and how they are performed, but what their problems are and more importantly why the users perform their various activities. They should be able to place the users in organizational context, and should understand how the users do, and should fit into that organizational framework. This background and detail information is critical to the ability to design an effective system. This contextual placement and detail forms the basis for the new system, since it is the context within which the needed changes must take place. Most importantly, the designers must use this business knowledge to ensure that the new system design fits within and interacts with, existing systems not only of other user areas, but also any systems of the client user which will not be changed during this design effort.
Perhaps the most important use of this information is to aid the designers in understanding the specific terminology and concepts which are used by the users in their work. In order to make workable changes, the designers must know enough about the user's work to be able to perform it themselves. They don't have to be able to perform it as well as the users, but they should have sufficient grounding and understanding to work alongside the users. Each design team member should have enough knowledge, not only to make viable suggestions for change, but to be able to evaluate suggestions from the users and from other members of the design team. In other words, the design team has to know enough to question what they see, read and hear.
User/Design Team Partnership
The design of a systems is a partnership between user and design team. It is also a two-way conversation. The users supply business activity and business justification information, and the designers provide objective viewpoints, and the ability to organize, evaluate, rearrange, systematize and automate the user activities. The design team provides the understanding of information systems technology and processing to make judgments on appropriate automation techniques, when to automate, how much to automate, and how best to automate.
Because each user is different, each business is different, and each situation is different, there are no common answers or common solutions to a given user's problems. Each situation must be examined on its merits, in context, and an individual tailored solution selected. Each system is thus different from every other system. No two are alike any more than no two people are alike, even identical twins. System design guides such as this one can do just that, guide. They can point out similarities between systems, provide techniques for assisting the designers in their work, and can point out areas where problems usually arise. However, in the end it is the judgement and experience of the design team, their preparation, documentation and understanding of the underlying business, the specific business activities of the user and their own technology which determine the success or failure of a design effort.
Most business functional areas perform many different, but related and interdependent activities. Each of these activities are a collection of tasks which themselves are related and interdependent. The activities are collected into processes which are further collected into systems. In a similar manner, systems themselves aggregate to larger more integrated systems.
In order to understand the process of designing systems, one must understand the various ways in which these various components can fit together. In many respects the fitting together of the components is
the first system design task of the design team. The other task obviously is to determine what those components are and what they have to accomplish. This combination of task and flow is the major portion of system design. Because of their high level perspective and non-process orientation, the data models, data entity time lines and other design aids are primarily methods for combining or integrating systems, although they are extremely useful at the individual system level as well
Process or life cycles
All business systems are constructed around one or more process or life cycles. The more integrated the system, the more complex the functional area being supported the more functional areas which use the system, the more distinct life cycles which must be incorporated into the system. At the highest business perspectives there are one or more life cycles which link all the processing areas together into a cohesive business unit (figure 13-1). Regardless of the level being addressed, the process of producing the life cycles and fitting them together is essentially similar. These flows when completed look something like a project plan. The individual flows when interconnected become the framework which depicts the tasks which the business processing areas within the function need to perform and the sequence in which those tasks need to be performed.
To understand this type of systems framework and its perspective, one must understand the business of the firm. Each business has a specific charter. This charter is a legal document which enables the firm to function and act with respect to its customers and other firms. Unlike people who can change their activities, careers or jobs at will, business are regulated in their actions, and have prescribed activities. Those actions are subject to review by both internal management and external auditing and regulatory agencies.
Because of the prescribed nature of its actions, and the need to audit both the actions and the results, business activities are usually governed by procedures which set out what needs to be accomplished and how it must be accomplished. These procedures in turn operate within a structure which is determined by the business practices and goals of the firm.
Business Focal Entities
Every firm has at least one business focal entity. Something around which all the firm's business activities revolve. This central focus is usually either a product, a service or an order for a product or service. This focus can easily be identified because it is the person, place, thing, concept or event (an entity) about which the firm needs to collect the most data. This data serves to identify and describe the entity to to help the firm track, monitor the status of, predict the activities of, or report on the entity. Within the business areas of the firm, each functional area may have its own focus. That focus might be an order (figure 13-2), a specific product, a shipment of products, the purchase of supplies and materials, or it might be an attribute of an entity such as product pricing, or customer credit management, or sales order verification.
Each group of administrative activities of the firm has a separate focus. Human resources focuses on the employee (figure 13-3), Accounting revolves around the account, or the ledgers of the firm, and so on.
Assembly Line Analogy
If we can draw an analogy between a business processing system and a manufacturing assembly line, business systems follow that focal entity through various processing stages. At each stage some action is performed which directly changes the entity, or which processes in some way changes made by others. Some of these changes are very complex and thus they are broken down, or decomposed into smaller task sets. Other activities are simple and many can be merged and accomplished at the same time. However simple or complex the processing, it is performed in conformance to a set of business rules, and toward the achievement of a business goal.
Some of these activities and tasks can be performed in parallel, others must be performed in sequence. In almost all cases however there is usually a definitive beginning to the processing and less usually a definitive end to it, as with the time lines in the previous chapter.
Since the business itself is an entity, albeit a legal one, it can be viewed in the same manner that the physical entities are viewed. That is, it has a life cycle. That life cycle is determined by the activities that the firm must engage in to "stay alive". To illustrate thus concept we can use a manufacturing firm. In this type of firm there are two separate focal entities - the product of the firm and the customer orders for that product. The life lines for these entities are intertwined in the life of the firm. The life line for the product starts during the design of the product and continues through engineering, production and warehousing. The life line for the customer orders begins with a customer placing an order for the product and proceeds through the various processing activities of order verification, validation, confirmation, and acceptance; through the selection of product from inventory, the preparation of the product for shipment, actual shipment, invoicing, billing, payment and order completion.
All activities of the firm revolve around these two life lines, or are a direct result of some activity which occurs during those life lines.
Life Cycle Construction
In order to construct a framework for order processing, the design team must "walk an order through the firm", from initial receipt through final filing in the firm's archives and reporting through the various financial accounting systems. It must also "walk" the product through the firm, from initial design through each of the manufacturing stages, the material purchasing stages, the quality testing, and inventory stages.
Since the intent of the new design is to modify the way the organization operates, to make those operations smoother, simpler and more efficient, the design team should examine every step and every activity to see that it is properly placed, performed in the most efficient manner and at the right time. It must also determine where the necessary changes should be made. More importantly, during the framework stage it should plot an "ideal flow." In other words, it should ignore how things are currently being done and when they are being done, and instead to look at how they could be done if all constraints were lifted. The designers must also seek to determine what constraints exist which prevent the processing from occurring in the ideal manner. The plot or flow when completed should ignore to the extent possible, existing functional responsibilities, and concentrate instead on efficient movement of the entity from stage to stage. In all cases the design team should look to determine what activities can be performed at each stage with the resources available at that stage and given other resources what additional activities could be accomplished at that stage.
For instance, in our example above, given access to all reference files, the order could be completely validated in one step, with the exception of credit checking (which requires additional data). The design team could then assume that complete order validation should be accomplished in one step.
These types of changes are processing (in the broadest sense) changes, rather than functional changes. They may enhance the function by adding processing responsibility, they may improve the response time of the company in certain functional areas, but the underlying function still retains its responsibilities to satisfy a fixed set of business needs and these rarely change.
However, as with any change in the organization, there may be a rearrangement of responsibilities for activities and a shift in when where and how those activities are performed. In the design of a new system, the shift is normally toward consolidation of responsibility. That is, it results in a consolidation of activities such that the end result produces a more streamlined, and less fragmented life cycle. The design team can use the data events to guide the distribution of task responsibility. As data events are identified and defined they should be placed in those areas where they originate. All activities associated with a data event are combined to the extent possible in one operation or series of operations.
A new system should not normally affect the company business. It may affect how it does business but not what that business is, although it is possible that with enhanced capabilities new products or services may become available through data processing systems. Specific changes occur in the product, responsibilities or even product lines but rarely does the basic business change.
From a data viewpoint, the organization is even more stable. To function, the business needs data, and the sources of its data are known. However, as the business changes it may require new data. This new data may be available from existing sources, or new sources may have to be developed to obtain it. For instance, to obtain additional customer data the firm may have to alter its order forms, account opening applications, or other such existing forms. In other cases these forms may have no provisions for gathering this data and the design team must develop completely new forms.
Each business has a flow of data. This flow has a definable beginning and a definable end point. Because business systems are for the most part data processing systems, the processing life cycles tend to follow the data flows. For instance, in a personnel system, The data flow might start when an employment application is submitted, although it is equally likely that it might start when the job requisition is produced by the user area. Since both are valid starting points, the specific starting point for the new system might be either of the two or more likely both. The choice is partially dependent upon the scope of the system being designed, and the willingness and needs of the user area to incorporate both into the system. In such systems, there would be multiple start points and, depending upon regulations and company policy, there might also be multiple end points.
Two Categories of Business Function
The functions of any firm, whether it is a manufacturing, finance, or service firm, can be segmented into two broad categories. Each of the various functions of the firm can be assigned to one or the other of these categories, and in some cases, a function may be assigned in both categories.
The Business Life Cycle Matrix
A business life cycle represents the flow of control and interaction of data and processing through the business. The relative positioning of each processing activity is determined by the actions which must be taken against the focal entity which might be the life of a single product of the firm, or other unifying aspect or thread.
The determination of this thread is one of the more difficult aspects of systems design. Just as the firm itself has a processing life cycle, so to each functional or user area has its own processing life cycle. If the firm's systems are working well, these individual user area threads work together to accomplish the business of the firm. The interconnected threads form the business processing life cycle of the firm.
Each business area has its own thread or in some cases multiple threads. This thread is the flow of work through the area. Each thread can be viewed as consisting of beginning with the receipt of some document, followed by the processing of that document and ending with the filing of that document in the files of the firm. Some Functions are active only once during the life of a product, or on a thread, while others are active on a continual basis, for the purpose of the model, one should assume that each function is active for the duration, but has a specific activation point.
The functional model, when completed should depict the flow of control, material or information, or all three, along the life cycle. Because the firm may have may many products, services, informational, control or other logical threads, it may be necessary to produce multiple models, each depicting a particular thread or flow. For instance, the accounting thread, will probably be different from the material management thread. The various line of business threads may themselves be different from the administrative thread. In decentralized organizations there might even be multiple versions of each of the basic threads, each corresponding to the management techniques in use by the each decentralized unit. These decentralized threads might in turn be different from the parent company threads.
For these reasons it may be necessary to produce multiple models, or to clearly state at the outset which part of the firm is being modeled. If multiple models are produced, they may intersect or overlap at various points or they may be completely discrete. Overlap and intersection points, if they exist should be examined carefully to determine if both models agree at those points.
Various Life Cycle Construction Methods
There are many ways to approach the development of the life cycles. Most methodologies and automated products provide extensive support in this area. Because these flows can be depicted in such different manners and because each system has its own unique flow, there is no standard way of approaching this phase. We will outline several different methods which appear to be most popular. All life cycles can be viewed as an assembly line processes. That is a series of processing stations where each station modifies the product and passes it along to the next. If we view the processing as data processing, then the "product" being passed could be a file of records, or documents, or other data carriers. Most processing contains some form of new data capture, validation, filing and reporting. The data can have a single entry point or like the assembly, have multiple points at which components of the data become available or are needed. Here these entire parts can be rearranged and the data components manipulated until the processing flows smoothly and easily. The activities at each station can be rearranged to effect the most efficient processing and the least movement of files or segmentation of processing. this can also help to eliminate redundant processing by assembling more of the components at each point rather then following a station per task flow.
The processing framework is perhaps the most critical portion of the design since it guides most of the remainder of the design and implementation efforts. It is here that the first cut at streamlining takes place and it is here that the processing direction is set.
Business processing systems must be viewed in the same way as a manufacturing assembly line process. Raw materials enter at one end and finished goods leave at the other. At each processing station actions are taken which add to the work in progress. Both processes are driven by the availability of materials (or data) and a plan which dictates the order in which the actions must be take. These processing plans take into account that some actions logically cannot be taken before others, some must be sequentially performed and others performed in parallel, still others only on an exception basis, but no actions are taken totally at random.
The assembly line has been organized and sequenced to ensure maximum efficiency - maximum productivity with minimum effort. Each station is guided by a logic which determines what has already been done, what has yet to be done, and what can be done right now, with the materials available and based upon the state of completion of the product.
For instance, if the system is processing raw documents the first step might be to extract all needed data from the document and enter it into machine readable form.
Two Life Cycle Perspectives
The above can be viewed from two perspectives: first from that of the item being processed, in which each item is treated as moving past a number of work stations with a definite start and a definite end to the flow. This is the straight line view of processing.
Processes can also be be viewed as on-going, processing many similar items on a continuous, almost circular basis. This perspective is the view of the processor, or person doing the work. Here the person moves from first station to last, and when the item is completed, moves back to the first station to begin work on another item.
Processes are both repetitive and continuous. To construct process flows, one must determine which tasks and activities can be collected into one process group or work station such that:
The effects of integration on process flows
As the level of integration of a system rises, its scope and complexity increase. In many respects however the reverse is not true. Many smaller limited user area systems may also be extremely complex due to the complex activities of the user area.
Much of the complexity is unnecessary and arose from the inconsistent development of the procedures over time. many procedures replicate activities for completeness, and redo work that has or should have already been accomplished.
In many cases work is performed in later procedures because it was not though of when earlier, and more logical procedures were designed. In some cases work is duplicated because work that should have been accomplished was not, or was not done correctly, or was done incompletely. In some cases duplication occurs to recreate intermediate work which was developed during earlier procedures and was lost when those prior procedures completed and discarded that work as extraneous.
In other cases complexity arises because activities are not smooth and continuous but rather a spasmodic and discontinuous. This lack of continuity between procedures leads to work which results from the shut down, or start up of discontinuous procedural processing, i.e. filing data away between procedures, retrieval of filed data at procedure start up. Simply put, many business systems are less like an assembly line processes than piecework operations.
New systems designs should at minimum remove these extraneous processing activities.
Organizational Orientation of Business Systems
Many existing systems operate along organizational lines. Because processing needs may not follow organizational structure, these lines may place restrictions on the design. At the framework level the design the design should ignore all such considerations and follow "logical" paths. in other words, activities should be performed in the sequence which reason and logic dictate.
Each business has a thread, or in some cases multiple threads which flow through it. These threads follow natural courses through the firm, or viewed another way, the natural course through the firm is dictated by the needs of the threads.
Most activities have an obvious sequence of occurrence. many times this obvious sequence is dictated by common sense. For example, prepaid orders should be handled before COD and credit orders, or orders on company supplied order forms should be separated from unsolicited orders on non-company forms (which need additional validation and editing). An order should not be accepted on credit unless a customer credit check has been performed, an activity should be completed before going on to the next station.
The business threads follow a physical thing, a document, a part, a person, etc. This thing may be altered, added to or deleted from, it may be copied in whole or in part as it moves.
If a document is duplicated and the copy takes a path of its own, both the path of the original and the path of the copy should be closely examined to determine the need for the duplicate.
In constructing these flows there are two ways to look at the environment. The first is to treat the tasks as dependent on resources and time. Therefore, a task performed is based upon available resources being properly assembled. The other way is to look at the task is to ask what cold and should be accomplished and what is needed to accomplish it.
Another question to ask is what is the most that can be accomplished in this activity before we must stop and wait for something else to happen.
In many ways this process is similar to a PERT/CPM problem, with the difference being that the tasks can be rearranged with somewhat more flexibility, since we are in the design stage. Activities can be rearranged to operational efficiency.
Recursive Activities
The difference between a PERT Chart (Figure 13-4) and a system design is the use of conditional activities and recursive or feedback logic. A conditional activity is one which is outside this stream but conditioned on some event in the stream. For instance, the requirements are to verify all customer information against the customer file. If the customer is not in the file then a separate branch or activity must be undertaken.
A form of recursive logic would be back order processing. When a back order condition is detected it is usually accompanied by an out of stock condition. Since all information for stock reorder is known at that point, we can automatically initiate or trigger a reorder process.
In developing the life cycles for a new system the deign team should note where processing must be different, that is, where original or raw input must be handled, at what point is it, can it, or should it be made similar enough for the various processing activities to be combined. This is the funnel effect. Processing efficiencies are achieved only where things can be made similar enough to be processed in a similar manner.
In most organizations the river of data is in reality made up of many tributaries and has many branches. This is similar to rivers where all flows merge into a common stream. Within the firm these common flows are continually branching into smaller streams, and remerging at later points.
To develop the processing streams, we can start by listing those things which happen in the order in which they happen, or should or could happen. We must identify each event as to whether it is dependent on any other process, and if so what. We must identify those processes which are time dependent and their actual start and actual ends. We must identify those which can happen concurrently, even of separately they are dependent on other processed.
We must identify first and last events, those processes which can be totally automated and which require human intervention, those processes with built-in time delays (and ask if they are necessary), we must ignore data considerations unless they are externally imposed.
We must examine the individual flows to determine where they can be joined and where they have commonality. We must determine where joining flows will eliminate steps, where rearranging flows and steps will eliminate steps, speed up processing and eliminate bottlenecks.
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.