Unit Oriented Architecture

Reusability vs. Composability vs. Repeatability

Reusability is the capability of an object to be used again. For example, a screwdriver [] can be easily used by nearly anyone, including kids.

Composability refers to the capability of an object to work in different contexts. Unlike a screwdriver, which is very reusable, but less composable, a driver bit [] can be inserted (composed) into various machine and devices. Composablity requires an object to support some composition protocol.

Repeatability refers to the ability to repeat (replicate) the design of an object or a system.

While most companies focus on reusability, some use every opportunity to get the most out of composability and repeatability. Authors James Allen and Chris Zook conducted a multi-year study of more than 200 companies and published their findings in the book, Repeatability: Build Enduring Businesses for a World of Constant Change, which shows the value of repeatable business models. You can learn more about repeatability on their website.

I conducted a 10-minute comprehensive study on McDonald's to find out how well the company scores on RCR (Reusability, Composability, Repeatability). Among other results, the outcomes showed that McDonald's scores very high on reusability (customers successfully use, reuse, overuse, and abuse McDonald's stores around the world) and repeatability (consistent design and quality of products and services, uniformity of operations), but they score relatively low in composability. You can see McDonald's stores successfully composed into streets, malls, and plazas, but there are only a few in streetcars, trains, planes, submarines, and space stations. In fact, the company's RCR score of 200 (80+40+80) out of 300 is significantly higher than that of other companies in the sector.

Information technology is crazy about reusability, stays away from repeatability, and scores very low on composability. For example, if we consider human interfaces, they are easily composed into applications, but worse into portals and, especially, into business processes. Today, to make a modern application composable into a business process, one must:

  1. 1. Disaggregate the application into atomic tasks and make each task addressable.
  2. 2. Make each task accept input and return output parameters.
  3. 3. Develop a composition protocol.

It seems today is the perfect time to stop discriminating against human interfaces and begin treating them fairly.

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.

Further Insights