Conway’s Law and End-To-End Business Processes

In my last post, I talked about the problems that can arise if you don’t have vertical alignment in your business architecture, namely, mismatched goals and KPIs at different levels in the organization. But you also need to be concerned with horizontal alignment: without responsibility for end-to-end business processes, no one will be taking care of customer satisfaction.

Many large organizations (and even some smaller ones) end up with functional silos in their business, with several of these silos required to complete an overall business process. Consider, for example, an order-to-cash process for handling customer orders:

These different steps are often performed by different departments, which in turn may have different and conflicting goals: Sales is attempting to maximize revenue, while Credit is attempting to minimize bad debt. In the absence of end-to-end metrics on the customer order process, each department will try to maximize their own goals without concern for (or knowledge of) the impact on other departments and the entire process. Each department just does their own part, then throws it over the fence to the next department and abdicates any responsibility for successful completion of the order; furthermore, they’re often proprietary about their data, and don’t want to share it across those internal boundaries.

Underlying all of this are the systems used to manage the process. Each of these departments may have their own system that is targeted at their part of the process, such as a sales automation system for Sales and an Accounts Receivable package for Receivables. These systems may pass only rudimentary information about the order on to the next system, so that Invoicing is missing some of the specifics of what Sales agreed with the customer, or Receivables attempts to enforce payment even though Shipping has not sent the complete order.

The result is that the end-to-end process isn’t really a process, but a disjointed set of operations that probably isn’t meeting your customers’ expectations.

This is a manifestation of Conway’s Law:

Organizations design systems that mirror their own communication structure.

In other words, if your organization is structured as functional silos with little interaction, you’re likely to buy or build different systems for each department that also communicate poorly. It’s difficult to change the systems to provide better interdepartmental data and process flows since you can’t convince departmental executives to spend money on something that doesn’t benefit them directly; and it’s difficult to change the organizational structure when the underlying systems manage and measure the work only on a silo level.

Note that Conway’s Law doesn’t state that the systems mirror the organizational structure, but rather the communication structure: the functional silos are not (necessarily) the problem, since they may embody specialized expertise that’s required to perform certain steps. Rather, it is the communication between those silos that makes the difference between organizations that have unhappy customers and inefficient operations, and those that focus on optimizing their end-to-end supply chain.

Fixing the communication between your functional silos starts with discovering your end-to-end business process(es), establishing goals for the process, and assigning a process owner to ensure that the goals are being met. Let’s look at some of the steps involved:

You’re then going to need to do some analysis of the underlying systems in order to fix some of the communication problems that exist there:

From this, you can start to (re)design departmental processes and systems that are aligned with the end-to-end business process to which they contribute, not just focus on local benefits maximization. The results may be unsettling: sometimes it’s necessary to deprioritize a department’s goals in order to achieve the highest performance for the overall process, and it’s usually necessary to spend some extra money on infrastructure to make all of this happen.

The end result will be a process of processes: the end-to-end business process (such as order-to-cash) with drilldowns to individual departmental processes (such as order fulfillment). Note that having a model of the end-to-end business process does not mean that the process is a tightly-coupled orchestration in the underlying systems: the actual implementation may be an event-driven choreography of microservices, or use message queues between business functions.

To drive acceptance of these changes, it’s necessary to gather operational metrics for the end-to-end process and make them available to the individual departments, with their own KPIs in context. That allows upstream departments to see the impact of their work on the downstream process, and measure everyone’s work relative to overall process success.