Software for the finest computer – The Mind


Posted by Tim Bryce on April 6, 2015


– Five business process templates which accommodate most business processes.

To use this segment in a Radio broadcast or Podcast, send TIM a request.

When we developed our Automated Systems Engineering (ASE) tool (originally called ADF – Automated Design Facility), it forced us to fine tune our concepts for system design. It was based on our concept of “Information Driven Design,” meaning it could deduce a complete system design based on the Information Requirements of the user. If the requirements were incorrect, the design was incorrect. However, in the hands of someone who understood requirements definition, it could save them considerable time in either designing a new system, or documenting an existing one.

Based on requirements, ASE decomposes a system into its sub-systems (business processes), the procedural work flow for each, and determine what programs are necessary to implement the computer procedures (software specs). To do this, we determined there were three basic types of sub-systems:

* File Maintenance (aka Data Collection).
* Information Retrieval (queries in the form of reports and screens).
* A combination of both Maintenance and Retrieval.

This implies there are primarily two functions we can apply to files: Read (query) or Write (update).

One of the key design parameters was the timing of the Information Requirements. For example, the need for specific information on a daily basis, weekly, monthly, quarterly, etc., or Upon Request (aka “On Demand”).

To decompose sub-systems into procedural work flows, it is necessary to understand other properties, for example:

* All processing involves the use of transactions, either one at a time (such as to make a query), or volumes of transactions (such as “batch” processing).

* The workflow of a system involves the use of the processing constructs of sequence, iteration (repetition), and choice (branching). Further, the workflow has one or more “Starts” and continues uninterrupted until it reaches “End.”

Between the timing of the sub-system and transaction volume, we can make some assumptions in terms of procedural flow. For example, a sub-system needed “Upon Request” with a short response time (such as seconds) would inevitably result in an “interactive” sub-system; conversely, a daily or weekly process involving several transactions implies a “batch” process.

From these specifications, we can deduce standard business processes using templates. For example (Note: PROC = procedure):




PROC-2 – DATA CONVERSION – be it data entry, optical recognition, or some other form.

PROC-3 – UPDATE FILES – computer processing.

PROC-4 – REVIEW – to verify transactions were entered correctly (using a log) and implement necessary corrections.


Note: This is typically a sequential process.



PROC-1 – INPUT TRANSACTIONS, one at a time, through a screen. After reviewing data validation, either print, correct transaction, enter another transaction, or end.

PROC-2 – UPDATE FILES – computer processing producing data validation screen.


Note: This is typically an iterative process.



PROC-1 – INPUT TRANSACTION representing a request, one at a time, through screen. After receiving information, either print, make another request, or end.

PROC-2 – READ FILES – computer processing to produce information on screen.


Note: This is typically an iterative process.



PROC-1 – INPUT TRANSACTION representing a request, either manually or scheduled.

PROC-2 – READ FILES – computer processing to produce reports.



Note: This is typically used for such things as weekly/monthly payroll, weekly/monthly/quarterly/annual reports.



PROC-1 – SELECT ACTION AND INPUT TRANSACTION through screen. If updating files, review data validation, either print, correct transaction, enter another transaction, return to menu to select another action, or end. If querying information, either print, make another request, return to menu to select another action, or end.

PROC-2 – READ/WRITE FILES – computer processing to either update files or produce information on screen.


Note: This is typically an iterative process.

When designing sub-systems, an application logical data base is created to service the data needs for all sub-systems, not just one. Then, as the sub-systems are designed into procedural flows, the application physical files can also be deduced, including working and primary files. Also, inputs and outputs are deduced and attached to the various processes.

These five templates represent the bulk of processing in companies. There may be other types of sub-systems to manage the overall system or to handle files, such as file initialization, backup, security, migration (import/export), but these five templates can be used by any business. Of course, such templates are modifiable to suit the nuances of a business, simply by adding or removing procedures.

Pictorially, we flowchart the sub-systems and procedures using standard ASCII flowcharting symbols which depict both the processing flow and data flow.

