Walmart Inc. (WMT) Earnings Call Transcript & Summary

All right. Hi, everyone. Welcome back. I hope you enjoyed your break. We're very excited to welcome Navdeep Singh from Walmart. He's going to explore how Walmart is expanding their use of Camunda Platform to address core business objectives for their omnichannel digital experiences. Managing customer experiences and interactions requires Walmart to coordinate between front-end channels and distributed microservices. And without a central process coordinator, business logic ends up being spread in front ends and back ends, resulting in a lot of complexity and rigid systems. Navdeep will tell us what they're doing differently and better. Remember that during the session, you can ask questions using Slido. You can use your phone to scan the QR code here or you can go to slido.com and enter CCStage1. And hopefully, we will have some time for your questions at the end. Also, be sure to log into Slido if you just want to see what other people are asking because you can hit the thumbs up button to upvote questions that you're interested in. So be sure to do that. And with that, I am excited to welcome Navdeep, who will be joining us virtually.

Thank you very much. I appreciate the wonderful introduction. As mentioned, I'm Navdeep Singh. I'm from Walmart Global Tech, supporting digital retail services. And what I'm going to talk about today is how we are solving for omni and digital experiences in retail using Camunda as a platform. One second. Having some difficulties. There you go. Okay. Wonderful. I can see my side. That all helps. Awesome. All right. So for those that aren't from Walmart, let me give you a quick background. So Walmart helps people around the world save money and live better anytime and anywhere, whether that be in digital retail stores, online, through local devices. Each week, approximately 230 million customers and members visit more than 10,500 stores and numerous e-commerce websites under 46 banners in 24 countries. With fiscal year 2022 revenue of $573 billion, Walmart employs approximately 2.3 million associates worldwide. Walmart continues to be a leader in sustainability, corporate philanthropy and employment opportunity. As was mentioned, I'm Navdeep Singh. I go by Nav, keep things very simple. I'm a distinguished software engineer for Walmart. I'm currently leading the architecture for in-store services focusing on digital retail and fintech, which includes mining services, a suite of in-store associate-facing applications, of course, those that face our customers as well; prepaid and postpaid wireless sales; our auto care center; and of course, the platform which I'll be talking about today. I've been at Walmart for coming up on 3 years. And prior to that, I worked in financial services where I supported a number of digital transformations for the solutions which power the secondary mortgage market. First of all, I'll send a big shout out to all the outstanding individuals who helped to make this happen and who are continuing on this journey with me. Innovation, success are not possible without you. Second, I want to send an equal thanks and appreciation for all of you for taking the time out of your day, whether it be virtually or in person to be with me. I'm very humbled by your attendance and hope that what I shared today is useful and at the least spark some endogenic conversations. So what I want to cover today are several topics. First, I want to talk about our objectives for omni and digital and how they impact the retail experience. I'll talk about the impacts to our customers, their experiences, give some examples and then shift into what they mean for architecture engineering. I'll give an overview of our path to a platform with Camunda and why we're using this type of approach. After sharing some of the benefits we've seen, I'll provide an architectural overview, the role of process management and how we have engineered a comprehensive solution that addresses our core needs for omni, digital, our customers, including our in-store associates. Now when you think about digital business and retail, you immediately focus on the ways in which customers interact with your services and try to find ways to expand those experiences into new channels. It goes very simple. How can I offer my services to customers in unique ways that make their life easier and bring more value? Now if you add the word omni to that mix, the focus expands to connecting those solid experiences in each channel to one where the experience can interact with your services fluidly across all channels. These are some of the challenges at Walmart. The ways in which customers shop are changing. They expect more connected experiences when they interact with Walmart through the web within our mobile application and within stores. Before omni was a strategy, customers would interact with Walmart through the mobile app and the web separately. They were disconnected experiences. It did not offer parity and richness of features equally between them. Together with digital and omni, we needed to connect those experiences so customers can interact in near real time and through any channel with our goods, services and information, including product, marketplace offerings and their personal profile. At the same time, there are different segments of customers. Self-service and no-touch experiences allow very digitally-inclined customers to shop with us, while those who are less digital still prefer experiences with our store associates. Supporting all levels of omni and digital for our customers are critical needs so we can effectively and efficiently serve them all. For the more digitally-inclined customers, we are removing mandatory interactions with service counters so customers can have true no-touch experiences, can save time in the stores and could do more on their own by having a wide array of choices for how they shop. Our solutions need to address all these needs and do so in a way that doesn't introduce complexities that slow down our ability to deliver new features and products to all digital channels. Now let's talk about some examples. Simply put, customers either interact with Walmart goods and services anywhere, any place and any time. We need to be always on and ready to serve the needs of consumers, store associates and other direct users of our solutions. Now considering the shopping experience, customers should be able to start an order for an item online and come to the store and pick up right where they left off as opposed to starting over. Let's take the process of buying a wireless phone through Walmart as an example. There is a series of steps which involves capturing customer information, selecting phones and plans, checking eligibility, going through several approval steps and eventually having to activate a phone. If a customer gets happy to the process via our online site and is unable to complete the rest, they need to be able to come into the store, pick up where they left off and finish what they started without having to spend the energy and time to redo steps which were already done. Similarly, they should be able to create custom orders for items like cakes and paint and swing by their nearest store to pick up their items. Now as you may know, Walmart can get very busy due to its popularity. Making appointments or getting in virtual lines for in-store services like our auto care center for services like tire installations, and at the wireless sales counter, especially during promotions and peak times of the year, allow our customers to save time in the store, allows them to better plan their shopping experience, allowing Walmart+ customers to pay through our mobile app and exit stores with a zero-touch experience. Lastly, explaining how we can effectively assist customers in stores through digital capabilities like chatbots, live techs and allowing them to request personal help from an associate via the Walmart mobile application or by texting a specific number. These are just a handful of examples which we are now facing and are solving through innovations in digital retail. Now we've gotten a view into how omni and digital client retail and the demands which our solutions need to meet. Let's take a look at what happens to the IT landscape over time as new experiences are created, back-end processes need to evolve and scale and how both need to connect to offer compelling engagements with all end users. On the left side, we've got a clean architecture. Simplified view, but it's typical what you would expect to see with a single web channel. The UI is responsible for our presentation layer needs. The UI back-end processes all requests to and from the UI, and there's a service tier, which has all the business and technical services used to fulfill user requests and execute the business process. This is straightforward, common architecture. And hopefully, it looks pretty familiar. In this case, orchestration would normally be done by the back end because it must drive the user experience and deal with errors. However, there's likely to be some amount of orchestration, the service layer, along with state management being spread across the UI back ends. In a single channel case with a simple business process, these design efficiencies, if they do exist, won't be that noticeable. And the application can continue to evolve without a lot of attention on these items, and there will be little to no effect on timelines and the ability to double these product features. Now in an ideal case, the back-end business services have very well-defined boundaries, adhere to the single responsibility principle where they perform only the function they were intended to do, properly handle errors and provides results of the UI via its back end, where customers can be engaged through a crisp, clean interface as required by the associated business processes. Now in a real situation, these back-end services will include a mixture of micro, macro, menu services, composite services and include integrations consisting of choreographed interactions as well as those which were orchestrated. Now on the right side, we've got what typically happens when new customer experiences are added over time, when processes in the back end get more complex, need to evolve and be tailored their experiences and when the ways in which how we engage with customers change. New experience channels will have varying needs. Customer interactions on a mobile app for the same business process is different than the interaction in a retail store or through an e-commerce site. It's not just the look and feel. The sequence of steps that a customer takes with the business process may vary between channels. The information could be different. Some experiences are likely to have more options for customers than others. In the case of in-store services, the end user could be a store associate. Exceptional handling will also be different. Some experiences may be straight through, whereas others require long-range transactions or interrupt where process make it pause, stopped altogether or moved into needing to be handled by support teams. These are all variances in how the experience layer needs to engage with and manage the end user as it executes a consistent and standard business process behind the scenes. The business process may need to execute slightly different steps or be different order based on how the customer is being engaged. But it is not a different business process. It's the same one. With omni, there needs to be a way to stand up new experiences without having to create new and unnecessary services and layers, where there is no single responsibility for the business process, no ability to effectively manage state and avoid duplication of code that is embedded within specific channels. The spread of state management, process management, business rules and state management across all application layers has compounding effects. Without solving for these, resulting complexity slows down engineering, makes changes more time consuming and costly to make, and we miss out on important business opportunities. The net result to the customer is a poor experience where these needs aren't met. Now so what does this mean for engineering? How do we have to solve our products? When I first discussed what digital and omni meant for Walmart, I talked about connecting customer experience channels and the customer journeys. That's only a part of the problem. The other key aspect sits behind the experience channels as we just saw in the business service layer. How can we have functionally consistent processes that require orchestration of customer interactions through different experience layers with many back-end microservices where all the business logic sits? Without solving for this, business logic could spread between front ends, back ends, layers in between and new services. Solving for this means we need to address several things. First, we need the ability to engage a customer through any channel while having a well-managed and consistent business process in the back end. That means that no matter what channel service is offered, the process must be consistent while allowing for some variability to support customer interactions, which need to be tailored for a given channel. Second, we need a solution that can manage complex business processes which are implemented in a large set of back-end micro services. The interactions between these micro services must include orchestrated steps, choreographed ones, both normal and exception pads and needs to have a way to manage the customer experience such that they're -- we don't have to grade their ability to do what they need to do through whatever channel they choose. Let's take a simple example to see what that means. Customers can return an item in-store at the service counter, online through the web, from a mobile application and through curbside. No matter where a customer starts that journey, the returns process needs to be consistent across all those channels. There are slight variations in how those returns are processed based on product type, sales channel and the steps both customers and associates need to take. However, the returns process needs to be fully calculated, its workflow standardized and then offered through any channel. Customers should be able to start to return online and then complete it in any Walmart store. When a customer does a curbside return, the associate needs some experience where they can take those products, validate return and send them for processing, including returning payment through whatever tenders were used during the sales process. If a customer does return entirely from home, they need to get another experience, which allows them to furnish a shipping label, like a drop-off location or schedule a pickup, whichever method they choose. Decoupling the experience layer from well-encapsulated business process layer is what brings functional consistency. Without solving for this, back-end processes will become inconsistent over time, business logic will end up existing in all layers of the software architecture, UIs will become bloated with business logic and new layers will emerge to only fill gaps needed by a single channel. Over time, this is a compounding effect, which leads to complexity, inefficiencies and operational problems. We needed to enable the building of highly-engaging front-ends that are tailored to a channel and which are orchestrated against back-end process flows. We needed to be able to do this quickly. There should not be a long runway to be able to take a service that we offer in-store or in any channel and make it available on another one. If we don't have functional consistency, we have core duplication, inconsistencies in the business process and a high probability of conflicting business rules. If you put all these together, the result is high cost, high software complexity, negative impacts to performance and a poor customer experience. To address these needs, when building customer engagement layers, there needs to be mechanisms in place to deal with things like staple retries, service orchestrations and choreographies and managing distributed business transactions end to end, including triggering compensating ones to deal with business exceptions. These items can't be managed in the fronts ends. And without these capabilities, not only the customer experience will be poor, but there is likely to be resulting inconsistencies and inaccuracies in the underlying transactional data. So why are we taking a platform approach? What I've talked about so far is not unique to a single product or service. These needs are across nearly all our products and services in Walmart and digital retail, which need to be digital and omni-enabled. We have used this platform for different use cases and seen success. Taking a platform approach is delivered, it's strategic and avoids one-off and duplicate solutions, which address the same needs I've discussed. Duplicate solutions, as we all know over time, increase development and operational costs, which are things we continuously optimize to make sure we at Walmart have best-in-class, quick delivery and innovative solutions. It enforces a well-defined architecture that encapsulates business processes, abstracts front-end concerns and implements all the common plumbing our product engineering teams need in a single offering. Standardized API contracts enforce how the UI channels interact with all the back-end processes. It makes engineering easier so that developers can focus on their product needs rather than all the complexities associated with enabling omni and digital for their product. The platform is multi-tenant and allows for tenants to configure and develop their codes separately, which we wire in through a common CICD framework. Optimizing the developer experience is an important aspect when taking a platform approach and critical for speeding adoption. We didn't want to sacrifice on these and spent a lot of time thinking how to make engineering easier in terms of how product software's developed, integrated, deployed and operated within the platform. Last but not least, buildings as a platform gives high business value by speeding time to market for new capabilities and allowing us to deliver on the goals of omni customer experiences, which our business has established. We have seen cases where using the platform remove the need to create additional software layers and services that included additive business logic for a specific channel, dealing with process exceptions and interrupts or that orchestrate a series of steps independently from the end-to-end business process. So we didn't get here overnight. Getting to a platform took some iterations. It was done iteratively using a strong agile architecture practice, which included continuous improvement, building an innovation into our processes and managing technical debt so we did not get into a situation where major rework was required. From the very onset, we invested in strong CICD capabilities, standardizing API contracts between layers and taking feedback from tenants along the way. We started this journey in the transformation of our wireless sales platform, which I discussed with you before. The legacy platform had outgrown its initial purpose and grew complex over time. Workflows and business logic were spread between the front-end UIs, multiple back-end services, which meant that any simple change impacted all layers, was time consuming to build, test and deliver. There was no central process coordinator, no centralized state management, and exception paths were not always dealt with effectively. The resulting customer experience wasn't where it needed to be. Even simple changes took a long time and didn't allow us to meet demands of our business partners, allow us to implement features which wireless carriers were offering. We decided to build a new product and started by encapsulated workflows in a BPM engine, Camunda. Front ends continue to manage the orchestration experience layer, which resulted in them containing business rules, business logic and managing the state for wireless orders. We were able to achieve some efficiencies with this, but there continued to be no centralized state or process management, inability to effectively deal with exceptions during the sales process and complexity in all the layers have dealt with integrating with the wireless carriers in the back end. All these needed to be addressed to meet what we had started out to achieve for a true omni journey. Now the next thing we did was address the customer journey. Specifically, we introduced a new service in the architecture that abstract the information used to engage and interact with customers and associates from the underlying business processes. This new service decoupled the user experience channels from the workflow, which push all business logic in the back-end services with Camunda serving as a single engine for process management. This was pivotal in that it allowed our workflows to be omni but still have the ability for them to be flexible when needed by a specific channel, scenario or wireless carrier. Along with this new service, we created a standard business contracts between front ends to the business process and from the business process to all the back-end micro services. This last piece gave us the full benefits of decoupling, enabled us to make changes faster and without requiring code changes in unrelated layers. This is a point in our journey of achieving the functional consistency I spoke about earlier. We implemented specific patterns in our workflow definitions, which allowed us to enforce omni flows while having sub flows for steps that needed to differ. The other benefit we gained at this point was reusability, we used to be of workflows, UI aspects and underlying service tasks. Establishing business contracts meant that we could change any underlying micro service, including those which integrated with wireless secure APIs without the ripple effects in unrelated areas, which is something that we faced for a long time. We were now able to stand up new UI channels faster than we could do previously. Now in next evolution, we added efficiencies in our CICD processes with streamline deployment to each of the layers, added more automation, specifically in the areas of testing. During this time, we were launching the platform in retail, so we had to deal with new customer experiences that required managing long-run transaction. The sales experience in an online use case is different than in retail. Not only is the shopping experience is self different. But in stores, customers are with associates going through the sales process. There are steps that take much longer than others and need to be managed in a way which kept the customer engaged and informed of what's happening while back-end steps continue to process. We wanted to give our customers a browse-and-shop experience in our stores in retail rather than a straight through one, where they would just go through the steps of activating advice. We wanted to give the sales team at the wireless desk the tools they need in the experience layer and a slightly different process flow than what was online to bring that browse-and-shop experience to life. Lastly, we had to address retail resiliency, which was achieved by implementing what we call a ring architecture that limited blast radius in a significantly-improved scalability of the platform. This advancement in the infrastructure was a major extension and brought the needed sophistication to retail products. So platform is fully live, and it's being used to address omni needs for capabilities across e-commerce and retail. Because this is a strategic investment, it is managed as a product with its own road map, dedicated engineering team and a well-managed backlog of features. It's fully multi-tenant, offered as a Platform as a Service and in different deployment models. We can deploy it in a shared mode where underlying compute and storage resources are shared across tenants or we can deploy a tenant what we call an exclusive mode or tenants on the infrastructure and all its management. We are expanding capabilities such as access management as we scale it to handle digital use cases. We are also looking to iterate this architecture to support edge deployments in retail stores for the performance needs of more aggressive use cases and user experiences, which are driven by self-service and point-of-sale devices. All right. Now that I talked a lot about the guts of the architecture of the platform. Let's say what happened with it? Now these are the benefits of realizing wireless sales. We saw a 63% time reduction for creating a new single channel process for buying and activating a wireless device through multiple cellular carriers. The channel, in this case, was online through our e-commerce site. There's a 75% time reduction to implement a new cellular carrier process flow and a new retail channel. The same time, this time saved was largely due to a service task reuse as a business process was largely the same. Where needed, we added sub flows for only those steps that needed to differ. We saw a 66% time savings to add new medium complexity features that involved modification of existing flows from multiple channels. We spent 75% less time making low to medium complexity feature changes that also involve modifying existing workflows. All right. So what does this architecture look like? So I'm going to take you a walk-through through this architecture, focus on each element and trying to explain its role and purpose of the platform. Starting with number one, customers and store associates interact with their products through several channels, web, mobile, tablet and handheld devices. Some are more restricted in not only their resources such as CPU and memory, but the types of UI they can render. Meanwhile, some are richer while others are basic depending on what they are used for and what business processes are making available to that channel. They all share the common need of being highly engaging, performing and require the same rigor in terms of process and state management and dealing with exception pass. What makes things more complex is that some products are accessible to the public Internet, while others must be accessed to only via the store network. Latency and response times are big considerations. The platform itself does a couple of things. First, it enforces the role of having no business logic in the front end, including animate state management and workflow decision. Second, data that is needed by the UI is abstracted away, defined in templates and provide it as data payloads to the front end via a well-defined and standardized API layer. Depending where the request originates, the store network or public Internet traffic is routed and managed using firewall and API proxy, API Gateway rules. For retail scenarios, the originating store where the request starts is also a factor on how to route a request. In these cases, and because we need to optimize for performance, the platform charts traffic is in proximity-based rules, which ensure the closest cloud region serves request. Under the hood, the platform allows tenants to configure primary disaster recovery deployment clusters so the platform can route accordingly. All these traffic rules are separate from codes that could be changed without requiring a single push of new code. These are all design patterns, which are part of the ring architecture, which I've touched on earlier. Now number three, the core of the platform is the business orchestrator service. It is responsible for encapsulating and managing the business process from start to finish, including all normal and exception pass. This encapsulation forces a single responsibility for process and state management and eliminates the need -- the spread of both throughout multiple front ends and multiple back ends. The business orchestrators where tenant process flows are executed at run time and service tasks implementing all their underlying service interactions and related logic. Number four, all customer engagement channels interact with what's called the user cash proxy, which is responsible for abstracting information needed to engage with customers throughout a process and the underlying Camunda workflow engine in the business orchestrator service. The user cash proxy service ensures that all UIs are completely decoupled from the back-end orchestrations and choreographies and allows us to keep the UIs very light. In fact, it has no idea that workflow engine is even being used. UI payloads are templatized, stored in a back-end database and cashed at run time for optimization. This template approach makes adding or moving data required by user task straightforward and manage through configuration. The user task proxy also makes us so that front-end channels are completely unaware that our workflow engine Camunda is being used, as I mentioned before. It services as the back end of the front end and has a standard API interface. These boundaries are very deliberate and enforces responsibility separation, functional calculation and optimizes for change management. Now as shown on number five, certain actions such as overrides in stores require users with elevator permissions. These needs are managed through a separate authorization service, which matched roles to find in permissions unique to each product. These are stored as tenant configurations and retrieved during run time by the workflow. Returning to the returns example. When a customer returns an item, the UI channel goes through a series of questions about that item. Those questions then head to the back end where return policies are checked through rules. Eligibility is determined. If it is determined that an item cannot be returned, we can allow a manager to override that decision with certain guardrails. The associated UI needs to orchestrate new log in, validate the role of that user as being a manager and then ensure that the manager can approve the override and they have the right permission. Addressing a use case like this required implementing a security subsystem, which can work seamlessly with the workflow while integrating with enterprise IM solutions on the back end. Now business data, as shown on number six, for all the running workflows are captured by the business orchestrator service and continuously fed to tenant data stores using change fees. This allows the business to flow -- business data to flow freely during process execution to tenant domains. The platform allows each tenant to configure the change feed rules, including what attributes they need, source of target mappings and the frequency at which they want data to be set. This gets away from bulky ETL feeds into one where data moves as it's created at the point of transaction and during business processing. Now in the future, we plan to support different types of integration patterns such as data streaming. Number seven, the platform has standard operational dashboards and health monitors for instrumentation, alerting and performance management. These dashboards are standardized across tenants and give deep operational insights into workflows which are executing and enables creating customer alerts when things do not go as planned and corrective action is needed proactively as opposed to being reactive. Now core principle of the platform is that it will not contain any tenant logic. Tenants on their workflows, business rules and all configurations needed to run their process in the platform. The platform provides tools, configurations and common frameworks to optimize the developer experience, has standard pipelines and allow for streamlining certain changes but not requiring a code push. One core part of this entire platform was the tenant management aspect, and these are the items that we are doing to enforce that clean separation. Now tenants use modeling tools to create their workflows in BPMN. They own their business process, they own their business rules and their domain services. Tenants also create templates used by the user cash proxy service, which I discussed earlier. These templates are JSON structures that define UI channel payloads required to interact with the front-end changes and that are needed for the back end and our abstract UI channels for back-end business processes. Channels don't even know, as I mentioned, that our orchestration engine is managed in the back end. This allows us to keep user interfaces focused completely on UI/UX needs, making them very lightweight. Tenants are responsible for mapping their business data in the workflows to target databases where they can consume that data on a continued basis. Typically, for funnel analytics. Funnel analytics are business-centric dashboards and reports that provide tenants with the deep view into their business processes, allowing them to see business transactions going to their workflows, give them direct insight into both happy and exception path transactions. The business orchestrater also allows tenants to configure monitoring and other run time aspects. The near-term focus has been on operational monitoring of the platform. And as tenants expand, we'll be adding additional features such as tenant-specific dashboards, including usage of Camunda cockpit. That brings me to the end of my presentation for what I wanted to share today. Thank you all very much for your time.

