Thursday, August 24, 2006

August 28, 2006


Back in June 1975 I attended my first systems workshop from Les Matthies, the legendary "Dean of Systems." Seems like yesterday. For those of you who do not remember him, Les came up through what was called the "Systems & Procedures Departments" of the 1940's and 50's. In Les' case, he was recruited by an aircraft manufacturer in the U.S. Midwest during World War II and was charged with establishing procedures for the production of aircraft thereby expediting the development and delivery of planes to the war front. Les was a quick study and was very effective in this regard. So much so, he went on to write numerous books on systems and "playscript" procedure writing. He also conducted courses on systems theory up until his death on December 31st, 1999.

During Les' courses he promoted the use of a simple "Grid Flow Chart" to track the flow of work between departments. This was a standard technique used for many years in systems departments. As the computer came in vogue, and different program flowcharting techniques were introduced, the Grid Flow Chart was eventually phased out. Regardless of how graphically elegant you thought the diagram was or wasn't, it was a simple and convenient way to express flows of work.

During the 1980's and 1990's, the emphasis was on "structured programming" and then "object oriented programming," and the concept of business process design was forgotten. Basically, the industry shifted its focus from Systems Analysis to Programming. Inevitably, the absence of "work flow analysis" (as it was once called) began to be noticed as software was developed that didn't work in harmony with the business. Consequently, "business process engineering" is being rediscovered by a new generation of developers.

The design of business processes was always an inherent part of the "PRIDE"-Information Systems Engineering Methodology (ISEM) since its inception in 1971. However, we referred to it as "Sub-System Design" (as we still do to this day). In the early days of "PRIDE," some customers liked to bypass Phase 3 "Sub-System Design" in order to get to the programming phases as soon as possible. Consequently, such customers ran into the problem of developing disjointed software out of step with the business flow. In other words, skipping Phase 3 would inevitably come back to haunt them.


Under "PRIDE"-ISEM, a sub-system is a business process that exists within a unique time frame; e.g., Daily, Weekly, Monthly, Annually, or Upon Request. This timing nuance is a recognition that business processes operate routinely in specific cycles. Further, it is a derivative of the complete specification of information requirements whereby information is needed by users in specific time frames.

For more information on "Defining Information Requirements," see "PRIDE" Special Subjects Bulletin #4 - Dec 27, 2004

There are three variables pertaining to timing:

Frequency - which specifies how often the cycle must occur; e.g., Daily, Weekly, Monthly, Upon Request, etc.

Offset - specifies when the time cycle is to begin; e.g., 1st of the month, end of the week, etc. As an aside, if the Frequency is 'Upon Request' there is no scheduled Offset (we want the information at any given moment).

Response Time - specifies the maximum amount of time to process the data to produce information; e.g., 5 seconds, 1 hour, 2 days, etc. Note: Response time is NOT a measure of machine throughput, although it will effect computer processing later on.

In "PRIDE"-ISEM we use these timing variables in a technique called "Chronological Decomposition" which is used to collect, store, and retrieve data in a timely manner, thereby keeping the processes synchronized with the data base. These timing parameters will also influence our method of implementation for the sub-systems. For example, if something is desired 'Upon Request' with a five second response time, in all likelihood we are probably looking at an interactive application. Conversely, a Weekly or Monthly process with a one hour response time might suggest a simple batch process. In other words, timing is a convenient means to define sub-systems and helps determine a suitable implementation of the business process.

There are basically three types of sub-systems: File Maintenance (to collect and store data in a timely manner), Produce Information (to retrieve data in a timely manner), and a combination of both (read/write). As sub-systems are designed, the data is organized into application logical files which are defined in terms of when they are Created, Updated, and Referenced (C/U/R).

The decomposition of a system into its sub-systems is performed in Phase 2 of "PRIDE"-ISEM. At this time, the sub-system is defined only in terms of logically "what" must be processed and "when." It will not be until Phase 3 when we will determine physically "who" and "how" each process will be executed.

Following the completion of Phase 2, each sub-system follows its own Phase 3 (Sub-System Design) where it is decomposed into the procedures required to implement the sub-system. Phase 3 is where the "work flow" of the business process is detailed in terms of physically "who" and "how" the process is to occur, from start to end. Here is where we prescribe the use of a "process diagram" to express the business process. Such a diagram (or a "Sub-System Flowchart" as we refer to it) can be drawn either horizontally or vertically depending on preferences. Either way, the diagram describes two things: the flow of work in the sub-system, and; the flow of data in the sub-system.

