It was late summer of 2020 when this reporter first met with Tim Daneliuk, who was at the time, Director of Architecture at Zoro.com. He had recently led the implementation of the first headless commerce project for the cloud-native B2B eCommerce company and had agreed to be interviewed about the experience for The MACH Alliance.
During the conversation, Tim stressed that Zoro was still at the beginning of its transformation journey. He made it clear that, while he was proud of what Zoro had accomplished, moving forward they planned to find partners to help them enable the full eCommerce buying experience.
Today, Tim is the Senior Director and Chief Architect of Zoro and works with both commercetools and DMI as vendors, with the latter partnering in the implementation. Just recently, the company went fully live with its MACH transition. While the system is still in the “hardening” phase, according to Tim, it’s already enabled the company to confidently move forward with its ambitious growth plans.
Tim graciously agreed to sit down with this reporter again to provide updates, share successes and offer a sneak peek at the next phase in Zoro’s commerce evolution.
A: Zoro was conceived by W.W. Grainger, a B2B industrial supply company that specializes in the global distribution of MRO (Maintenance, Repair and Operations) materials. Grainger is known for its high-touch customer service, direct sales force and super-fast delivery, all of which are particularly well-suited for really large companies and government institutions. About 12 years ago, Grainger leadership began to think about additional ways to deliver its product and envisioned Zoro as an outlet to sell directly to smaller-volume business buyers.
At the time, there wasn't a good B2B eCommerce solution out there as most players were B2C focused. So, the initial concept was for Zoro to be an eCommerce channel for goods Grainger already offered but under an entirely separate brand. The company already had a significant interest in a Japanese business with a similar business model, MonotaRo.com, so they used its website as a reference point, taking the principles they'd learned from that experience and even some of the code to create Zoro.
A: Plumbers, machinists, electricians, contractors, and factories will always be a core part of our customer base because of our Grainger heritage. For those customers, it's not always about the lowest price or the coolest product. It's about getting exactly what you need when you need it — because if a piece of machinery is broken and you can’t get the part you need, it directly impacts revenue. These are small businesses; they can't afford to be down waiting for parts or supplies.
As the Zoro vision has evolved, our customer base has expanded. We still have our core customers, but now we’ve expanded beyond MRO products and offer what we call the “endless assortment”. Our vision is that any SMB should be able to find everything they need to run their business on our site. This is literally true today. Not only can you get the lubricant that keeps your assembly line running, but you can also get everything from breakroom supplies like paper towels and hand-cleaning products to pallets of potato chips.
Our vision is to provide one-stop shopping with tens of millions of items a click away — we’re giving our customers a single place to shop, have their orders fulfilled and get great customer support.
A: The platform wasn’t really conceived for a double-digit growth environment. One of the things the IT industry struggles with in general is that, while we know how to describe what we want something to do as we spell out the requirements, we often don’t spend enough time thinking about “non-functional requirements”. The industry doesn’t often spend enough time on questions like, “How long will it take to bring it back online if it fails?” “How fast does it have to be?” “How much data does it need to support?”
These larger meta-issues around technology systems are really important. So, I would say the big challenge the company was facing was that stability and scale were going to be critical as we contemplated expanding from 4 or 5 million items to 20+ million and beyond while sourcing from thousands of suppliers. It was pretty clear the existing platform couldn't scale like that. The big expression of that was that customers were already waiting unreasonable amounts of time to log in, check out, and check their orders. The system was groaning under the weight of the work.
A: It was a little bit of both. It’s always been a cloud-only business; Zoro has never owned a data center. If you're delivering your business over the cloud, you’re really an integrator of cloud services. Today, we integrate services for tax calculation, clearing credit cards, taking orders, accounting, etc. So, the environment we had was a mix of third-party products that we had integrated and custom code that we built around it. At the center was a commercial ERP product and, at that time, it handled all the accounting and all of the logistics fulfillment, as well as the frontend eCommerce experience for our customers.
A: The growth rate was amazing. But, you can become a victim of your own success. Around the time I joined, the idea was, “Let's build a platform for the future so we can keep adding many, many different items.” And, as my team was working to do that, executive management came in and said, “Listen, we want to expand what Zoro is doing beyond just Grainger’s inventory. We want to build a platform that can support an arbitrarily large number of suppliers and deliver all of their goods as Zoro products.”
And, that’s exactly what Zoro is doing today. We’re giving customers one touchpoint to get everything they need to run their business and an entire customer experience that, from beginning to end, is with Zoro. Every item they buy is a Zoro product and for every customer service concern, they speak to a Zoro representative. No matter who the fulfilling entity is, they receive their goods in Zoro boxes with Zoro paperwork. We take on the burden of being the interface to the suppliers, from the initial search to placing items in their cart, having orders delivered and, if necessary, contacting customer service or returning items, every step is implemented through our staff here in the U.S.
A: One of the things I’ve learned over the years is to never build new IT infrastructure [i.e. microservices] unless you also have a business-critical application [i.e. guest checkout] that can actually use it when it's ready. It is the mission-critical, business-facing applications that create the demand for the evolution of the infrastructure.
I had just left a job where there was a lot of experience with microservices and I wanted to bring that to Zoro. The idea was to build a microservices-centric architecture and delivery organization because it was clear to me it was the direction we needed to go as a company. The thing is, you can enable a microservices infrastructure and then nobody does anything with it. So, our thought was, “Let's build the platform of the future because we know it will give us scalability and all the abilities that MACH promises but, first, let’s put a use case in place that shows this thing off and solves a real business problem.”
What was that real business problem? As it happened, executive leadership was eager to solve a near-term issue. When our ERP would go down, we knew nothing about our customers because all of the account information was in the ERP. So we said, “Well, when it’s down, at least we should be able to serve guest buyers because we don't have to look up anything about the customer to take a guest order.”
To do that required us to do a number of things properly — build a cart, price it, put taxes on it, apply promotions to it — and most importantly, protect the resulting order so that when the ERP finally came back up, we could resubmit the orders for fulfillment.
The guest checkout implementation was our first foray into headless and microservices and It proved we could take control away from the ERP. We learned how to build independent microservices to do cart, checkout, taxes and all these other things so that later, when we were ready to do the full authenticated experience, we were able to repurpose that same technology but with commercetools in the background.
That first project did three things for Zoro: It was a Trojan horse to bring in the next generation of technology for the platform of the future, it solved a real immediate-term business problem, and it served as a learning experience that paved the way for the full headless experience we have today.
A: The Executive Leadership's expectations were clear. “We expect this to work. We need this to work. The future of the company hinges on it. And, by the way, we're going to be adding hundreds and soon thousands of other suppliers, so it has to work at scale.”
Thankfully, we had tremendous support, and still do. My peers, the CTO and the president of the company, have all been extraordinarily supportive of this journey. I remember the president saying to me, “I know you're going to break some things. There's no way we can do this without doing so, just go break 'em fast and go fix 'em fast.”
It's unusual to find that kind of risk-taking in the C-suite. Even when we've had bumps along the way and struggled with some things, the executives above me have been nothing but supportive. It's been really great, actually. It is literally the case that, had they not been, we’d never have succeeded.
A: In building the guest implementation, along the way we also built a really experienced architecture and senior engineering team that hadn't existed before. We had great engineers, but there wasn't DNA around eCommerce and fulfillment architectures. We built the platform and the application in eight months and then hardened it for five, so 13 months notionally from concept to running, which is pretty quick — and another reason it was a little terrifying. It was, ”Okay, so let's run like our hair's on fire and see what we can do.” Many companies have spent 13 months just doing discovery work around microservices.
By the time we were ready to do this work for all customers, authenticated or otherwise, we had the architectural horsepower to do deep-dive research. The architects sat down, and one of them, our eCommerce architect, did a side-by-side feature and benefits analysis of all the major vendors. He'd had experience with other major platform choices so he knew what the other options offered. By that time we were microservices-centric and so when we looked objectively at what we needed and what fit our model best, commercetools popped out at us.
A: It's been good. We just went fully live as we didn’t do the fully authenticated thing all at once. We've been migrating onto it since the beginning of the 4th quarter of last year. We were adding 5% more users at a time — 5%, just to see how the system behaved under strain and under load. Again, our microservices and our APIs are in front of everything. Our customers’ browsers never talk to commercetools. They talk to our microservices via APIs. They talk to the world that we control. We use commercetools behind the scenes — it’s like the orchestra with Zoro as the conductor.
Shortly after we went live, we experienced a 24-hour problem with one of our core systems: a third-party product that is central to our order processing activities. Over the next 24 hours, our headless implementation, in concert with commercetools, protected many thousands of orders until the third-party reestablished ordinary operations. As far as I'm aware, no customers experienced orders lost and that speaks to the power of a headless architectural model.
Senior Director and Chief Architect, Zoro.com
We still have more work left to do, but the system has proven to be resilient. I think it just gets better and better from here — better monitoring and alerting, smoother operations, more automated tooling for resubmitting orders and that kind of thing. Of course, with commercetools as a partner, we certainly expect that, as we discover new use cases, we'll be coming back and saying, “Hey, what about adding this feature that we thought would be really useful to the system?” It's an ongoing conversation.
A: Not really. Headless did what it was supposed to do, what it was designed to do. I did live for a few days wondering, “Okay, all these orders are stacking up. Can we get 'em back out in time?”
Ultimately, I was excited and pleased, even if I was nervous for about 48 hours. The general sentiment around the organization was really positive from the GM's office down through the C-suite. At my lateral level, and among the engineers and architects who worked on it, people were walking around like proud parents thinking, “This thing really worked.”
A: Our customers come to us over a browser through an API gateway — it’s MACH architecture from tip to tail. That API gateway dispatches the request into one of our microservices interfaces and APIs actually orchestrate and manage carts, orders, promotions, taxes, etc.
In turn, our microservices talk to commercetools. commercetools actually keeps track of the orders and the carts and all of the intermediate states. The other thing we're making use of is something a lot of commercetools users don't use — the Custom Object, which allows us to design anything we want in commercetools. We use Custom Objects to allow our Net 30 customers to look at their invoices and pay them. It’s not an out-of-the-box functionality of commercetools, but we were able to create the feature because of this extensibility.
A: Well, I think we could have done all of these things ourselves but it would've taken a lot longer. The engineer in me wanted to build this thing internally — so did many of the engineers. But at the speed we were running, we couldn’t afford five years of development work when our core business isn't building headless systems.
It was prudent for us to buy commercetools as an accelerator into the marketplace to get us where we needed to go. I suppose everything we did could have been done on our own, but it wouldn't have been very economical and it wouldn't have been very fast.
Senior Director and Chief Architect, Zoro.com
A: Well, that’s the selling point of a monolith, it’s plug in, turn on, and play. If this was a small business, say $5 to $15 million, there's no way we would do it this way. We would go to a company that has an off-the-shelf solution that already has plug-ins for eCommerce, order-to-cash, taxes, auditing, fulfillment and record keeping. This is more-or-less how Zoro got started.
However, the issue is one of scale. When you double in size in five years, the monoliths show their limits. It's not even that they can't scale efficiently, they just can't keep up, period. Our real driver was, “We need to build a durable system that is elastic and can grow as the company moves towards 2 billion and later to 4 billion.” That's really what we were thinking about. We weren’t just thinking about the next few years but the next 10.
A: We were pretty far down the path with making the decision to move to commercetools. We knew from the beginning that it's always better to have expert help. Through a variety of mechanisms, we checked out the significant experts in commercetools’ implementation. It was a normal vendor selection process. We got to know the folks over at DMI and were not only impressed with their experience but their approach to how they work, how they wanted to work with us, and how they saw us partnering.
It’s been a rich, healthy relationship. From my point of view, whether work is being done by a DMI person or one of our people, the experience is seamless. One of the great things about DMI is they're not a traditional consultancy that wants to get into your business and never leave. They're always looking for ways to say, “Hey, we've done our job, we're going to go on to our next customer. Call us when you need us again.”
A: Since we’ve engaged with commercetools, we’ve built an internal platform team focused exclusively on headless, microservices and commercetools. We've also got a lot of additional expertise in-house around the product now that our people have had many months of experience working with it.
Now that our headless transition is in place, we have two things left to do. One is to start taking advantage of what headless lets us do. For example, we want to add new features that we couldn't offer to our customers before. We want to build things that enable our customers to do things that will make their lives easier, help them find what they need faster and get their stuff quicker. Two, we want to get the system so stable, well-alarmed, well alerted and carefully watched that we can forget it's there.
The perfect technology is the one that recedes into invisibility. That's our vision for this commerce system.
Senior Director and Chief Architect, Zoro.com
A: Now that our headless system has proven itself to work at scale, we want to enter into a phase of work called “headless exploitation.” We have a lot of increments of improvements planned. These are all focused on the customer’s experience when buying from Zoro.
Headless is really two parts: There's the user experience part our customers see, which is designed by our digital product teams. Then there's the backend eCommerce environment - headless microservices with commercetools riding behind them. For both of these, we think we can take better advantage of the environment — exploit it — so to speak.
A: I just celebrated my fifth anniversary at Zoro. When I joined the company, it was probably at about $500 million in revenue, give or take. So, it's been really exciting. It's been a hyper-growth, double-digit, “hang on to your socks, we're going really fast kind of place.”
Today, we’re at just over 12 million SKUs now and are moving toward 20 million. We'll probably move beyond that. Our aspiration is for the assortment to be truly endless. We just keep adding things that people want to buy because the more things we can make available to our customers, the fewer places they have to go to do their daily ordering. The key to that is to be constantly enriching our customers’ experience when they interact with our systems, fulfillment, and support organizations.
A: A big milestone for us was recognizing we now have a self-healing system, which means when something behind the scenes breaks, customers don’t notice. So now, whether you're coming to our site to register, update your credit card information, create a new order, track an order, pay an invoice or whatever, if there’s a problem in our backend systems or a problem with a third party, you just don't know. You just see a great Zoro experience mediated by our headless environment. This kind of customer-facing seamlessness is critical to growing our order volume and attracting more customers.
The flexibility of the system and the insulation it gives us from other dependencies in the stack is pretty important — and that's the nature of MACH design.
Senior Director and Chief Architect, Zoro.com
A: This was an effort that involved nearly every part of the organization at one point or another. The architects and delivery engineers couldn’t have done this without direct support from Finance, Customer Service, Marketing, Supply Chain, Customer Fulfillment, ERP, Pricing, Merchandising, Legal, and so on. And, of course, we had terrific executive leadership support. So, Zoro in total, has a lot to be proud of. We have a mantra we repeat often: We Win And Lose Together. The headless effort has been a first-class example of this.
Today, you walk around the building and hear people talking about headless, microservices and API gateways. People at Zoro have embraced the whole concept, whereas five years ago most people had never heard of a microservice — it completely changed the way the whole organization thinks about what we do.
On a personal level, the experience has been incredibly rewarding. It's been really satisfying to do something this transformative and watch really bright minds deliver really cool stuff. I’m supported by strong leadership and surrounded by talented and engaged people.
To learn more about how microservices, APIs, cloud-native and headless technologies are delivering the flexibility and scalability business need to thrive today, read MACH® architecture unveiled: Powering modern digital experiences.
Anita J. Temple is the Corporate Journalist at commercetools. She was a fashion editor at Women’s Wear Daily (WWD) and W Magazine before launching a career as a freelance writer and creative producer. She has written content and worked on a wide range of marketing projects for companies including Dreamworks, Walmart, Coca-Cola, Verizon, and Adidas.