Standard System Structure
Submit Articles Back to Articles
"An information system is a product that can be engineered
and manufactured like any other product."
- BRYCE'S LAW
There has been a lot of discussion in I.T. circles the last couple of years
regarding system architecture, yet there appears to be general confusion over
the inherent properties of an information system. To some, a system is nothing
more than a collection or suite of programs. Computer hardware manufacturers
tend to believe it is either a collection of physical components or the
operating system itself. Data Base people think it is nothing more than the
interfaces to the DBMS. These are all rather myopic points of view and a source
of confusion to a lot of people in the industry, not just now but over the last
four decades as well. And if I.T. people are confused, imagine the effect on the
end-users who must work with the systems they produce. Fortunately, there is a
rather simple and proven solution to all of this; something that was first
introduced 37 years ago. Let me explain.
First, let's ask what type of system we're talking about; an irrigation system,
a communications system, a software system or what? If we are talking about
satisfying the information requirements of a business, than I guess we mean an
"Information System"; a systematic approach for collecting, storing and
retrieving the data necessary to produce information to support the business. So
far we have not addressed the method of implementation. Undoubtedly we will use
the technology of the day, namely computers, but we can also implement
information systems manually as well (and have for centuries). Does this mean
the design and development of information systems should be treated differently
to suit the technology of the day? Surprisingly, the answer is "No." But to do
so requires standardization of terminology and agreement on the fundamental
structure of an information system.
Taking a chapter from industry, we have always contended that an information
system is a product that can be engineered and manufactured like any other
product. This is a difficult concept for some people to grasp as information
systems tend to be much less tangible than other products, such as automobiles
or other mechanical devices. But if we can break through this barrier we can
make use of the same concepts as found in engineering and manufacturing.
Using this product orientation, an information system can be depicted as a four
level hierarchical structure:
LEVEL 1 - representing the system overall (the product).
LEVEL 2 - represents the sub-systems contained within the system. Each
sub-system represents a business process to collect, store and retrieve data
that is executed within a specific time frame such as daily, weekly, monthly,
quarterly, annually, or upon request (on demand). As an aside, "Chronological
Decomposition" is an effective design technique for specifying sub-systems.
Perhaps the best way of thinking of sub-systems here is to think in terms of
"assemblies" as found in manufacturing.
LEVEL 3 - represents the procedures needed to implement each sub-system. Here,
emphasis is placed on designing the work flow of the business process,
consisting of procedures implemented by human beings, office automation
equipment, and by the computer. The selection of technology to implement each
sub-system at this level should be based on what is cost-effective to implement.
Again, going back to the manufacturing analogy, procedures represent
LEVEL 4 - represents the steps needed to implement each procedure. For manual
procedures, specific actions and decisions are defined in terms of what the
human-being must perform. For computer procedures, the programs are defined in
terms of what the computer must perform. In manufacturing terms, this level
represents specific "operations" to be performed.
The glue holding this structure together is the data base representing the
standard and reusable parts to be used between assemblies (sub-systems). In this
regards, data represents the formal interfaces between the various parts of the
system. This is no different than how parts are shared and reused between
assembly lines in production.
This hierarchical structure is commonly referred to as a "four level bill of
materials." and offers many benefits:
* In terms of design, the structure is designed top-down, from the general to
the specific, yet testing and implementation is performed bottom-up, from the
specific to the general. This is commonly referred to as an
"Explosion/Implosion" approach to design and development.
* Designs are recorded using layered blueprinting to show the various levels of
abstraction in the hierarchy, for example, a system flowchart shows sub-systems;
a sub-system flowchart shows procedures; a computer procedure flowchart shows
programs. This approach is also referred to as "stepwise refinement."
* The hierarchy ultimately represents the project structure. Following
decomposition of the system into sub-systems, the project branches into separate
parallel paths to be followed. By doing so, the hierarchy ultimately represents
the road map for the project and, as such, provides the means for effective
estimating and scheduling. It also provides greater flexibility in terms of
deploying human resources to its development and allows for the completion and
delivery of some sub-systems before others, yet assuring everything will fit
* Because virtually any information system can be depicted using this model, it
provides for the effective re-engineering of sub-systems without having an
adverse affect on others.
This concept of standard system structure helps bridge the gap between system
architects and software engineers by using a standard model that is elegantly
simple and has been proven to work on just about every information system
imaginable. By using a standard approach to design, it materially improves
productivity simply by improving communications between project participants. It
also brings uniform consistency to the work effort. In other words, all parties
know where they stand in the design and communicate on a common level.
So you have to wonder why people in the I.T. field are trying to reinvent the
wheel when a practical and universal approach already exists. I tend to believe
the reason is twofold; first, because we live in a fast paced world of changing
technology where there is a tendency to resist standardization of any kind, and;
second, over the last few decades the industry has become immersed in
programming and has lost sight of total systems. Hacking away at systems one
program at a time obviously hasn't been successful, hence the renewed interest
in designing enterprise-wide systems. So, instead of other esoteric approaches,
how about a little commonsense for a change, such as thinking of systems as
products and designing them as such? After all, if it's good enough to build
just about every other product, why not information systems as well?
For additional information on this subject, see the "PRIDE"-Information Systems
Engineering Methodology (ISEM):
About the Author
If you would like to discuss this with me in more depth, please do not
hesitate to send me an e-mail at
Tim Bryce is a writer and management consultant located in Palm Harbor,
He can be contacted at:
Copyright © 2008 Tim Bryce. All rights reserved.
Follow us @Scopulus_News
Article Published/Sorted/Amended on Scopulus 2008-01-23 00:32:19 in Computer Articles