For the work flow, there are essentially two types of procedures involved: Administrative (the procedures people will follow) and Computer (representing the programs to be executed). Under the rules of "PRIDE"-ISEM, a sub-system can have one or more Administrative Procedures and one or no Computer Procedures (Yes, Virginia, systems can be implemented without the use of the computer). Systems will fail more for the lack of administrative procedures than they will for well written computer procedures.

In laying out the process flow, a line is drawn representing the flow of work with a "Start" to the process and an "End". Following the "Start", procedures are defined based on three constructs:

  1. Sequence - representing consecutive steps in processing.

  2. Iteration - representing repetition until a condition is met.

  3. Choice - representing a selected path based on a prescribed criteria.

This means a process diagram can be drawn as simply or as extensively as desired. For example, it is not inconceivable for a sub-system to have multiple "Starts" and multiple "Ends."

The other aspect of a process diagram is the depiction of the data flow as represented by the inputs, outputs, and files associated with all of the procedures and how they are used (C/U/R). This reinforces a basic "PRIDE" concept: "the only way systems communicate internally or externally to other systems is through shared data."

Earlier we mentioned a sub-system can have no more than one computer procedure. Let us not forget a computer procedure consists of one or more programs. Normally, there are administrative procedures before and after the execution of the computer procedure. As such, we must remember one characteristic of a sub-system: once a sub-system starts, it continues uninterrupted until its logical conclusion. We have been challenged on this rule time and again by "PRIDE" users. Perhaps the best example is a computer procedure executing routinely on a given cycle (e.g., daily, weekly) with seemingly no human interaction (for example, the computer procedure simply updates or backs-up files and produces no report). However, in this example, there is, in fact, an administrative procedure after all. Care to guess? A simple administrative procedure to trigger or kill the computer procedure. After all, it didn't initially startup by itself did it?

This "one computer procedure per sub-system" rule has been somewhat controversial over the years, yet we have never seen it fail in 35 years of "PRIDE." It also has an added benefit of providing a convenient means to document our current systems. By scanning our control language libraries we can detect our computer procedures and thereby deduce our sub-systems.

Regardless of the types of procedures available to us as designers, the Systems Engineer must ultimately determine a practical solution. Since the sub-system must be implemented by human beings (as well as the computer) considerable thought must be put into the sub-system's ease of use ("user friendliness"). Let us not forget an elegant solution that is not easy to understand or use solves nothing.


Back in 1979 we created an add-on to our "PRIDE" product line with a feature called ADF (Automated Design Facility) which we later renamed ASE (Automated Systems Engineering). ASE implemented the "PRIDE"-ISEM technique of "Chronological Decomposition" and could automatically design systems into sub-systems, procedures (both Administrative and Computer), and programs. ASE was most definitely NOT a program generator, but rather a systems generator. As such, it was a handy precursor for program generators as it would define inputs, outputs, records, and files, and then marry them to the various processes. Regardless, one of the lessons we learned in building ASE was there are some basic sub-system templates covering the majority of all business processes. True, designers can add or eliminate procedures from the ASE sub-system design, but the lion's share of sub-systems used in a business followed the templates.

The point is, a company should develop similar templates for use in designing their business processes. Such templates can save an enormous amount of time during a development project.


The design of business processes is hardly a new concept; the need for it has only been rediscovered. However, there are now several interpretations now on the market, some simple, some cryptic. Regardless, business process design represents the missing layer of development that was lost for a period of time. The main benefit of business process design (or sub-system design as we refer to it) is that it ties software engineering efforts with real-world use of systems, thereby making software more usable and minimizes the amount of development time lost on software that will not be used.

Although I find the current business process design renaissance amusing, there is a whole new generation of developers out there who have simply missed it. It is encouraging to see people rediscovering this lost and sorely needed talent. As Les Matthies was fond of saying, "Systems are for people." Remarkably, we lost sight of this simple concept. Hopefully, we are regaining our eyesight. I guess what goes around, comes around.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"Systems will fail more for the lack of administrative procedures than well written computer procedures."


