Archive
Functional Allocation IV
Part IV is a continuation of our discussion regarding the often misunderstood and ill-defined process of “functional allocation”. In this part we’ll, explore the nature of the “shallocation” task, some daunting organizational obstacles to its successful completion, and the dependency of quality of output on the specific persons assigned (or allocated?) to the task.
If you can find one, the process description of functional allocation starts out assuming that a human allocator is given a linear text list, which maybe quite large, of “shalls” supplied by an external customer or internal customer advocate. Of course, these “shalls” are also assumed to be unambiguous, consistent, non-contradictory, complete, and intelligently organized (yeah, right).
My personal experience has been that the “shalls” are usually strewn all over the place and the artifact that holds them is severely lacking in what Fred Brooks called “conceptual integrity”. Sometimes, the “shalls” seem to randomly jump back and forth from high level abstractions down to physical properties – a mixed mess hacked together by a group of individuals with different agendas. In addition, some customers (especially government bureaucracies) often impose some overconstraining “shalls” on the structure of the development team and the processes that the team is required to use during the development of the solution to their problem (control freaks). Even worse, in order to project a false image of “we know what we’re doing” infallibility and the fact that they don’t have to do the hard value-creation work themselves, helpful managers of developer orgs often discourage, or downright prevent, clarification questions from being asked of the customer by development team members. All communciations must be filtered through the “proper” chain of command, regardless of how long it takes or whether technical questions get filtered and distorted to incomprehensibilty through non-technical wonks with a fancy title. Bummer.
Because we want to move forward with this discussion, assume the unassume-able; the customer “shall” list is perfectly complete and understood by the developer org’s system engineers. What’s next? The figure below shows the “initialization” state. The perfect list of “shalls” must be shallocated to a set of non-existent product functions. Someone, somehow, has got to conceive of and define the set of functions and the logical inter-function connectivity that will satisfy the perfectly clear and complete “shalls” list.
Piece of cake, right? The task of shallocation is so easy and well described by many others (yeah, right), that I won’t even waste any e-space giving the step by step recipe for it. The figure below shows the logical functional structure of the product after the trivial shallocation process is completed by a robot or an expensive automated software tool.
Realistically, in today’s world the shallocation process can’t be automated away, and it’s highly person-specific. As the example in the figure below shows, given the same set of “shalls”, two different people will, “after a miracle occurs”, likely conjure up a different set of functions in an attempt to meet the customer’s product requirements. Not only can the number of functions, and the internal nature of each function be different, the allocation of shalls-to-functions may be different. Expecting a pristine, one-to-one shall-to-function mapping is unrealistically utopian.
What the example below doesn’t show is the person-specific creation of the inter-function logical connectivity (see the right portion of the previous figure) that is required for the product system to “work”. After all, a set of unconnected functions, much like a heap of car parts, doesn’t do anything but sit there looking sophisticated. It’s the interactions between the functions during operation that give a product it’s power to maybe, just maybe, solve a customer’s problem.
The purpose of part IV in this seemingly endless series of blarticles on “functional allocation” was to basically point out the person-specific nature of the first step in a multi-level nested allocation process. It also hinted at some obstacles that conspire to thwart the effective performance of the task of shallocation.
Trees
This tree below is my personal creation. You’re tree would likely be different than my tree. Nature creates perfect trees. Man tends to destroy nature’s trees and to create arbitrary artificial trees to suit his needs. Man must create, either consciously or unconsciously, conceptual trees to make sense of the world. How attached are you to your trees? Are your trees THE right trees and are my trees wrong? Are trees created by ‘experts’ the trees that all should unquestionably embrace? Who are the ‘experts’?
Creating the vertical aspect of the tree is called leveling. Creating the horizontal aspect of the tree is called balancing. Leveling and balancing, along with scoping and bounding, are powerful systems analysis and synthesis tools.
Analysis Vs. Synthesis
Everybody’s an expert analyzer. We slice, we dice, we evaluate and judge everything and everyone around us. “That’s good, that’s bad, you should’ve done it this way”, yada, yada, yada. Analysis is easy, but how many of us are synthesizers and/or integrators, CREATORS?
The problem is that we’re taught to analyze and critique from day one. We start with our parents and we are continually reinforced over time by our education system until we’re rigid adults who know how “things should be”. Over and over, we’re presented with something that already IS (like a circuit drawing, a business case, an a-posteriori historic event) , and we are taught how to criticize it and how to vocalize that “it should have been done this way”.
That’s too bad, because we are all born with the innate ability to be synthesizers, integrators, or in summary, CREATORS. We were born of creation, and thus we are creators. Sadly, we lose touch of that simple fact of life because of our inculcated obsessive infatuation with academic intelligence and the ego-driven desire to know more than “others”. Our western societies reward and glorify left brain “experts” and they shun, or even ridicule, wild-ass innovators and creators (at least until aftet they’ve died). Creators and innovators are often ostracized by the herd because they shatter the status quo and disorient us from the comfort of our lazy Barca-loungers.
The figure below shows the difference between analysis and synthesis (Cx = component x). In the analysis scenario, we are given something that exists and then we are asked to evaluate it, to determine what’s good/bad about it, and to develop ideas on how to improve upon it. In school, we are taught all kinds of discipline-specific techniques and methods for decomposing and breaking things down into parts so that we can improve upon the existing design. But analyzing the parts separated from the whole doesn’t get us anywhere because the whole includes and transcends the individual parts. By breaking the system apart we obliterate the essence of the system, which is the magic that exists in the interactions between its parts. Blech! Meh! Hawk-tooey!
The synthesis scenario is downright scary. We are given a novel problem, a bounded set of parts (if we’re lucky), and told to “come up with a solution” by the boss. Dooh! Uh, I don’t know how to do that cuz I wasn’t taught that in school. I think I’ll bury my head in the sand and hope that someone else will solve the problem.
Synthesis transcends and includes analysis. You can’t be a good synthesizer without being a good analyzer. You synthesize an initial solution out of intellectual “parts” known to YOU and then you analyze the result. If you aren’t familiar with the problem domain, then you have no “parts” in your repository and you can’t come up with any initial solution candidates. End of story. If you do have experience and knowledge in the problem domain, then you can synthesize an initial solution. You can then iterate upon it, replace bad parts with better parts, and converge on a “good enough” solution without falling into an endless analysis-paralysis loop. During the process of synthesis, you dynamically rearrange structures, envision system behavior, and iterate again until it “intuitively feels right”. All this activity occurs naturally, chaotically, at the speed of thought, and to the chagrin of the masses of Harvard trained MBAs, in no premeditated or preplanned manner.
Ultimately, in order to share your creative results with others, you must expose your baby for “analysis”. Now THAT, is the hard part. For most people, it’s so hard to expose their creations to ridicule and humiliation that they keep their creations to themselves for fear of annihilation by the herd of analyzers standing on the sideline ready to attack and criticize. It sux to be a synthesizer, and that’s why the vast majority of people, even though every one of them is innately capable of synthesizing, fail to live fulfilling lives. Bummer!
System Architecture Notation
For years and years, I’ve used the simple circle and square notation shown in the top half of the figure below in order to communicate (mostly to myself) multi-technology system designs. I did it because UML hadn’t been invented yet, and circles/squares were trivial to draw with any software drawing tool.
Now that UML has been out for quite a while, I’m gonna (try) and switch to the UML notation shown in the bottom half of the diagram. Even though packages and nodes are slightly harder to draw than circles and squares with most mainstream drawing tools, every UML tool makes it as easy as pie. Even Visio (my favorite engineering graphics tool) has templates for easily generating UML notation.
Contained And Container
In Russell Ackoff‘s excellent book titled Idealized Design , he talks about container and contained systems. He essentially states that optimizing the contained system without changing the container system is a failure in waiting. The figure below depicts what often happens when a change agent succeeds in improving the contained system without consideration of the container system.
At time 1, the change agent realizes that there is an efficiency problem within the contained system. After an epic battle against the forces conspiring to keep the status quo intact, he/she succeeds in smoothing out the operation of the contained system at time 2. However, since the container system was neglected, it still operates according to the old rules and interfaces of time 1. Thus, an impedance mismatch between the container and contained system interface has appeared. This impedance mismatch can cause organizational performance to be worse than before the change (the cure is worse than the disease) to the contained system!
In an ideal system change effort, both the container and contained systems are improved. Done correctly, a smooth and high performing system-of-systems, like the above model at time 3, can be achieved. Compare the smooth circular integrated interface at time 3 with the previous inefficient and cloudy interfaces of the previous 2 times.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 