Unit Architecture

The main components of a unit are 1) the boundary, which enables its interactions; 2) business processes, which enable its operations; and 3) the controller that connects the two.

In order to design a robust and effective unit, an architect should follow a few key steps. To begin, determine the unit's customers, those who will interact with the unit by consuming its products, services, and self-service interfaces. Following that, construct the system boundary, which should consist of facades, with one facade assigned to each customer type. Reserve a private (operational) facade for the unit operators. Each facade should consist of human and system interfaces. Next, define the business processes that would support the boundary interactions. Lastly, schedule the execution of the business processes at required intervals to make sure that they satisfy the service level agreements attached to the boundary interfaces.

Let's consider the Accounting & Finance unit of a fictitious organization, Unsame Inc. Figure 5.1 shows that this unit directly communicates not only with the employees and two internal units (CEO Office and Sales & Marketing) of the organization, but also with two systems (Revenue Agency and Suppliers) outside of the firm.

Now we can take a detailed look at each element and the role it plays in the unit's structure.

Constructing a Unit Boundary

The boundary is the official digital perimeter of an enterprise unit, an interface that allows the unit to exchange information with the environment. Being the only visible part of the unit, a boundary hides its internal structure and protects it from environmental stress. A well-defined, robust, clear, and aesthetic boundary is what makes an organizational unit unique and competitively superior. A boundary enables continuous evolution of the unit and the creation of a culture of ownership and innovation.

Despite the many advantages that boundaries provide, between 80% and 100% of development budgets are spent on the construction and renovation of enterprise operations with very little left for constructing interfaces between organizational units.

One notable exception was Amazon.com's CEO, Jeff Bezos, whose memo was accidentally publicly shared by Steve Yegge, former developer at Amazon.com. Here is an excerpt from that blog post:

So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.

His Big Mandate went something along these lines:

1. 1) All teams will henceforth expose their data and functionality through service interfaces.
2. 2) Teams must communicate with each other through these interfaces.
3. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. 4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5. 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. 6) Anyone who doesn't do this will be fired.
7. 7) Thank you; have a nice day!

Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.

#6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Army Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word "hardened interface" a lot. Rick was a walking, talking hardened interface himself, so needless to say, everyone made LOTS of forward progress and made sure Rick knew about it.

Over the next couple of years, Amazon transformed internally into a service-oriented architecture...

A unit's boundary consists of facades. A facade determines the boundary between a unit and the entity (or a group of entities) it interacts with.

Figure 5.2 shows that the Accounting & Finance unit interacts with internal customers, including company employees, through the blue facade; with Suppliers, through the green facade; and with Revenue Agency, through the cyan facade. The gray is a private facade, which can be accessed only by the members of the Accounting & Finance unit.

Facades consist of human and system interfaces. The most popular types of human interfaces are web applications and mobile apps. System interfaces support both synchronous (web services, RESTful APIs, FTP, etc.) and asynchronous interactions (point-to-point and publish/subscribe).

Facade interfaces may be configured on a lightweight ESB (or a service gateway) that increases loose coupling by providing location transparency, transport protocol bridging, and message protocol conversion.

I recommend giving each control unit its own gateway. It's important to note, however, that a functional unit may configure its interfaces at any level up the hierarchy. This means that the unit's boundary can be projected to the boundary of any parent or grandparent unit in the hierarchy, including the organization itself.

A substantial difference exists between operational (private) facades and customer-facing facades.

Operational Facades

Operational facades help the unit's team perform work tasks. The execution of a task results in the creation, modification, or deletion of a resource owned by a unit. Operational facades are also used by unit managers to invoke business processes.

Customer-facing Facades

Customer-facing facades—no matter whether they are accessed by organization's external or internal customers—are used to deliver a product, provide a service, or offer self-service capabilities to the customer. A product is any digital artifact that can be prepared in advance and delivered to the customer immediately upon a synchronous request. A product can be a song, an ebook, a financial report, or a data feed. The latter, however, is a by-product, which is a secondary product derived from another business process. The dictionary definition of service is the action of helping or doing work for someone. A service cannot be provided without a customer's specification.

Self-service interfaces enable customers to not only do some valuable work (manage email, search the Web, etc.), but also conduct various fun activities.

In addition, customers can use self-service interfaces to create product and service requests (place orders) and make payments.

Governance Facades

Governance facades expose business rules and policies and can be used by all types of customers depending on access rights. These facades are most often implemented by control units. An example of a business rule exposed through a government facade interface could be a frequent flyer discount, trading limits, a customer transaction limit, etc.

Defining Unit Operations

Unit operations are defined and implemented as business processes. Wikipedia defines a business process as a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. Those structured activities or tasks could be performed by both human and computing resources. Business processes are long-running and may take hours, days, weeks, or even months to complete; the process state is mostly persistently stored in a database.

A business process that supports a product interface must complete its execution before customers begin sending product requests.

To support a service interface, a separate process instance will be invoked for each customer request. Another process instance(es) might be executed to conduct some preparation work before customers begin sending product requests.

Due to the fact that by-products are created as a result of the execution of other processes, they don't require business process support. By-products, e.g. historical currency rates, may require some formatting and are mostly delivered to a customer on a synchronous request.

Self-service interfaces also operate synchronously and don't require business process support.

It's important to note that process-centric coordination mostly occurs inside units. Organization-wide activity coordination is normally implemented as a combination of event-driven coordination between units and process-centric coordination inside the units. Figure 5.8 shows the Sales unit publishing an event to a topic hosted on the message broker. The Production, Distribution, Accounting, and Marketing units, who subscribed to that topic, receive a message and invoke respective business processes.

As a result of the completed process, each unit may also produce an event and publish it to the respective topic, which will also trigger business processes in the contexts of the subscribed units. This event-process-event pattern applied recursively in multiple unit contexts, produces an instance of a value net, something that is otherwise very difficult to capture in a single business process definition. The best way to visualize the value net is to create a unique token at the beginning of execution and pass it along with every message.