That was great. Thank you so much, Navdeep. And we have a lot of questions from the audience. Honestly, maybe more than we can get through, but we will try. So to start off, for the omnichannel mobile app, is the customer able to see real-time data?

Real-time business data, absolutely. As we're going through the business process flow, the user task products I mentioned before, what it does is it provides that data back to the customer in real time. So they're not having to go and query to find out state. We can have that stake represent the right to the customer as they're transacting business with us.

Okay. Great. That's really cool. How long did it take to implement the platform and the first use cases that you were talking about with wireless sales?

Great question. So when I joined Walmart, my first charge was we have to address wireless. Whilst unbeknownst to me, it is a pretty complex business process, especially having multiple carriers. So the entire end-to-end for online use case took us about 9 months. Now within those 9 months, we had broken down the business process into steel threads that we delivered very incrementally. Again, this is very deliberate because we knew in order to achieve the end goals for the business, we had to have a foundation and runway in place so that as we added on more features and workflows, it became standard operating procedure as opposed to refactoring. The platform launch after like, as I mentioned in 9 months, we did take it into retail, which took less time, specifically 6 months. Because we already had workflows built, we were only changing aspects of experience, and we created sub flows for where it needed to differ for retail sales channel.

Okay. Great. So where do you place the business logic behind the data entry activity since no business logic is stored in the UI?

