The system breakdowns for different project roles are also different, because “the system is in the eye of the beholder”: each breakdown, with its way of distinguishing from the world of objects of attention, is convenient for discussing some role concerns, and inconvenient for discussing others.
Systems are special in that for them the functional/role parts, product/module parts and allocations are the same, they occupy the same place in space-time, as depicted in the figure.
But if you start simultaneously to understand how such a system works (functional parts/components), what to make it out of (modules), how it is composed (places/allocates), it turns out that sometimes components, modules, allocations in it completely coincide (if they form subsystems—subsystems are systems, too), but sometimes there is no such coincidence—and intentionally!
Thus, TRIZ (“Theory of Inventive Problem Solving”) increases the perfectness of its systems by the fact that several different functions (remember: function is the behavior of a functional/role part of the system during system operation) were performed by a smaller number of structural parts—in a perfect system all functions are performed by zero number of structural parts (no module at all, but functions are performed!), TRIZ aims at this. So you can’t guarantee that the system/functional breakdown and the product/modular breakdown and the allocation breakdown coincide. In 9 out of 10 cases they may match, but you will have huge problems in your project with the remaining one case if you don’t consider it!
Components/functional parts should not be confused with products/modules. The role-playing Prince Hamlet should not be confused with the constructive Joe Shmoe, even if they are one and the same during the performance, they coincide 1:1. If you say “Your Highness” to Joe Shmoe backstage and say “How are your wife and children?” to Prince Hamlet onstage, the people around you will look at you strangely, and Joe Shmoe will be very puzzled in both cases.
We have already considered a teapot with only two products/modules (body and lid) and quite a few functional parts (reservoir, spout, pouring hole in the reservoir, reservoir handle, lid, lid handle, steam outlet).
It seems hard to mix up the functional and design parts in a kettle? Alas, it’s easy!
Let’s take a scissors example of what happens when people confuse the functional (role times, working with the environment) and constructive/product/modular (creation times, on which the software works) parts.
For scissors, engineers come up with different forms of handle and blade block, thinking of the handle and blade block as functional components. They discuss the handle and blade block as physically existing (the handle is held, its size and smoothness are counted, the blade block is cut—its strength and sharpness, opening angle are counted). If procurement managers perceive scissors as consisting of such functional components as products/modules, they will try to order handles and blade block manufacture separately: handles to a firm that understands ergonomics, and the blade block to a factory that knows how to make blades. Engineers would be shocked by this, because they start thinking of scissors for manufacturing and assembly purposes as consisting of modules/work products: two one-piece parts of specially shaped metal, fastened together by a screw. Only products/modules can be ordered, and the handle and blade block in scissors are only role/functional elements—no one plays their role unless there are products/modules assigned to these roles! Modules in scissors would only be the two halves of the scissors (and also the screw). If you make the handles and the blade block separately as modules, and then somehow staple them together, it would be bad and unreliable engineering. Here’s the scissors at the “how-to” moment (modular breakdown):
Managers at first listen to the arguments of engineers, but then… They look at the scissors assembly, see the handle and the blade block in action (operation, operations)—and then try to do something with them individually again, not in the moment the “performance” (when the scissors are assembled and working—cutting), but at the moment of production. For example, to divide the work on the handle and blade block assembly, although it is fundamentally impossible to divide the work on the handle and blade block when the halves of the scissors are connected with a screw. Or make a catalog of handles and a catalog of blade blocks and then try to force engineers to produce these supposedly “scissor parts” in the form of spare parts. The list of errors and misconceptions here is endless, and these errors will not stop: managers are constantly finding the “blade block” and “handles” in the engineering description and try to deal with them as assembly units.
The truth of the matter is that the scissors different design roles sees two different breakdowns: one of functional decomposition (“analytical”) and the other of product composition (“synthetical”):
The System-of-Interest is the same as a component and a module, but then the structure of components (functional structure, systems breakdown) and modules (modular structure, product composition, constructive breakdown) may differ significantly.
In the engineering modeling languages of the hardware architecture, as well as in the enterprise modeling languages, the functional and structural parts have different icons. If you don’t understand the difference between them, it becomes misleading to use these languages. If in project management you make schedules of module implementations and functional part implementations (in programming they may be called “features”, for example)—then they will be totally different, but both can make sense! The main thing here is the decisions of the creators of the system, which modular elements implement which behaviors/functions necessary for the system to work, so it is usually necessary to describe both functions (behaviors) and functional parts (role parts that perform the behavior/function), and constructive parts/modules/products, and where it all is placed (allocation). In complex cases, both functions (behavior) and functional parts (role objects that behave somehow) are modeled separately. In simpler cases, one makes do with either functions/behavior or functional/role parts—but never just structural parts/products/modules, for the “how it works” concern must necessarily be discussed, it cannot be omitted. “How it works”, the functional concern, is the primary concern in systems thinking!
*An excerpt from Systems Thinking course