We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:


The Information Week 500 Conference and Gala Awards will be held September 10th-13th at the Westin Mission Hills Resort and Spa in Rancho Mirage, California. For information, contact 877/449-5289.

The British Academy of Management will be holding their 2006 Conference at The Waterfront Hall and Hilton Hotel, in Belfast, Northern Ireland on September 12th-14th. For information, contact Clare Saunders in their London office at +44 (0)20-7383-7770 or visit their web page at:

The Society for Information Management will be holding their SIMposium 2006 on September 17-20 at the Fairmont Hotel in Dallas, Texas. For information, contact SIM headquarters in Chicago at 312/527-6734

Verify 2006, the International Software Test Conference, will be held October 10th-11th in Washington, DC at the Crown Plaza Hotel Crystal City. For information, call 703/725-3051.

The International Institute of Business Analysis will be holding their World Congress for Business Analysts (in conjunction with ProjectWorld 2006) on November 6th-9th at the Caribe Royale Hotel in Orlando, FL. For information, call 212/661-3500 x 3702 or visit their web site at:

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to


Folks, we've just released a new book on management entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

We have also just produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

While there, look for our new MS PowerPoint presentation describing both the book and the training program.


I'm curious, does anyone have a corporate policy on the use of iPods in the work place, particularly I.T. departments? The reason I ask is because I see more and more people plugged into iPods in offices these days. God only knows what they're listening to; I doubt if its Tschaichovsky or Beethoven. Probably some rap crap instead. I've talked about iPods in the past and discussed how they can have an adverse effect on a worker's productivity. But I'm not sure managers are paying attention to this; they're probably plugged in themselves and haven't noticed.

Now don't get me wrong, I'm a big believer of music in the workplace, but the volume and type of music is very important. Like it or not, music does affect our senses and concentration. As much as I like good, old-fashioned Rock and Roll, it is hardly the type of music I want played in the office. The same is true of rap and country. We may like such music personally, but I don't think it is wise to play it in the office. Instead, jazz and "easy listening" stations are probably better choices. The volume and tempo is not too distracting. In fact, I don't believe anyone really listens to "easy listening" music, and that is just the point. Its nice to have something playing in the background without actually distracting us from our work. Offices get hectic enough and some calm music in the background can greatly relieve the tedium.

Any manager who allows workers to plug into their own music is asking for trouble. Basically, they are abdicating control over their environment. Take back control; outlaw iPods in the office, and tune in some more suitable music for your workers.

Such is my Pet Peeve of the Week.


Friends, I don't know if you've seen it yet, but we've added a Frapper map to the "Management Visions" web site. Frapper is a free mapping service offered by the folks at Rising Concepts, LLC, and allows you to plot yourself on a worldwide map. This is a great way to keep track of our listeners and I encourage you to try it out through our web page or by clicking HERE.


I received an e-mail from a Jon Harris in New York who wrote me regarding last week's essay entitled, "Logical vs. Physical Design: Do You Know the Difference?"
Jon writes:

"How does logical versus physical design relate to application developers?"

Thanks Jon for your note,

Good question. The concept highlights the difference between programmers and Systems Analysts (or as are sometimes referred to today as Business Analysts or Enterprise Architects). Programmers deal with the physical world, analysts work in the logical world. As I've mentioned in the past, software exhibits some rather "hard" characteristics. Despite programming languages such as Java, software is written for physical devices. But one of the goals of a systems development organization should be to seek machine independence, thereby allowing them to move systems from one hardware configuration to another. This can only happen if someone develops a good set of blueprints beforehand, and this is primarily the job of the systems analyst. Think about it, systems analysts are analogous to architects and programmers are analogous to building contractors. The contractor cannot effectively do his job unless a good design is already in place. In the absence of an architect, the contractor is forced to layout a design, a talent they are not particularly suited. The same is true in systems development; in the absence of a systems analyst, the programmer is forced to layout a design, a talent they are not particularly suited.

This analogy of programmers to building contractors is somewhat controversial in that they see themselves as more free-spirited artists then blue collar workers. And it is not meant to demean programmers, but the fact remains that programmers work in the physical world.

Again, Thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."



Post a Comment

Subscribe to Post Comments [Atom]

<< Home