BRYCE ON SYSTEMS
- It need not be as complicated as people make it.
I never really understood the hubbub associated with system design. People tend to look upon it as a complicated process. Actually it's not, yet the corporate landscape is littered with disastrous system projects costing millions of dollars, all because developers overlooked some rather simple principles for design and focused on technology instead. There are five easy lessons which can greatly expedite the development of any information system. To begin with, it's not a matter of following a rigorous set of instructions, but simply having a different perspective on information systems, to illustrate:
1. Information = Data + Processing
This is a simple formula involving two variables, data (the facts), and systems (how the data is processed). It also means there are differences between Information and Data, they are not synonymous. Data is nothing but the facts of the business; Information is the intelligence needed to support the actions and decisions of the business and, as such, it only has value at a particular point in time. Consequently, Data is stored, Information is produced. As an aside, there is little point in producing information if nobody is going to act on it.
All system design projects begin with a definition of information requirements, not hardware/software specifications such as "functionality." If information requirements are improperly defined, everything that ensues will be incorrect and a colossal waste of time and money.
2. An Information System is a product that can be engineered and manufactured like any other product.
All Information Systems consist of a four level hierarchy where the product is represented in various levels of abstraction, from general to specific. This is no different than an architect designing a building, or an automotive engineer designing a new car. This also means systems are designed "top-down" and tested and implemented "bottom-up." When the various sub-assemblies are designed, they can be finished separately. This means a system design project can be conducted in parallel with different parts running concurrently. This is clearly a departure from the "waterfall" approach which assumes systems are designed in a linear manner.
The system structure consists of: LEVEL 1, the System (the product); LEVEL 2, Sub-Systems (sub-assemblies represented by business processes used to collect data and produce information); LEVEL 3 (procedures, both manual and automated, interconnected to represent a flow of work); LEVEL 4 (steps for performing manual procedures, and programs for automated procedures).
3. Systems communicate through data.
Data is the glue holding systems together. It is the only way one part of the system communicates with another part, through shared data. By identifying the fundamental data requirements for the Sub-Systems at Level 2, we can then develop the business processes in parallel knowing they will work together at the end of the project.
4. There are logical and physical dimensions to systems and data.
Sub-Systems (Level 2) represent logical processing; it is what we want to do, and when we want to do it. Levels 3 and 4 represent physically "How" the Sub-System is to be implemented which is normally based on economics and available technology. Whereas the logical portion of the system will rarely change, the physical portions will change more dynamically. For example, consider Payroll Systems used in business, both commercial packages and in-house developed systems. All provide the means to collect data regarding worker profiles (salaries, hourly rates, deductions, etc.); time worked, vacations taken, overtime, etc.; producing the actual payroll, and; various government reporting tasks. How this is physically implemented though, varies from one package or system to another, yet they all satisfy the logical specifications. In other words, payroll systems have logically been performed the same way for many years, their physical implementation though differs significantly.
As another example, consider the various spreadsheets available (e.g., MS Excel, Lotus 123, Google, OpenOffice Calc); all fundamentally work the same but are physically implemented differently under the hood. How a system is physically implemented is of little importance if it solves the problem effectively.
Data also has logical and physical dimensions. A data element has only one logical definition (what it is meant to represent), but may be physically implemented many different ways. For example, consider the different ways time can be represented, dates, weights, money, etc., yet the logical definition remains the same.
Logical data models of the facts and events of a business (e.g., customers, orders, products, shipments, etc.) are required for implementation in physical file management techniques, including data base management systems.
As should be obvious, whereas logical information resources will remain relatively static, the physical resources will change dynamically.
5. Documentation is a byproduct of the design process
Just like an architect or engineer who produces a set of blueprints depicting the various levels of abstraction in their product, systems developers should do likewise. At LEVEL 1 of the system hierarchy, Information requirements are used to define the various sub-systems; at LEVEL 2, the various sub-system definitions, complete with inputs, outputs, and logical files, are used to define the procedures; at LEVEL 3, the procedure definitions, including inputs, outputs and physical files, define the steps for manual procedures and software specifications. At this point, LEVEL 4, there should be sufficient documentation for programmers to develop and test their programs.
This approach is no different than an architect completing the blueprints before laborers can begin construction. In systems, programmers produce and test each program; they then test the software as a string (Level 4); then test the workflow of the sub-system, including both manual and automated procedures (Level 3); then parallel testing of the sub-systems (Level 2), before putting the system into operation (Level 1). Again, you design top-down, test and implement bottom-up.
The point is, good specifications can improve programmer productivity far better than any tool or technique.
Yes, system design is actually quite that simple. However, people tend to make it more complicated than it needs to be. It's not a matter of lengthy instructions as embodied in a methodology, it's a matter of perspective. If you can accept the concepts embodied by these five easy lessons, you can build any information system. That's right, any.
For a free copy of my mini-poster on "Information Systems," see the "Bryce's Laws" section of my web page at:
http://timbryce.com/
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author: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 [email protected]
For Tim's columns, see: timbryce.com
Copyright © 2013 by Tim Bryce. All rights reserved.