Sandy Kemsley's Blog - Conway’s Law and End-To-End Business Processes
Sandy Kemsley

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

By Sandy Kemsley

Read Time: 4 Minutes

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:

  • Map out the high-level functional view of the process, similar to the order-to-cash process above, showing the functional blocks. This may be done through observation and interviews with people involved in the process, or may be done by process mining on direct measurements (system logs) to trace individual cases through the supply chain.
  • If you did the goals alignment exercise from my previous post, use the high-level business goals to establish KPIs for the process. For example, for an order-to-cash process, you may have KPIs such as customer satisfaction, time to complete order, order accuracy, returns, fulfillment cost, and unpaid invoices.
  • Identify a logical process owner – someone on the business side whose own performance is tied to the process performance – and task them with making the end-to-end process achieve its goals.

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:

  • Map out the processes in each of the departments in sufficient detail to understand how information flows within that department and between departments within the overall process.
  • Check what data is in each system, and how that data is shared between departments, e.g., direct integration or batch updates. A single data store is not necessarily the right way to go (especially for scalability), but systems need to be able to seamlessly access all of the information that they need to perform their part of the overall process.
  • Again, using the goals alignment exercise, establish KPIs for each departmental process that can be traced to the end-to-end process KPIs, and up to the overall business goals.

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.

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

Learn how it works

Request Demo

Confirm your budget

Request Pricing

Discuss your project

Request Meeting