Information Driven Design

This is all made possible by defining our terminology and concepts. Information Driven Design concentrates on the proper definition of information requirements. Timing will ultimately dictate how data will be collected and stored (availability requirements) and how data will be accessed to produce information. From this, we can deduce both processing and data requirements, thereby providing for design correctness.

When decomposing the system into sub-systems, the emphasis is to design backwards:

Information Requirements >>> Data Requirements
Receiver of Information >>> Originator of Data
Outputs >>> Inputs

Later, as the sub-systems are decomposed into procedures, the process is reversed. Here, the design expresses how data will physically be processed in order to produce information.

Source of Data >>> Destination of Info
Inputs >>> Outputs
Start >>> End

This is also true in determining the programming of computer procedures, from “Start” to “End.”

The required data must be defined in such a way that we can easily understand what primary data must be supplied by a User and what generated data must be calculated internal to the system. Data relationships can be extensive. For example, take NET-PAY which may be based on a complicated computation:


The data elements used in the formula may also be calculated, such as:


This means in order to arrive at the correct value for NET-PAY, we must be able to reach all of the primary values, such as HOURS-WORKED and PAY-RATE, in a TIMELY manner. If we cannot do this, NET-PAY will be incorrect.

Information Driven Design and the use of standard processing templates greatly simplifies the design of systems, thereby saving time on the critical up-front work that is normally overlooked. The result is a viable design of both the processes and the data. This approach is universally applicable and based on tried and proven approaches fundamental to sound system design.

The hitch though remains defining the information requirements properly. If they are correct, the design will be correct. However, if they are incorrect, no amount of elegant programming will correct a flawed design.

“Automated System Design: Fact or Fiction?”

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at

For Tim’s columns, see:

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  THE PROBLEM WITH DRUG NAMES – They certainly do not give us a clue about their purpose or use.

LAST TIME:  DIVVYING UP THE CHECK  – Don’t turn a pleasant evening into an accounting nightmare.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.


5 Responses to “PROCESS TEMPLATES”

  1. Nearing the end of my working career in the corporate world, I observed a situation in which decisions were made to “modify” an existing system to fit new system needs. That is something which has certainly been accomplished successfully in the past, but in this case, one large factor was ignored from the git-go. The original system was designed to track changes at the single event level. An example might be: a system which tracked maintenance dates and mileage on a vehicle but not the specifics of “what maintenance” took place. The business need of the client was not only to track the vehicle but also track the specific maintenace functions taking place at each maintenance event. Writing such a system from the outset works well because one is starting with a clean slate and then satisfying the business rules determined in the information gathering phase of the development. Modifying a system which was designed for a completely different purpose and level became far more complicated as the old system contained many limitations and a lot of “buried” business rules. The developers did not see it that way and could only point to the amount of work and money they would save in the “modification” versus “starting anew”. That premise proved “false” over time as the program developers became engulfed in the limits of the old structure and the stubborn business rules that it wanted to follow again and again. In essence, this program was born a “mule” and here were these developers attempting to turn it into a “cow” simply by attaching a set of horns. In the end, the customer got a marginally working model, the modification ate up oodles of time and millions of dollars rather than thousands, and the developers hid behind their desk and refused to take credit for a very bad decision made at the outset. Not only do we need a template for development but we also need a template to understand the limitiations of that which already exists. Good write, Tim!

    Liked by 1 person

    • Tim Bryce said

      Thanks Wayne –
      In order to modify an existing system, you have to document it (something most people do not like to do or ar incapable of doing so). However, what you are ultimately after is the data elements used and file structures. The processes can be easily changed, but it is the data which is of paramount importance.
      – All the Best,




  3. […] Process Templates – Apr 06, 2015 It’s All About Transactions – Oct 21, 2013 Logical Systems – June 16, 2014 […]


  4. […] Design” “Methodology Design 101” “Medical Records Interoperability” “Process Templates” “44 Years of PRIDE” “Information Resource Myopia” “The Systems […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: