Talking operations 2.0 - how UPS disrupted itself by acquiring i-parcel
- Summary:
- When UPS acquired i-parcel, it wasn't a typical talent and code extraction. At MongoDB World 2016, UPS i-store's Yursil Kidwai told me how they moved from acquisition to innovation driver inside UPS. That journey also involves a move to MongoDB, and what Kidwai and his team call operations 2.0.
That's a fancy way of saying i-parcel built an international logistics platform UPS wanted. At the time of acquisition, Kidwai and team had expanded i-parcel's local language sites and multi-currency pricing to vendors in 100 countries.
During my chat with Kidwai at MongoDB World, I was expecting the typical story of startup employees heading for the exits; the last person standing facilitates the absorption by the bigger organism. But Kidwai's story is far more interesting: not only does i-parcel remain as a standalone business unit, but almost all the fifty startup employees stuck around. I-parcels' DevOps culture is influencing UPS as a whole, providing a jolt to established procedures.
The growth of UPS is tied to international commerce
Beyond the sound bite, why did UPS acquire i-parcel? Kidwai cites two factors: international capabilities and logistics execution. International growth is high stakes for UPS. Kidwai:
UPS recognized international is really where they believe all the growth is in their business, and i-parcels was really founded with that purpose, to grow international e-commerce.
To grow e-commerce globally, i-parcel tackles two issues. The first is solving technology problems that merchants struggle with, including currency conversion and content management. That could mean showing international shoppers country-specific promotions, or handling international fraud checking and review. Accurately quoting taxes and duties in the shopping cart is critical:
The UPS guy shows up and gives you a bill at the same time as your package, at which point you can say no, and for international shipping, that costs a lot of people money.
I-Parcel provided UPS with capabilities to deal with these issues. Then there is i-parcel's logistics network, which brings vendors together, gluing the transportation from point A to point B. The big key is reduced shipping cost from classic UPS services:
If you were to send one pound into Australia - something the size of a book - you'd get charged somewhere between 70 to 90 dollars by all the carriers. UPS i-parcel can do that same transportation for around 10 dollars. So that enables international e-commerce in a way that you haven't had before.
The end result: merchants across the globe can now add UPS i-parcel services to their web sites, giving them global pricing and shipping capabilities that integrate with shopping carts.
But there's a twist to this story. When Kidwai joined i-parcel as CTO - prior to the UPS acquisition - he built a new e-commerce front end. The logistics system was another matter:
We used logistics operation software to move the packages from point A to point B with our vendor network. But that system itself had a number of problems. It wasn't scaling. It was very difficult to make changes in, and it was struggling. It was also originally written by a third party, and only maintained and adjusted by i-parcel developers.
Operations 2.0 led UPS i-parcel to MongoDB
After UPS acquired i-parcel, Kidwai was tasked with upgrading that logistics system. UPS was concerned about investing in a business unit that was already grappling with volume:
We knew we had to redo this software, so that's why we started a project that we call operations 2.0.
Parameters were strict: for legal reasons, there could be no contact with the external 1.0 team. White board time:
We weren't able to leverage anything that was built before. Not that we wanted to, because we wanted to approach the problems with a new, fresh look anyway. The bottom line is we were solving a problem that we didn't really know. And so, to that end, we were looking for a database solution that would grow with us as we learned more about what we were building.
Kidwai's team did have some database criteria:
It had to be something that supported dynamic queries. It couldn't be something where you had to know the queries a week or a month in advance before you actually started using them. It had to be something that supported a flexible schema, and it had to be something that was very easy to make regionally redundant, meaning it had to be something we could run out of multiple data centers and fail over very very quickly.
Which led them directly to MongoDB:
MongoDB checked all those boxes for operations 2.0. As we began that project, we changed the schema a lot, and we built new queries, and we're still building new queries all the time. We've certainly leveraged the resiliency of MongoDB in terms of its regional deployment. So all of those things have really paid off for us.
The go-lives are rocking along. Kidwai's team started with a Minimum Viable Product, building it out while deploying across regions:
We are now running our operations 2.0 software in seven facilities across the world, with zero downtime. We're continuing to handle more and more volume as the business grows.
Kidwai's journey to enterprise-level Mongo started with the free edition, kicking tires and experimenting with prototypes. As last year's MongoDB World, Kidwai and team showed up in force, taking training classes and learning from peers. After the show, they engaged MongoDB in more consulting. They decided to purchase the enterprise license, with global support in mind:
Ultimately, as we were moving closer and closer to full production, we wanted to have the security blanket of knowing that we had the full support of that company behind us. So we knew we had to choose a vendor or a solution that was going to have that enterprise level support. Anything that didn't have it was off the table.
The rollouts continue. By the end of 2016, Kidwai expects the last of the operations 1.0 regions to be replaced with the operations 2.0 MondoDB system, version 3.2 (Mongo's latest release). I asked Kidwai if he's seen benefits so far. He pointed to the process of deciding which vendors a parcel will be delivered by, and the label printout for the final mile carrier:
That process in 1.0 was taking up to 30 seconds, and sometimes 60 seconds, per parcel. With operations 2.0, we've seen that drop down to sub-two seconds. So that's a huge performance increase for us. Ultimately the faster the system is, the more cost effective we can be in terms of our labor and materials.
The wrap - winning hearts and minds at UPS
UPS is continuing to invest in i-parcel, with plenty of projects on the horizon. One priority: a renewed focus on the e-commerce system, applying the operation 2.0 lessons. Later this summer, Kidwai's team plans to release a set of internal development tools as open source, a project called Scale Sharp. These tools are intended to help developers "work with MongoDB and other modern design patterns."
When Kidwai mentioned open sourcing a tool, I paused: that doesn't sound like typical UPS behavior. So is i-parcel influencing the larger company? UPS knew what they were getting into, says Kidwai. UPS has data centers in New Jersey and Atlanta; i-parcel is a cloud-based environment:
They knew coming into it that we do things differently. And they liked that; they welcomed that... We're being given a significant niche.
Early on, UPS gave Kidwai one of their lead resources - a fifteen-year veteran - to spend a year with i-parcel and get a close up look at how they do things. Culture clash?
It was interesting, but it was beneficial, and he became a fan of our approach.
The UPS person veteran impressed enough to share i-parcel's DevOps ways with the rest of the company:
He started posting onto our internal UPS forums, talking about all the things that he learned after his year with us.
His story has a neat ending:
Ultimately, we said to him, "Do you really want to go back, or stay on?" And he decided he wants to stay on with us.
So how much did this UPS veteran know about Minimum Viable Products, DevOps and design?
He was totally not familiar. But he picked it up really quickly, and enjoyed it all.
And what did he like about it? Was it the speed of delivery?
Yes, he loved that. He did feel a little bit burdened by some of the UPS bureaucracies. But he saw a lot of that removed with us. Deploying, for example. We deploy daily - if not multiple times a day - into production. UPS, on the other hand, deploys, I think, four times a year.
Sounds like plenty of chances for change ahead.