Pilot Flying J uses MuleSoft, which can integrate data from locations in North America and improve the quality of service to its customers.
API first strategy and Mulesoft help Pilot Flying J to break down data silos
Pilot Flying J uses MuleSoft, which can integrate data from locations in North America and improve the quality of service to its customers.
At Dreamforce 2019 in San Francisco, Bill Detwiler from TechRepublic spoke with Pilot Flying J Senior Director Digital, Loyalty and Brand Marketing, Tyler Tanaka about interoperability and how linking multiple data sets has improved the company’s performance. The following is an edited transcript of the interview.
Bill Detwiler: How do you bring together several companies that are made up of multiple mergers and acquisitions? How do you bring these systems together in a way that is efficient, works and benefits the customers? I’m here with someone to talk about that at Dreamforce. Tyler Tanaka is Senior Director of Digital at Pilot Flying J. You may know them from their truck stops and gas stations, but there is much more that Pilot Flying J does. They manage one of the largest fleets in the industry, so I am really interested to hear how they manage to make everything run so smoothly.
Tell me a bit about Pilot Flying J. How you grew through M&A, how you had to connect and assemble all these old hardware, software, data repositories in a way that works.
SEE: Hybrid cloud: a guide for IT professionals (TechRepublic download)
Tyler Tanaka: It was an interesting trip. We are more than 60 years old, a family business, but a lot of organic growth combined with mergers and acquisitions, and a few joint ventures, a few acquisitions and a few large mergers. And so there have been many technical debt and legacy architecture and legacy systems and new outlets and old outlets that we all had to bring together. One of the keys for us was this switch to an API first strategy and the unlocking of all those monoliths or frozen data sets in one beautiful, organized data lake, which can then be distributed and expanded wherever we want. Our goal, of course, is to make a better day for our guests on the road, professional drivers or a gas customer, and having that data unlocked and accessible is extremely important.
To have all that data organized, the hard work needed to put it in an EDW and have it ready for use. This first API strategy has given us the agility and agility to do what we want, even if we were to merge or make an acquisition in a large area of locations. If we did not have that flexibility, it would take much more work, much more time and we would not have the opportunity to be as flexible as we as a company.
Bill Detwiler: Give me a concrete example of how to put that first API philosophy into practice. You can talk to that, whether it is a customer contact point or something behind the scenes.
Tyler Tanaka: I will give you a good example. Several shower reservation systems had been built for some reason. Many people do not realize that we are also a hotel; we are a concierge service. We have professional drivers who stay with us in the parking lot and sleep in their taxis at night. We have more than 80,000 parking spaces and we do almost 70,000 showers a day to help our guests.
Bill Detwiler: So it is in a way a very spread out hotel.
Tyler Tanaka: Exactly. We are a conglomerate of hotel stops and a variety of different brands. For whatever reason, built up over the years, we ended up with multiple shower systems and one system might do one thing. We wanted to give tools through our mobile app to these professional drivers who had to reserve showers, so we have built a shower reservation system that allows drivers – once they have broken our geo fence – to use our mobile app to get in line. It then gives them a code that they enter in the combination lock on the door and they can shower.
Thanks to an API strategy, we were able to take all those disparate datasets and disparate systems from more than 750 locations in North America and know how many showers there are at each location, how many showers are now available, and how to line up in a row places the line and then gives him the code to make a reservation and to inform him when the shower is available. The goal was to provide this great tool to the professional driver so that he could save time and not be anxious and stressed about his routine when he arrived at our site. Of course, that API functionality allows that to happen, to take all that old architecture and make it something modern and new and available in our mobile app.
Bill Detwiler: I imagine there were quite a few challenges in building the API that would bring the two systems together in one lab. Talk a bit about some of those challenges and how you have overcome those challenges. What was it about the platforms you chose that made that process easy or even possible in the first place?
Tyler Tanaka: We opted for MuleSoft for the acquisition of Salesforce, so I am clearly feeling well. The companies that Salesforce chooses to buy are quite phenomenal. We have quite a few other companies that we have chosen for their products that were eventually taken over by Salesforce. So we chose MuleSoft because of the single runtime that that platform delivers. It removes all that point to point–.net in our case – point to point in APIs earlier, and then builds the system layer and process layer APIs within the Mule code that every developer can go in and write a new experience layer for whatever function we want to build. We don’t have to rewrite the work over and over, because with the MuleSoft platform we can build this muscle memory that you do the hard work in advance and you have all this reusable and reusable code.
Of course I think the big challenge is that there is a learning curve, such as learning a new language, with everything. The investment you make in your existing team members to train and go through learning change management and adopting a new platform was probably the most difficult for us, but our team is remarkable. They have adapted well; they have taken the time to learn and be educated and have really embraced a new way of doing things. It just takes a little time to get that momentum going.
Bill Detwiler: One of the things I spoke with Uri Sarid, who is MuleSoft’s CTO, was the leadership and a vision and the will within the company to invest the time that you said you are making changes to and starting with that strategy . Was that a challenge within Pilot Flying J, or could stakeholders and business unit leaders see the benefit of switching to an API structure right from the start, or did you have to overcome resistance – this is how we always did it so do we have to keep on doing it?
Tyler Tanaka: Yes, that always exists. Change is difficult for everyone. The real tribute goes to our CIO, Mike Rodgers, who has really embraced an agile methodology within the IT organization and has left traditional work and the waterfall. I think Mike is one of those leaders who quickly sees where we need to go and wants to empower ourselves as an organization and enable IT to be the business partners that make all other business units successful. The only way we can do that is by being iterative and agile and athletic. He did a great job of helping the company understand that if we want to get there, here are the important things that are needed to help us reach that successful endpoint versus the traditional IT business relationship of “go do my work,” go build my IT build ‘. We are now really in a partnership because of his leadership, which was extraordinary to see.
Bill Detwiler: Something we are talking about at TechRepublic is the changing nature of IT. It has really shifted from people. IT was traditionally seen as a cost center, as the people who always say no, as a point of friction for BUs. I think that this barrier must have disappeared very quickly in the last decade. IT can no longer be an entity that is seen as just a roadblock or barrier. It must really be a symbiotic relationship and a partnership with business stakeholders.
Tyler Tanaka: That’s right. Sometimes – and this is in my conversations with other digital leaders in this area, and I’ve heard a lot about this at Dreamforce this year – you can’t say yes. There is no possible solution unless you started working a year ago or two years ago to make that possible and feasible today. With this shift to adopting Salesforce as a platform for us, we are well rooted in Salesforce and committed to it as a platform. Sales Cloud, Service Cloud, Marketing Cloud and a variety of other tools to which they are attached.
We are a Tableau store; we are a DMP; we are now a MuleSoft customer for APIs. That commitment, more than three years ago, laid the foundation and all the hard work that has now come to the fore means that the answer is usually always yes to everything the company needs. The digital and IT teams can be extremely flexible. And now it’s about problem solving, not about re-architecting or ripping and replacing. It is really remarkable how quickly we can move to support business needs and to move in whatever direction we need to evolve as an organization.
Bill Detwiler: One of the other things that large organizations have to deal with is interoperability. Dealing with all those we talked about earlier, with legacy, this hardware that you talked about, using the API strategy, API first strategy to overcome that, to bring those things together. If you think about it now, were you already a Salesforce customer before the MuleSoft acquisition?
Tyler Tanaka: We only had Sales Cloud and at that time we had Marketing Cloud. What we realized is that we still had no way to move data, even within the Salesforce environment, because you had core sales and Service and Marketing Cloud on two completely separate environments and two code bases. It was like you could do it through Salesforce connectors, and you could do it from point to point, but you didn’t have the flexibility to do what you really wanted to do to help the company move forward. This interoperability was a huge advantage in saying: “You know what? We are not going to rely on Salesforce to determine our own success here. We can’t wait and pace their general releases or their connected strategy. We really only have to attack this. ”
A very good example is Josh Birdwell, who manages our retail technology; he is my colleague on the business and technological side. It is stuck in the same with older architecture at the point of sale, and without having a way to tap into all these different data sets by moving it into APIs, we would be fascinated. He and his team have done a fantastic job of enabling us to use the retail technology in-store via the mobile app or kiosk – or whatever we want to invent in the digital product team. It works in both cases in both cases.
Bill Detwiler: You used two different Salesforce products. It was MuleSoft and that API that you already used to bring it together. Then comes the acquisition and the new announcements here at Dreamforce about some of the changes they are trying to make with APIs, with the MuleSoft strategy with the APIs – in your eyes they are going to make it even easier to do that.
Tyler Tanaka: That’s right. I clearly thought it was a brilliant asset, because I had already seen the value of what we as an organization had with the product. I don’t think Salesforce might even have known how valuable it would be. The reason is that Salesforce has clearly started as CRM and has grown into marketing. I actually think that all Marketing Cloud customers can now use MuleSoft to unlock extra value that goes the other way. If you only used Marketing Cloud, I think MuleSoft now offers this whole extra cloud opportunity for those customers to go back to the core product versus core products that go to Marketing Cloud.
Bill Detwiler: On the other line.
Tyler Tanaka: Yes, that’s my bill.
Bill Detwiler: I like the point you made earlier about taking the time to train your staff, taking the time to invest in it. One of the things I know MuleSoft announced was a greater integration with Trailhead, the Salesforce training platform, to help people create APIs. Talk a little bit about that. Is that something that you see as: “Hey look, since we have this API strategy for the future, this is definitely something that our people can benefit from.”
Tyler Tanaka: The last thing we want to do is invest in a platform and rely on a system integrator or an external third party to do all the hard work and then leave with all the knowledge about how they built it all. It is incredibly valuable to be able to train from a junior developer to a senior architect. Being able to have that continuous learning and continuous knowledge growth to reduce the dependence on these third parties that we would otherwise have for StaffOrg or to run a hybrid is really important, and of course it’s free. It is included in what the platform already provides us. You don’t have to go out and pay extra training, and it’s at their own pace; it’s on their own time. It should be a huge advantage to let the team go through that training.
Big Data Insights newsletter
Master the basic principles of big data analysis by following these tips from experts and reading insights about innovations in data science.
Delivered on Mondays
Register today
Also see