"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 "subassemblies."
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 when completed.
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).
If you would like to discuss this with me in more depth, please do not hesitate to send me an
e-mail.