Yes. So. We do simple syntax validation on the UI. So what we don't do there are business policy rules. So for example, if we need to have data validated on the back end, all that's handled by the respective business service. If we're simply checking for things like nonempty values, those types of checks are done in the UI, but we do not have any sort of business rules that check for allowable values or it checks for cross-field attributions. None of that takes place. All that is done by the workflow engine. And that is also very deliberate. On one hand, you have to have some syntax validation upfront to make sure that you've optimized experience. But what you don't want to do is have business rules there because if you have multiple channels where you have to validate the same data, the business rules exist in the web channel layer or the UI channel layer versus being the back-end business process where it's consistently implemented across any channel.

Yes, that makes a lot of sense. So can you elaborate on what it means to orchestrate a front end with digital and omni aspects and give a few examples about how that's done?

Yes, that's a great question. I think wireless is a great example. When we talk about front-end orchestration, it's really going through a sequence of steps, user tasks or I should say user integration and system integration, we have to kind of connect it to. If I'm going to step by step getting information by a customer, in the back end, I'm doing all sort of validation of that customer. For example, doing account lookup, we already have an account with the wireless carrier. Are they eligible for an upgrade? And as we do those checks, we need to tell the UI what to do next based on how things respond. If we didn't have that separation, the UI will have to maintain the state about that order. You'll have to have rules to say what happens if a customer is not eligible. What should my accepting path be? What would happen if the data plan it's liking is not available in their region and those type of aspects? Like clean separation orchestrating a front end based on what's happening in the business process on the back end is what I mean when I speak about the orchestration.

Okay. Yes. That makes a lot of sense. And what is the architecture that's being used to ingest the change feed in the shortest time? Do you have any middleware integration in there?

Well, there are some components that we built. We have a change sheet processor, which basically it reads the metadata I referred to before or tenants configure. And based on that metadata, it then takes information from the workflow engine or the core integral databases and then to the tenant database that could take it. It's very lightweight. It's quick. It's not a lot of middleware integration.

Okay. Cool. So is the data already saved to the omnichannel database? Or is it on another system and then you have to ingest it into the omnichannel database?

Well, there is an omnichannel database. So the way to think about it, someone itself comes at the workflow engine, it's database because the workflow state is maintained there. What we separated very deliberately were business events, which was what we pass through the change feeds as well as the business data. So when I say business data, I give you an example in the context of wireless. It is a wireless order. That wireless order is separate from the workflow. The reason we do that is because when change fees capture every single event that takes place, there are business operations personnel as well as those in technology that need to see what are happening to orders to get in front of anomalies as they take place. That information is what's stored in a separate database, not a single omni sort of database.

Okay.