Control Unit
The obligation of any component is to contribute its best to the system, not to maximize its own production, profit, or sales, nor any other competitive measure. Some components may operate at a loss to themselves in order to optimize the whole system, including the components that take a loss.
I used yEd, my favorite graph editor, to generate a tree with node count = 16, max depth = 4, and max child count = 3. Exactly as I requested, yEd created a tree—a hierarchy structured accordingly to the Composite design pattern. Leaf nodes in the composition are UOA's functional units; composite nodes are the control units.
Figure 6.1. Organizational hierarchy
With just two clicks, those who don't like hierarchical layouts can apply an organic layout. Now the organization looks like a network with the control core and the functional perimeter. It doesn't change the nature of the organization though: it still remains a hierarchy.
Figure 6.2. Organizational hierarchy (organic layout)
Wikipedia argues that composite components: 1) implement methods to manipulate children and 2) implements all Component methods, generally by delegating them to its children.
UOA concurs with these and suggests that control units, while delegating work and authority to child units, are responsible for:
- Direction. A control unit ensures that its child units provide a means that directly support its ends. The means-end hierarchy of an organization determines its effectiveness.
- Coordination. Control units coordinate interactions between child units by providing intermediation (message brokering), mediation (location transparency, transport and protocol conversion), and governance services (policies and rules).
- Measurement. Control units collect relevant information about the child units' performance and conduct analytics.
- Control. Control units regulate the behavior of child units by providing either positive (reinforcing) or negative (balancing) feedback.
UOA suggests that control units should have the same structure as functional units. Even though control units have their own boundaries, child units might project their interfaces to the parent unit's facades. Needless to say, control units must run their own operations to fulfill the responsibilities listed above.
In real life, however, many organizations have organizational structure similar to that shown in Figure 6.3.
Figure 6.3. Real-life organizational hierarchy (antipattern)
Even with fair and competitive compensation, but with little information support, these art-style managers become so swamped and busy with work and responsibilities that they immediately begin hiring help, delegating responsibilities and distancing themselves from the problems. As a result, many companies quickly find themselves having a steep hierarchy, as depicted in Figure 6.4. Then, to find out why the company has become unmanageable, somebody brings consultants in who tell them that the organization must flatten its hierarchy.
Figure 6.4. Steep organizational hierarchy (antipattern)
Key Points
UOA creates digital constructs that provide interactional and operational support to organizational units. An organizational unit is a social system, which represents a social technology phenomenon programmed to some purpose(s).
UOA views the organization as an implementation of the Composite design pattern with every node treated either as a Composite (control unit) or a Leaf (functional unit).
Unit software must be as comfortable to an organizational unit as a house is to a family, a space station to an astronaut crew, or a battle tank to a fighting crew.
Each unit must have a formal [software] boundary, which represents a contract between the unit and other entities inside and outside of the organization.
Each unit runs its own operations implemented as executable business processes. Every process in the organization is owned by exactly one unit. A unit might engage another unit or organization to perform a task within the context of the process it owns.
UOA places a special emphasis on control units, which today often consist of just one or a few people, have inadequate information support, and, therefore, have become the weakest links in modern organizations.
UOA uses Systems Thinking for defining the problem, Organization Design for configuring both an enterprise and a composite unit, SOA for constructing unit boundaries, EDA for inter-unit communication, BPM for defining unit operations, and Business Rules for governance.