Transcript
Chawla: I took a brief sojourn as a young kid into the finance business, and determined that that wasn't where I wanted to be. I had met a couple of people in the finance business that had some money. Back in the early '90s, when the internet looked like it might actually not just be an academic exercise, raised some money with a couple of friends, bought one of the first ISPs in the U.S. Joined another couple of friends, built Earthlink, which ended up being the largest ISP in the United States. It was fun. It was a great journey.
It was amazing to work on a lot of things we worked on. I always tell people, try not to be successful in your first two startups, because it colors your vision of what's to come next, because they don't always work after that. I've been in a lot of diverse industries. I've done a lot of consulting. I was at Thoughtworks. I've had a lot of opportunity to see all kinds of architectures and all kinds of situations, from small companies to some of the Fortune 5. The Ritchie Brothers journey was a really interesting one.
Introducing RB Global
There's a little subtitle to the talk, build things no one expects, in a place no one expects it. This phrase came up in a conversation about a year ago with a group of some of the folks at Thoughtworks that were still working on a project at Ritchie Brothers. One of them asked me how I had reached some of the success I might have reached in my career. I was trying to think about what that really meant, and trying to come up with a way to describe it. At least for me, the things that I've done is exactly that. Whatever the solution is, it's not what the solution somebody expected, or it was something no one was looking forward to.
No one had on their bingo card to build this thing. No one was expecting the World Wide Web in 1994, 1995, or building an architecture like we did at Ritchie Brothers, in an industry where no one expects that architecture. That leads into, what is Ritchie Brothers. We're the largest global auction marketplace in the world for heavy equipment, agricultural equipment, heavy trucking, things like that. Sounds boring, but it's actually really very interesting and a lot of fun. We have deep relationships across all these industries, and deep relationships with construction companies, large agricultural firms, and a lot of small businesses. Our customers range from very small family farms all the way up to major construction firms, or firms that rent and lease construction equipment and then move that to our marketplace.
Things about Ritchie in the plus column, the good things about Ritchie Brothers. We care deeply about our customers. When you think about our sellers, if you go to one of our live auctions or even look online, we spend a lot of time on merchandising the equipment that we sell. It's just a pickup truck, or it's just a large dump truck, or it's just an excavator. If you go and you see the care that we took in bringing that equipment in and cleaning that equipment and merchandising it and making it available to people. We deeply realize that a lot of these people that we work with, from a seller perspective, have built a firm as a small business or a medium-sized business that is their retirement, that is their assets. They don't have a pension somewhere. They don't have cash somewhere. They've got this equipment. They've reached the end point where they're going to go relax and go to Florida or go somewhere and be done.
We're there to get them the very best price on that equipment. That's what they deserve. That's what we want to care about them. When it comes to our buyers. We want to get them the best possible pricing. We want to give them accurate information. You're making a very large investment in a piece of equipment that you may only have a few minutes to inspect. We're going to give you a professional inspection. We're going to take a lot of time to make sure you understand what you have. Again, if you also aren't getting the best possible customer service, we're going to make sure you have that. We look at our business. We're a very white glove, very hands-on business on both sides of the transaction. That's a real positive for us.
On the not so positive side, or the, what's become difficult, or really, why are we here talking about this. Ritchie Brothers evolved into RB Global, and built that company through acquisition. We bought another company called Iron Planet, 7 years, 8 years ago, that helped us bring another way of being in the digital marketplace. They were very online at the point where we were very physically centric. Auctions were at an auction yard, an auctioneer calling out. Iron Planet was very digital. RB moved into the digital universe on their own. Actually, what happened is, you had those companies, now we have other companies within our sphere.
The integrations were never done. They were uncommitted. We would find ways to make them work. We now white glove our own internal operations. There's a lot of manual steps. How do I bring in a bunch of trucks that I'm going to sell, or a bunch of heavy equipment I'm going to sell? Some of it needs to get sold through the Iron Planet sales formats, and some of them needs to get sold through a local auction yard. There's a ton of white glove manual steps that go into moving everything from system to system. We call it doing arts and crafts.
How do I fake this process? How do I fake that construct? I asked one of our people, what's her dream for a successful integration? She says, I want to be able to do it from a dining room chair. I said, I don't understand what you mean. I don't want a swiveling office chair. I want a chair that doesn't turn because my office chair allows me to have three monitors, because IT gives me three monitors because I'm in three different apps all the time. I want a screen. I want a boring, just simple engagement. That's where we have that challenge of how to bring a better digital experience for our own customers, but also a better digital experience for all the people that were embedded in the company.
Architecture Perfect Storm
What did we find as we started this journey about 2 years ago? I came in, I was with Thoughtworks at the time. They came in and said, we want to do this digital transformation. We want to build a very large digital marketplace. We want to integrate all our companies. We want to do this amazing thing. Here's what we found. We call it the architecture perfect storm. If you look at across all the systems we had, there were at least three of everything. Whatever domain you picked, there was three of it: three merchandising, three this, three asset management systems, three billing. All the different pieces all over the place. What was maybe worse, was that each one of these was believed to have to be in sync all the time. We're going to talk about some of the models and things that we found. There was no system of record for anything in particular.
Even worse was all that interconnectivity. Everything's in threes for some reason. If you think about the modes of intercommunication, we had a really interesting combination of literal database sharing, Kafka and Boomi, between all the different systems, one of which could fail at any one particular time. We had what everyone was calling an event-driven architecture, through Boomi and Kafka, which is really data synchron, data propagation. It was not event-driven architecture. There is a long-standing teams chat, where there are a group of people, three and a half, almost four years ago that came together in a teams chat because they were noticing auction data wasn't propagating online between these two systems. We'll get in a teams chat. We'll bring people together when we see this, we'll be able to go and fix it. That was supposed to be temporary. It's four years. Sometimes people ask me what my goal is for this endeavor, and how do I know when I'm done? I shut that chat down. To me, that's a sign of success.
Technical Myth Understandings
Many technical myth understandings. Why does our electronic bidder number only have five digits? We need more digits. We run out of numbers. We had a reason. There was a reason. You talk to 7 different people, 11 different answers, why we have this. What happens if we change it? I was told if we change, this thing breaks. No, that's the thing that breaks. You're just trying to layer on layer and layer of puzzlement of how this even happened. My other favorite, so we can't schedule an inspection unless it's tied to an event. In Ritchie Brothers' domain language, an event means an auction. That's what that means. I can't inspect something if it doesn't have an auction as its destination. It turns out, we run a good business of inspecting equipment for companies, because we're good at it. They want to just get this item inspector to this fleet of excavators inspected, so they understand the value. They understand maybe what they have to do to fix them.
We have to literally create a fake auction in the system for that to happen. Events have IDs, which are all a small collection of numbers of sale ID. It's possible now to run out of spaces. It feels like I'm doing COBOL. I've run out of literal spaces to have an ID. Now they say, we got to get rid of events. This is going to be a major rewrite. The team that builds the inspection service says, no, it's not, we'll just take the events out. Everyone's like, what do you mean just take the events out? You told us to put them in. They're actually not necessary. We've been doing that arts and crafts for 4 years, and it wasn't necessary? Who said to put it in? I don't know, it's so long ago we forgot. I call this the cacophony of voices. There are many myths.
There are many people with a different version of the story. You've got a key system that we have that actually constructs the online bids. It constructs online listings by listening to five Kafka topics and hoping to synchronize them. When they get out of sorts, that's what we had before, year-long chat for. Haven't gotten to the point of just what if we had one. Timing. We have timing issues. We talked about the data synchronization. It's a big mess. It's just what I lovingly call right now, when we got there, was the architecture of errors.
The Architect's New Clothes
Here's the thing, nobody wants to point these things out. We're all going to make do. There was nobody before just raising their hand saying, this has got to stop, or this is the wrong thing. When you put people individually in a room, they would tell you, of course, this is nuts. I knew better than that. You couldn't go out and say that, because it would be very unpopular to say that, or this team might get insulted, or this boss did that before, and I don't even know who's responsible. We had to go through and peel layers of the onion off.
We got to the point where we just said, you know what we're going to do? We're just going to start with what we think the right way forward is, from an architecture perspective. We'll deal with these things when we get to them, because it was impossible. Six months of trying to understand everything, we realized we just had six months, we hadn't moved forward at all. We were just trying to understand. At some point you just say, we're going to approach this as if we were building it, and then we're going to see what we have to do as we walk through the system.
Time to Dig In - Building the Plan
What do we have to do to dig in and get through all this? The important part here, we had to understand the business model. There was a lot of people in our organization that wanted to treat this as an e-commerce exercise. There were comments of, we could extend Shopify. Shopify would work. Why don't we just do Shopify? Let's just do this. Let's do a simple e-commerce architecture. We're not e-commerce. There is no single thing that we sell that is identically the same as the other thing. I might sell a bunch of Cat 720s, but each one of them is inherently different. It has different hours, different condition. It's been used in different kinds of work. This one needs painting. That one is different. This doesn't have the same value. They're not the same thing. Our inventory is not acquired from a single source, like an e-commerce inventory would be. We have some inventory that's in our auction yards.
One of the things that Iron Planet specializes in is selling things at your location. You've got a big construction site, we'll sell it from there. You don't have to transport it to an auction yard. My inventory is distributed across the world. It's not identical. It doesn't have a common merchandising function or a common pricing function. It's not e-commerce. It's an online marketplace, though. There's domains that are similar to anything that somebody who's been in the space would understand, but it's not e-commerce. Again, part of that early discovery process was treating it like e-commerce and realizing we really had gone down a path where it just didn't fit. The architectures were not coherent. Again, at some point, you have to match the business model and step back. Something I always say, the architecture serves the business, not reverse.
First thing we had to do is start thinking about, what are the key domains in our system? What do we do? Effectively, at RB Global, we take something from person A and we facilitate a transaction to organization B. We collect money, we calculate our take, and we send the rest back to the other person. That's what we do. Ironically, it's a lot closer to a distribution model, or, as an ex-stockbroker, it's very identical to the finance model. I'm going to help you get this thing, and I'm going to take my slice, and I'm going to deliver it to you over here. You have to think about what those domains are and understand them, and really deeply try not to model something that doesn't represent your business. The other thing that we really discovered was, we were also in this transition to becoming a product-driven company. Really, what does that mean?
That was a very nascent journey that we're still on together. Having that connectivity with the business and helping the business change and understand, again, remember I talked about, we're very white glove, we're very manual. That's going to change. The business is moving. The business is undergoing change. The tech is undergoing change. Who is the translation unit between those? Our product people were the deep translation layer. One of the things I tell people is, when you're going to be in a product-oriented environment, when you're thinking about domains, when you're thinking about platforms, one of the things you want to think about is, what is your communication path between the business and your teams? How do your teams communicate with each other? How do you communicate with the business?
We leveraged our product managers within these teams, and our technical product managers way down at the deep technical levels to be that interconnection point. I would often say that we wanted our teams to be isolated and focused in their domain and their context. The product people were that little integrated circuit pin. There was one pin to that whole API, and they would speak to the other team, whether it was a business team, whether it was a technical team. The product folks helped us, along with our staff engineers, and the architecture team, keep that all in alignment, and keep it all driving towards the same end goal.
This is the key, we fought for radical simplicity. Everything we did at Ritchie is massively complicated. I often make this joke that if you're going from your main bedroom to your main bathroom, we would go through our neighbor's house. Every process we do is intensely complicated. How do we break it down to its most simplified process is a struggle. One of the things that we realized was, especially at the technical level on this, don't rush it. Incrementally think about it. I am very much an XP person. I always prefer code over documentation. This is one of those times when drawing it a couple of times was worth taking the time, before even coding it, sometimes. Just thinking about it. One of the things I like to talk about a lot, I think we need more thinking time.
I reference at the end of the presentation, there's a great YouTube video of Toto Wolff being interviewed by Nico Rosberg. Toto Wolff is the principal of Mercedes Formula 1 team. One of the things he says in there is, we don't take enough time, we have our phones. We don't take nearly enough time to just stare out a window and think. We are all so busy trying to accomplish things. What I tell people when it comes to architecture, when it comes to trying to simplify or organize complex systems, walk more, think more, get away from the screen, because it'll come to you in the shower. It'll come to you walking the dog. It'll come to you doing something else. The last thing is just question everything. You have the right as technical leaders to politely question everything. Are you sure I absolutely have to do that? Is that a requirement or is that a myth? Dig into it.
People always ask me, my CEO asks me all the time, how are we going to be done so fast? We're going to write less code. They look at you like, what do you mean? The less work I do, the faster it gets done. Can I get it done with that little amount of code? That would be a victory. There's also the, I spent this much money, I should get more. We're not doing lines of code. It's not Twitter. It's not SpaceX. We don't do lines of code. We do business outcomes. If we get the business outcome with the least amount of work, that's the win.
The last thing too, is that we really tried to value fast feedback. We built a lot of our architecture and our platform for the sole purpose of shipping every day. We can't always ship to production every day, but we ship internally every single day. Our product people get really tired of having to review code and review outputs every day, but that's what we do. Get an idea. How do we get from ideation to somebody's hands to take a look at, and get that fast feedback. Is this what you meant? Back to that old, simple process.
What Is Your Unfair Competitive Advantage?
One of the things we talk about a lot at Ritchie is, what's our unfair competitive advantage? I'm a big car racing fan. Gordon Murray is a famous F1 designer from the '70s and '80s. He's got his own company now, Gordon Murray Automotive. This is some slices of his new hypercar, the T.50. Professor Murray was the very first guy to just basically say, I'm going to put a fan on the back of an F1 car to get ground effects and just literally suck the air out of the car and have it go around the track even faster. The reason I bring this up is, as soon as he was winning everything doing that, they banned the fan.
That's not fair. We didn't all think of that. The rules don't ban, they will next year. For that year, they won everything. Not everything, but most everything. They were ahead of all the other teams because of that. Even in the world of tech, if you think of something and you can do something, somebody will catch up to you. For the time that you have that, figure out what your unfair competitive advantage is and dig into it as your business. What can you instantiate in your architecture that matches your business? It's unfair advantage.
Organizing the Complexity
I'm going to talk about organizing the complexity. I'm going to dig in a little bit to some of the basic principles we used here to get through all this. Borrowed this slide from my team at Thoughtworks. This is one of our favorite slides. If you look at the left-hand side, you see all the systems and all the complexity. Every system talking to every system. All the connectivity is really complicated. All the things are very spider web. What we want to do here is get to the right-hand side. Think about our key domains at the bottom. Think about our key APIs, our key services, our key systems.
How do we build something composable? How do we make clean interfaces between all the systems? How do we stop the data sharing? Is there one place that does asset management? Is there one place that does consignment? Is there one place that does invoices? Period. How do I compose them to build different experiences, whether it's mobile, whether it's an online external API, all of that composition, with clean boundaries. That was the goal. You want to think about retaining your deep knowledge. Are you going to move things to this new platform? Are you going to rebuild them?
In the amount of time we have, we have a lot to prove to both our investors, our board, our own company. We're not going to rebuild everything. There are systems that we can use and keep. Part of our first adventure in that multiple system universe was taking a lot of those multiple systems, and in their first year, getting it down to one. One thing that was responsible for this. In a monolithic world that we were in, sometimes that one system was actually responsible for eight things, but it was only one of them for any particular thing. Then we could decide, what of those pieces are we going to build an API around, so that we could keep them. Which pieces are we going to strangle out later? It's important in your architecture to know that and to be able to explain why you chose what you chose.
Because, again, the business elements of architecture, the unfortunate reality is, you're always searching for funding. You're always trying to get somebody to keep paying you to get this job done, or keep investing in it. A lot of these complex enterprise transformations or detanglements, they fail. People say all the time, why do they fail? My snarky answer usually is lack of executive courage and follow-through. That happens because you didn't give the executives the inputs to see that it was worth to continue to fund, so people say, "It never happened. I gave up." Which pieces do you move now? How do you think about your roadmap? There are things that we're going to use in 2024 that will be gone in 2025, but we're going to use them now. Again, think about the deep knowledge. Think about the things not worth changing. Make sure you mark them down and understand them.
I think about bounded context, and I wanted to find a nicer way to talk about that domain-driven design concept of a bounded context. Have clean interfaces around complexity. One of the best ways for me to explain this, relevant to Ritchie Brothers, is we have something we call our taxonomy. For us, what taxonomy means is how you organize all the different types of equipment we sell. We sell everything from small excavators to huge dump trucks, to Ford transit vans, to Ford F-150s. How do you organize all that data in a catalog? It turns out, it's mostly tree based, if you really think about it. Knowing it's a particular model of this particular Ford truck tells me something.
The things it tells me, for example, are its dimensions. It tells me how much its transport cost usually is. It tells me about its tax categories, which are very important, whether you're in the EU or in UK or the U.S. There's usually a lot of exemptions or different tax rates depending on if it's agricultural or if it's not agricultural. Is this piece of equipment a fixed agricultural unit, is it a mobile agricultural unit? At Ritchie Brothers, all that taxonomical information was actually distributed across the system in many places. As we were rebuilding this and thinking about, we have a modern tax interface now from Thomson Reuters to do the calculations, and it tracks tax exemptions. Where should the categories be? Obviously, the team building the tax system would have all the tax categories. That was everybody's first answer.
We said, no, that's actually not right, because what turns out happens in the taxonomy world is, the taxonomy is not fixed. It changes. We learn about equipment. Somebody sells a new piece of equipment. If you think of it as a tree, end leaves in the tree split into a node with two new leaves. If we're changing that taxonomy tree, then the tax categories change. If I had changed this, now I have to go change another system to correspond to this. If I keep the tax categories inside the taxonomy when they change, I may go to the tax team, they may actually program the facts into the taxonomy. They're not going to have to change data here and here, and hope that we both kept them organized and clean. That's what we mean about containing that blast radius of change.
We had one system that was responsible for one thing, as we go through this architecture. Think about which domain is managing for change, because, again, an exercise like this is a change management exercise. Nothing will be the same 2 years from now. As you start pinning responsibilities around things, you have to understand which system and which team is responsible for that ownership. Even if it's going to change, you know over time.
We also talk about decreasing the coupling between all the different systems and having a clean interface from that previous Thoughtworks slide. I'm going to try to give you a slightly simplified version of something we ran into. We found out we had a limitation on the number of items you could put on a contract for the seller. We dug into, why can you only have 100 to 200? If you have more than 200, the system just completely bogs down, and it takes more than 2 hours for it to generate the contract exhibit A that the customer has to sign, and they don't want to wait. We dig into that. That's not a business limitation. That's a system limitation. Why do we have that? Contracts and all the contract data is stored in salesforce.com. That's your CRM system. We had our asset management, we had our system called Mars, which is a big asset management monolith. We had all the contract terms and all the asset data in Mars.
It turns out, we synchronized the two of them. We would take all of the detailed asset data, ship it through Boomi to Mars, from Mars to Salesforce. Salesforce would recompute all the things we already knew about those assets to regenerate that PDF. Then, of course, the payout system would have to go to Mars in order to figure out what the commission was and the holdback rates and all the other things. It was a mess back and forth. When you think about it, though, what did our CRM system actually need? The CRM system just needed a PDF. It didn't need all that data.
All the customer needed to store in Salesforce was the PDF that listed all the things they were selling. That's it. When we refactor it, we say, we're going to build a contract service. It generates the PDF for Salesforce. It's a bidirectional. If you add more items to a contract, it goes to the contracts service. Contract service will return you a new PDF. Nice and simple. Thousands of items if you want them. No limitation anymore.
It's also where payouts now goes to get the commissions. Payouts no longer goes to that big monolith anymore to find out what the commission rates are. It goes to the contract service. One more thing out of the monolith and one less hassle for our people internally by sending stuff back and forth to Salesforce. Slightly oversimplified version of that, but by extracting that and understanding its domains and having the right responsibility just for contracts and item association, we broke through a major barrier for customer service, because now they can have many items. We have some sellers that will bring us 10,000 things, and we would have to open 1000 contracts. One contract now, much simpler for everyone.
Event-based architecture. At Ritchie, event-based architecture was an excuse to do data synchronization. There was, A, lack of consistency. B, massive payloads containing all the data. Yet mysteriously missing data, so not a complete payload. Now again, too, there's many forms of event-based architecture. You can get very complex CQRS. You can just get simple. What I always say in this space is, first of all, understand what model you're going to use, and then be as simple as possible. Be consistent. Think about the information you're sending as an API payload. If you're going to send a notification of change, "This change, go retrieve it." That API that you're retrieving, it should be complete. If you're sending all the data in the event, have all the data.
Our bidding engine is famous for sending winning bids. It has the winning bid, has the number right there. Just anyone want to guess what's missing from that payload? No, the number's there. The price is there. It's a global company, you know what's missing? Currency. One hundred and eleven what's? No, that's fine. Just go to the event and go look up the currency for that particular event. No, put the currency in there. No, just MapReduce it and just go over. No, just send the currency.
Everything in our system, and we modified it to go work on our new world, all the money is integer based, except our legacy which is all float based. When you do money, that's a whole nother heart attack by itself. Then you have currency. It gets crazy, but again, inconsistent payloads that make systems go talk to each other, we have an incredibly chatty system. Because you have to assemble so much information from so many places, just because it isn't well factored.
Talk a lot about communicating choices. I'm not going to go through this whole Wardley diagram. This was a key tool. This was a very early one built. We first started with some assumptions, but again, what was going to be things that we were just starting to think about? What deserved to be custom, what belonged to Ritchie Brothers and the way it did its business. What products could we go get, and what are commodities? Some interesting things that came out of that discussion.
We use Stripe for their payment APIs. We also leverage Stripe for money movement. We have a lot of rules in the UK and EU and the U.S., around what we call trust accounts. Certain states in the United States, if we sell a truck, the buyer paid has to go into an account that's only in that state before the money gets paid out. There are all kinds of rules. There's a lot of money that moves after the payments are made.
We use Stripe APIs for that versus manual entries in accounting right now. We could get that at a very low rate, negotiate a very low rate for a highly fiscally compliant and performant service. Why would we build our own? Same thing with taxes. Why build a tax calculation engine when you can get a global tax calculation engine off the shelf and rent it? We could help our board and help our leadership understand where we thought these things were. This diagram becomes a way of communicating. It also becomes a way of negotiating. Put that in Genesys, we'll deal with it later. Or no, let's go ahead and make that custom. I'm willing to invest in this.
Think about how you as architects are communicating your choices to your leadership so they understand. This is another example of that. This talks about some of the main business capabilities or domains that we have in our system. On the left, you see the things that we care about that we built on our technology infra environment. This is one way that we can communicate to our leadership, "This is what we're working on now. These are the different experiences. These are the different touchpoints." It's not an architecture diagram, but you still have to be able to take that. Remember back to that search for funding, that's also an important part of this.
Starting in the Middle
We started in the middle. Talk about the journey. With all that in mind, where do we actually start this process? We started in the middle, because it turns out, on the Ritchie Brothers side, on the Iron Planet side, some of the payment processing and post-payment processing was automated, not all of it. On the Ritchie Brothers side, there was no online payments at all. You got an invoice from a 25-year-old VBA based system, and then you called somebody to find out the wire instructions if you didn't already know them, and then you wired the money, or you walked in with a check. Everything that happened after that was mostly manual. There is an AS/400 sitting in a corner. It only does manual certain flat rate commissions. There was a group of people that would stay every night to make sure that what was in the AS/400 actually computed, and they would do that on spreadsheets. Why? Because we don't trust computers to do math, so we use Excel. That is the statement of the century.
We started with, we're going to automate this process of checkout. We're going to build a way for our customers to complete a purchase online: win their bid, win their item, and actually pay for it. Leveraging Stripe, we could give them an option to do ACH, because a lot of our customers, even the big ones, still pay a fee to do a wire. If we can use bank transfer, it saves everybody money. It gets a lot faster. We can do online credit card payments up to certain amounts. We do all of that, that'd be a much better experience.
More importantly, that manual process that we were using to figure out what we had to pay out to sellers, and figure that all out, was mainly a manual process. We have a certain number of days to pay our sellers, and so nowadays, with money earning even more money, that float, that number of days that we had was important. You can't monetize and buy overnight repos and treasuries on money if you don't know how much you're supposed to pay out, because you don't know how much you can make money on. You lose opportunity for float.
There were a lot of reasons we wanted to start in the middle. We did it wrong, and I think this is an important lesson in the process. I told you at the beginning, we do all that white glove service. With white glove service comes the famous exceptions. We do this, but unless the customer wants that, and then we do this. What about if they don't pay? Then, if they don't pay, we do this thing. Or what if they go into the yard and they say it's missing a key, there's no key for the excavator, so I want 50 bucks off.
Fine, now we have to give them $50 off. Or, this is a mess, can you paint it for me? Now we got to charge them. There were all these manual processes that we would do, and there were so many of them that everyone was so responsive to the business, we built a workflow that was basically managed on making sure all the exceptions worked. When we got to the end of that, and even started working on a pilot, the user experience for the customer suffered because we were thinking about exceptions instead of the customer.
More importantly, the accounting integrations weren't perfect, because we forgot the end in mind. The goal of automating a checkout, and of all this calculation and settlement flow was to get the correct entries in the finance system. For us, that's Oracle Financials. It doesn't matter which one it is. Getting the accounting entries correct was mission critical. If you're going to automate payout to customers, then Oracle needs an invoice in Oracle, in order to understand that and automate that whole process. We realized we'd gone off the deep end. We actually came and sat down with our team in the EU, and we learned about all the anti-corruption rules in the EU about immutable invoices, when people are allowed to get invoiced, when we trigger certain events in the workflow for VAT.
They were all remarkably straightforward and defined. It actually gave us a way to say, if we meet this high bar, and we define all the accounting and the logic for this high bar, everything else becomes easy. We went back and we refocused on, what does the happy path from, I won my bid, to the end of everything's in the accounting. I've paid for my stuff. I've got my invoice. The seller got their money. What does that look like in Oracle? Done. Figured that out, built that. What's interesting is now when you build all the exceptions, now when you build the $50 refund, or you build this, you build that, you have already defined what the end goal is supposed to look like in this system.
You can value check, did you do it correctly? It was a really important learning lesson for us to understand, really, what was the end, what was the happy path end in mind? Some of our integrations that are coming next are even more complicated. We have to go back and say, how do we know this worked? What's our actual acceptance criterion? Thinking about that as part of the core architecture was a real lesson for us. Again, back to radical simplicity. The point of this was to sell something from Tom to Fred, keep the money in between, and account for everything properly. We had to do that part and then do all the other exceptions later.
Platform V1, V2, and V3
Just some quick, high-level versions of what the platform looked like. When we started, we had Stripe and Thomson Reuters on the finance side. They were our finance partners. When we started, we had a Ritchie Brothers legacy website. We had our Iron Planet website. We started by building a standalone checkout experience and a standalone account management experience, and adding mobile to our checkout app. That wasn't perfect, and it would have been better to have added it to the existing app, but the legacy app also was a 20-year-old, unstable platform to work in. I talked about the spaghetti data flow. It was also very much in the middle of how all the things worked. It was a little dangerous at the time to play with it. To get ideas to customers, we actually built some standalone pieces, and then we built some core capabilities around contract management settling, settlement invoicing, all the things we needed to make that checkout work.
We got that working, and it was successful. Our customers liked it. It's rolling out now. In the process of getting it ready to roll out, we actually did build a unified new, modern website for RB Global. We got it off. Anybody remember Liferay? This was all 20-year-old Liferay with bad microservices sitting in Java, and all the old things. Now it's in a new, modern stack. It's a lot less in the middle of all the data transactions. That's where we are now. We're releasing all this with our new checkout system, which is awesome, and it's working. This is what's coming next, is to integrate Iron Planet with Ritchie Brothers. This is our next task that we're in the middle of. Really what we're doing is saying, we're not going to bring the systems together. What we're going to do is, Iron Planet sells things a certain way, Ritchie brothers sells things a certain way.
We're going to combine those ways into the new platform, so lift them both up to the new world. That means we have to change how we do consignment. It means we have to change how we track our assets, because we track different things between Iron Planet and Ritchie Brothers. All the things in that deeper orange color that changed, all got modified or getting modified, as you bring that integration together. Because we understand those domain boundaries, and we understand where we can change things or where things belong, it's going to be very much easier for us to move that stuff off the old monolith into here, because we have a known destination. We can have a test suite that tells us, run the characterization tests and understand that what we did in Iron Planet now works over here. Again, because the architecture allowed us to migrate that incrementally.
Beyond Architecture - The Secrets to On-Time Delivery
Thinking about what we did to actually get to delivery. Because delivery of all these concepts is just as important as organizing the concepts. We built a lot of what we call delivery infrastructure and tooling around engineering enablement. We did think about how we want to make a productized delivery platform. We built it on Kubernetes. We wanted to think about the same concepts that exist. How do we build a set of well factored APIs, or which of the Kubernetes APIs do we use for our developers so they can get through this process and have the least amount of knowledge about how to use a complex thing like Kubernetes and containerization? Jeremy had talked about taking your deep knowledge, and taking that deep knowledge and wrapping it up and making it simpler for another person.
It's a lot of what we tried to do here. We use a lot of the Kubernetes tools, such as mission controllers and operators to obfuscate even cloud provisioning. At Ritchie Brothers, if you want DynamoDB, it's a couple of entries in your Helm chart. If your team is allowed to have that, you have the budget, it'll show up for you. We don't make you learn Cloud APIs for Azure or AWS. We put that in the delivery platform. That deep knowledge that we've had, we built it into some very simple APIs, so our engineers are really effective. We can go from no team, to putting a team of people together and have them all ship to production in less than an hour. It's pretty cool.
The other thing is, I try to treat our engineers as our competitive advantage. It's been said a couple of times during the keynote, at the end of the day, this is still a people exercise. The folks that you have in your organization who have that deep knowledge of the people you bring in, they're all part of the people that are going to actually get through this slog and deliver all this. We focused deeply on investing in our own organization. Yes, we brought Thoughtworks in as a partner, but we also deeply invested in the people that we had, who'd been building monoliths, who'd been building code a certain way.
They had to learn a new way of working. We took the time to do that. We focus on joy as a metric, in the organization, we don't focus on productivity. I always tell people, my goal as an engineering leader is to create an opportunity for people to have joy every day from delivering work, because we all like to do that. We build the stuff, we want somebody to use it. We want them to have that joy of doing the job. We want them to be able to focus every day and not be disturbed. I was begging our engineering leaders not to wait for engineers to be dead before their art is worth money. Can we please get this out the door? Because people get really frustrated if they don't see their stuff hit the marketplace, if nobody sees what they did.
Then, other thoughts on maybe how you leverage your development partners through a process like this. We partner with Thoughtworks. We have other partners as well. Part of the entry criterion is, how do you create or uplift the environment that you're in? I'm not paying for more hands on keyboard. I'm paying for some specific skill, or I'm paying for an attitude, or I'm paying for a way of working. I'm paying for something. I want more ROI than just hands on keyboard, than just code. I want them to help create that environment, to help build that new culture that we're looking for. I always say, partner with a quality partner. Partner with somebody whose goals and culture and other things match your own. Don't just try to find somebody to type stuff.
Also, if you're going to be partnering with a partner in a complex transformation like this, mentoring is important. If you're going to bring people in who've done this, it's not enough for them to go into a room and do it on their own, because when they leave, you have nothing left behind. You have a bunch of code and a bunch of people that were separated. We have a phrase at Ritchie about, One Team All In.
We bring our partners in, they're part of our teams. We have a product engineering team, period, whether you're a partner or not. We don't exclude people from the process. When I got there, there were a lot of people that were the cool kids that were going to work in the transformation, and there were not the cool kids that were going to do the legacy stuff. How motivated was everybody? Not so much. The way we did it was very simple. We have a lot of pets, and none of them get to die right now.
Every day, somebody's got to feed the pets, and somebody's got to take care of the new pets. We're all going to shift, and we're all going to do some of it. It isn't cool kids versus the old kids. We're one family. We have to take care of everything we have. We consciously did that and even brought some Thoughtworkers in, they're like, why am I maintaining legacy code? Because it's your week. It's your week to take care of the old pets. It's just the way it is. There isn't cool kids and not cool kids.
When you think about a transformation journey where you're building a KPI in a capability platform like we are, there are some things I've learned over the years of doing this, and the things that get me really excited aren't always obvious. I watch across the organization to see if it's sticking, to see if the message is working beyond my own teams. We call them moments of serendipity. My product leaders, can I use that settlement statement API to take the settlement statements and put them in our external fleet management software so sellers using the fleet management software can see their payouts?
Yes, it's an API, use it. When you finally get somebody to say, I could use that API here, and I can use it here, that's fantastic moment. That's what you're looking for, because right now, you built them to do one thing, but you really want those to be multiple ROI type investments. You start to hear shared language. You start hearing people talking about the new provisioning domain or the new consignment domain, or they're talking about invoicing, and they're talking about it in a specific way that you're talking about it, and it's not just your team. That means you're getting that transformational knowledge out to the universe. People in your organization are thinking that new way. When you hear your business owners speaking in that language, you won. This one's the hardest one.
I'm not done with this journey here, and there's been a lot of slog in a lot of other places in this last point. Martin Fowler has written about it many times, moving from projects to products. This one is hard. We call it RB 2.0, that's the name of this endeavor. I always say, this is a transformational endeavor at Ritchie Brothers, at RB Global, to change our way of doing technology in the technology we use. It is not a project that will someday end. It is not a thing that will ship when it's done. It's not a thing you fund until it's over.
If you have invoicing for the rest of your business, you need to fund invoicing for the rest of your business. If it's important for you to have a catalog of the things that you're selling and be able to tell where they are in the process, then you will always need that, and it will not be done, and you need to fund it. It is a hard slog. Don't ever back away from this fight, because if you do, you end up with legacy software again. You end up coming back here, or some other poor side ends up coming back here. Because you're off doing something else, and now the stuff is worn out, and he's still doing it.
Key Takeaways
Set time to stare out the window. Just every once in a while, it's ok to think. I saw that Toto Wolff video, and I actually went and bought a chair for my home office. My wife says, what are you doing? I said, this is an official stare out the window chair. She's like, are you allowed to do that? I'm like, I'm going to do it anyway. Then, don't mistake action for results. Sometimes, the running around and the activity. Activity doesn't mean outcomes. Be really careful about separating the two of them.
Then, everything in architecture is about tension. I just told you to slow down. Now I'm going to tell you to go faster. One of the things I always tell my teams all the time, is an old Yogi Berra, great, nonsensical baseball coach from the States, but when you see a fork in the road, take it. Make a decision. We have a lot of people, whether they're executives or engineers, who are standing in the road.
The truck is coming and they're standing there like a deer in the headlights. Go left. Go right. It's code. What could possibly go wrong? You can change it tomorrow. Make a decision. Try something new. We have a lot of digital disruptors coming for us in the industry right now. They can move at that digital native speed. We don't have time for that. If you build a good architecture, you can experiment quickly. You can stay ahead. That's the argument here. Then the other thing is, just be a demon about removing all the friction from your value stream. Deeply think about what blocks you from getting from ideation to delivery.
Think about that, not just in your tech business, but work with your business leaders to understand what that means in the business. What are people doing right now that could be eliminated so we can make more margin and put people on smarter things? We all learn about value stream management. We all learn about those processes as engineers: educate the business. The last one, everyone can be a servant leader. It doesn't matter what your position is from an engineering perspective. You could formally be a leader. You might be an IC. These are things you can do. Everybody deserves to carry this process down the line.
See more presentations with transcripts
