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