The Order-to-Cash Process
A Case Study from the Tire Industry to Show the Use of Domain-Driven Design
A Case Study by:
Thierry Fraudet and Olivier Jauze
November 2021
Copyright © 2021, The Open Group
The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The Open Group, and may not be licensed hereunder.
This document is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to these publications; these changes will be incorporated in new editions of these publications. The Open Group may make improvements and/or changes in the products and/or the programs described in these publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of this publication may be downloaded at www.opengroup.org/library.
ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group.
Apache Kafka is a registered trademark of the Apache Software Foundation.
All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.
The Order-to-Cash Process
Document No.: Y212
Published by The Open Group, November 2021.
Any comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by email to:
Boundaryless Information Flow™
achieved through global interoperability
in a secure, reliable, and timely manner
Executive Summary
This Case Study is based on a real-world example to illustrate the use of domain-driven design and event storming in the context of Digital Transformation. It focuses on the tire production company, Michelin, and in particular the order-to-cash process.
Although the concepts presented in this document address the typical concerns that correspond to the order-to-cash process and a tire production company, they could be applied to different situations.
This work supports The Open Group Open Agile Architecture™ Standard application.
Context and Background
Several years ago, we revisited the information system that supports our order-to-cash processes. We used to have a legacy monolith (hosted on a mainframe) supporting most of these processes. We decided to adopt a best-of-breed approach, where several solutions were implemented to support the different parts of these end-to-end processes: from order capture to transportation optimization up to logistics delivery. This move helped us to:
• Source the best software to support a subset of our processes
• Start decomposing our monolith, enabling us to change parts of our processes at a difference pace
As soon as there are several systems contributing, a central component is needed to ensure the overall execution. In our case, a central orchestrator, a Business Process Management (BPM) tool, was used to steer the execution of these processes and deal with differing object granularity. This may seem like a minor problem, but we do not manipulate the same object all along the execution of our processes: a customer order may have three lines (one line per item) that will be split for transport optimization into four lines (for instance, one customer order line being sent in two truckloads).
The introduction of the orchestrator was also believed to be necessary because the team building the contributing applications had lost the knowledge of the business rules they had to implement, which manifested into the creation of a team in charge of the orchestrator to enforce these rules.
After several years, different issues were occurring with this approach, especially around the orchestrator:
- The orchestrator became a single point of failure. When it was down, it had a direct impact on deliveries to our customers.
- It became a sort of monolith, and was difficult to maintain over time. For example, there were around 20 processes deployed in this BPM engine and we could not modify some of them without having to retest everything.
Our Journey
So, we decided to rethink our architecture around the concept of events and their choreography, as we wanted to get rid of the orchestrator. The approach we took can be regarded as a recipe that we tried, but bear in mind that we do not pretend to be a three star restaurant.
We used the domain-driven design approach for this architecture refactor. We know there are different ways to practice domain-driven design depending on the state from which you start, and the assets you already have. In the following sections, we will describe the different steps we went through.
It All Starts with the Domain Boundaries
In this section, we discuss the order-to-cash domain and the definition of its boundaries (even from a very high-level perspective). The context begins with the capture of sales orders by customers and goes up to the payment of the invoice. The work group decided to take the processes as a hypothesis, to ensure we have the goods/products at the right time and at the right moment, and how to allocate our inventory to customers that were considered out of scope. These belong to other domains with which we have relationships.
An Event Storming to Discover the Domain Through the Prism of Business Events
The event storming practice is useful to explore and discover your domain. But in our case, even when we started by describing the process, our efforts quickly became focused on the information that was passed all along the process. Sharing the execution of the process made it possible to highlight the information granularity we had to deal with at each step, as well as the temporality of events:
- The order line created by the customer is not the order line we have to execute. Indeed, depending on where we source the products (which inventory warehouse), their availability, and the possible delivery dates, the quantity requested by the customer can be split into several lines, or even be reduced (the total quantity is not available for the date requested by the customer).
- A customer delivery groups together different lines of orders fulfilled by products leaving from the same warehouse, and for which we are committed to a delivery date.
- The reception at the customer’s premises is done at truck level, as we group different delivery lines into the same transport unit.
- A customer invoice groups together different delivery lines (not necessarily delivered in the same truck) with identical payment terms (with one or more payment dates).
- A payment groups together different invoices (total or partial) to be paid on the same date.
Figure 1 illustrates the different objects we are dealing with, their granularity, and how they are interconnected.
The granularity changes, along with their associated vocabularies (i.e., the ubiquitous language), helped the work group to decompose our domain into three sub-domains: Customer Orders, Customer Deliveries, and Customer Invoices.
Sub-domains often have dependencies, and so we defined for each relation which sub-domain is upstream relative to the other. The nature of the relation is also important, and to qualify it we used a strategic integration pattern. There are nine patterns in total but, in our case, we ended up using only four: Conformist, Anticorruption Layer, Open Host Service, and Event Published. The domain, along with its sub-domains for which relations are defined through integration patterns, forms a system context map. Figure 2 illustrates our case.
Figure 2: 0rder-to-Cash Domain
As you can see in Figure 2, not only do we have the domain described in the system context map, but we also find the teams realizing the domain – that is the team context map. Mapping teams is useful to identify any inconsistencies; for example, several teams working on a domain.
But Wait a Minute, you Mentioned an Event Storming and there are No Business Events Yet
Indeed, during the previous stage, we found ourselves describing the objects we had to manipulate as part of the process, rather than identifying the business events themselves. So, to complete the approach, we had to complete the event storming. Figure 3 shows the result of this session.
Figure 3: Order-to-Cash Event Storming
The red sticky notes represent the main business events of the domain, and visually you can see the sequence of events. You will also recognize two of the sub-domains that were mentioned before: Customer Order and Customer Deliveries. We have also grouped events by the applications receiving them.
You are Ready to Dive into Some Implementation Details
As event storming is used to discover and describe a business domain, it has very few Information Systems/Information Technology (IS/IT) details. So it is quite common to describe the events chain in a more “technical” manner. An IT event storming helps to highlight the information expected by each solution, the need to store this information or to request it, the data and Application Programming Interfaces (APIs) made available, and the events carried out.
Here, it is important to remember that our objective was to implement an event-driven architecture. It is quite common to rely on technologies such as Apache Kafka® to support it. One of the central concepts of Apache Kafka (or a similar technology) is the topic. It is the “container” in which you publish and consume your events. Figure 4 lists the topics we will be using.
The Final Step of Our Journey
We have a business domain decomposed into sub-domains and described through the main business events. The next and last step for us was to describe each bounded context so we know which events it receives and emits, which APIs it consumes and exposes, and which commands it executes. The Bounded Context Canvas (see Figure 5) is especially interesting as it also lists the domain entities or value objects it uses (using the domain “Ubiquitous Language”) and the “Business Decisions” (rules, policies, and decisions) it supports.
Figure 5: Order-to-Cash Bounded Context Canvas
References
(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)
• The Open Agile Architecture™ Standard, also known as the O-AA™ Standard, a standard of The Open Group (C208), September 2020, published by The Open Group; refer to: www.opengroup.org/library/c208
About the Authors
Thierry Fraudet, Michelin
Thierry has been involved in the IT Industry since 1992 in a wide variety of contexts and companies (from start-ups to large international companies), which has enabled him to develop significant experience and expertise in Information Systems Architecture as well as Software Engineering, from large-scale distributed information systems to embedded software.
Currently working as an Enterprise Architect for the IT department at Michelin, his main focus is to develop the long-term IT technologies vision, articulate transformation roadmaps, and deploy IT capabilities to support business strategy and innovative thinking. Prior to that, Thierry was leading the Lean & Agile Transformation. He has been named as a Michelin Fellow for his significant contributions to the transformation of his company. Since 2020, he has been a member of the Board of Directors of the Club Urba-EA, a non-profit professional association that aims to develop Enterprise Architecture practices in French companies.
Olivier Jauze, Michelin
Olivier is an IT Distinguished Engineer at Michelin with almost 20 years of experience in Software Engineering and Architecture. Passionate in finding solutions to users’ problems with technology, Olivier coaches teams in their journey to deliver incredible products and, for a couple of years now, platforms too. Involved in many initiatives around Michelin core business, Olivier is also working in the service & solution and consumer experience areas. Recognized as a disrupter, he is continuously pushing organizations to adopt new business models and new ways of working. Recently he worked on an open source project to help software architects dealing with today’s continuous nature of software delivery.
About The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 800 organizations includes customers, systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.
The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:
• Working with customers to capture, understand, and address current and emerging requirements, establish policies, and share best practices
• Working with suppliers, consortia, and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies
• Offering a comprehensive set of services to enhance the operational efficiency of consortia
• Developing and operating the industry’s premier certification service and encouraging procurement of certified products
Further information on The Open Group is available at www.opengroup.org.
return to top of page