Implementation
Human interfaces, which deliver products/by-products or enable self-service, can use variations of the layered architecture shown in Figure 7.1.
Figure 7.1. Product, by-product, and self-service interface implementation
This stack may be implemented with an Ajax-based app running in the browser (e.g. implemented with popular jQuery or Sench Touch mobile frameworks) and Java EE components on the server side, Jersey (RESTful web services framework) and Hibernate (persistence framework).
Figure 7.2. Product, by-product, and self-service interface (Java implementation)
Also, while keeping Ajax frameworks on the front end, one may implement the back end with .Net WCF (web services) and Entity frameworks (persistence).
Figure 7.3. Product, by-product, and self-service interface (.Net implementation)
A service request may be handled by a long-running business process and is asynchronously invoked by a program. This will result in the implementation shown in Figure 7.4. People don't normally place a service request directly. Instead, they use a self-service interface to create a service order and then receive the results of business process execution as part of another interaction.
The diagram shows that the coordination layer may communicate with both the human interaction layer (to perform human tasks) and the service interaction layer (to execute system tasks). Human interactions are mediated by a process portal.
Figure 7.4. Service interface implementation
In order to support a product interface, a unit manager schedules a business process to make the product (which could be a financial report, an ebook, a song, or any other digital artifact) before the SLA target time. This adds a scheduling layer to the stack as depicted in Figure 7.5.
Figure 7.5. Support of product interfaces
In the case when a business process is based on the event produced by another unit, the intermediation and mediation layers are added to the stack. Figure 7.6 shows an intermediator (message broker) and a mediator (service gateway) outside the unit's boundaries.
Figure 7.6. Event-driven implementation
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.