This chapter is from the book
This chapter is from the book
This chapter is from the book
How Do You Understand Systems?
Understanding a large and complex system is difficult. You can only understand it by controlling the amount of information you take in at a time.
Let’s leave the cavemen’s system for a moment and find an example in the twentieth century to illustrate. Suppose that you, a systems analyst, need to understand an automobile. Assume that you have only the most rudimentary knowledge of how a car works and that an expert is available to explain the car. Although cars are made of hundreds of individual components, initially you do not have to know anything about any of them.
In the beginning, the most useful information your expert can give you is an explanation of how the major components of the car interact with the others to produce the desired result. This means, of course, that the major components are fairly large things such as the engine, transmission, suspension, and body. For the moment, you must accept that each component works as the expert says it works, and not be concerned with how it accomplishes its task.
Once you understand the complete system in terms of the interactions between the major components-the engine powers the wheels, the body rides on the suspension, and so on-then you can begin to investigate how each of the components at this level works. Again, you must accept an explanation of the interaction between subcomponents, and believe for the moment that the subcomponents all work. Ensure that you understand this level of detail before investigating the subcomponents.
Each of the subcomponents is in turn broken into its subcomponents, and this partitioning continues until you arrive at a level of detail such that any component is so understandable you don’t have any more questions. Its function is obvious, or it can be described without benefit of any further partitioning.
How far do you go with the partitioning of a system? With the automobile example, you can continue dividing and subdividing until the components are single pieces of metal, or until you get to the molecules of the alloy, or perhaps until you reach the fundamental particles that make up the atoms. The answer is that it depends on your purpose when you study a system.
In systems analysis, we use the convention of head-sized pieces: pieces of the system that comfortably fit inside an analyst’s head and are readily understood. In the automobile example, the engine of the car is larger than head-sized, whereas the carburetor is just about right. For information systems, head-sized pieces are those that can be satisfactorily specified in a page or less of text description. These descriptions are called mini specifications, and they are the topic of Chapter 2.12 Mini Specifications.
The alternative to a leveled, successively detailed approach to understanding systems is too awful to contemplate. Suppose that in trying to understand the car, you started at the nuts-and-bolts level or the sub-sub-subcomponent level. How many sub-sub-subcomponents are there? Too many to let you easily understand how a car works. By starting at this level, you’d be swamped with details to the point that you’d probably never understand the system. The advantage of a leveled approach is that you move into the details as you choose. When you are controlling the amount of detail, you are far more likely to succeed with your goal of understanding the entire system.
Now look back at the cavemen’s hunting system. Hunting was just part of their lives. If you were studying anthropology and wanted to understand the ways of the cave people, you’d not likely first study their recipe for the barbeque sauce they used on the woolly mammoth. Instead, you’d first look at a higher level to study all of their activities: hunting, gathering, painting the cave walls, clubbing other tribes, and so on. Then you would study each activity that you identified. You would produce the hunting system diagram for study at this level, and then you might go on to look at even lower-level details, such as how they made their tools, how they mixed the paint for the cave walls, and so on. Eventually, by progressively descending into more and more details, you would capture all the activities as well as the links between them. This method is called a top-down approach.
Making Functional Pieces
The tactic of breaking large systems into progressively smaller components seems wise. However, you must ensure that you do produce useful components. There is little point in randomly chopping up systems in the way that Lizzie Borden partitioned her parents. When you divide a system, the resulting components must have some rational relationship to how the system works. In other words, each component must be a functional piece of the system.
How do you tell if you have functional components? First, a component is functional if it can be easily and informatively named, and if the name makes sense in the context of the system. Second, if you can honestly name a component using a verb and an object, it is a function. For instance, a name like SELECT AMBUSH LOCATIONS indicates that the component has a single function. It can be recognized by the user, and described by the analyst. A name such as PROCESSES BEGINNING WITH “M” does not pass the test and indicates that the partitioning didn’t produce functional processes.
We can also tell a lot about the functionality of a process by inspecting its interfaces—the data flows that enter and leave it. These flows should carry as little data as possible, and thereby make narrow interfaces.
Functional components need less data than do nonfunctional ones. Imagine the data flows for the two processes mentioned above. The data for SELECT AMBUSH LOCATIONS are reasonable (Figure 2.1.2). However, in any modern system, a process called PROCESSES BEGINNING WITH “M” would have an absurdly large number of data flows and, as a result, be meaningless to users. While functional components make narrow interfaces (alternatively, narrow interfaces make functional components), both are easier to get if you find the right places to divide the system.
)
Figure 2.1.2: Part of a model showing the data for SELECT AMBUSH LOCATIONS.
Cutting at the Natural Joints
Clearly, a woolly mammoth was too large to be cooked all at once, so the cave dwellers prepared it for cooking by cutting it into pieces. When they butchered the animal with their primitive tools, they cut along the soft natural joints, where it was easier to cut through than the hard bones. Similarly, many fruits, like oranges, provide natural seams for dissection.
The same is true in systems analysis. The natural joints in the system are along the narrowest interfaces, or where you find a narrow flow of data with two processes. If you try to divide the system by pulling apart functions, you’ll get messy interfaces. By partitioning where you find the data interface at its narrowest, you’ll deliver a model with functional components that are easy for the users to recognize.