A vendor ecosystem strategy that is common in the restaurant technology space is the best-of-breed strategy whereby an operator selects the best possible vendor for each application independently. Before we discuss how to make that model work, let’s discuss how we got here.
Current State of Restaurant Technology
Over the past few years, the slow transition of the traditional restaurant application vendors to a cloud-based architecture has opened the door for well-funded startups to seize the opportunity and build innovative cloud-based restaurant applications.
This has led operators to embrace a best-of-breed model with a cast of vendors providing the applications they need to run their business. The result is that operators are now struggling to manage a complex vendor ecosystem of integrated applications and get them all to play well together.
Cloud-based architectures have increased the rate of application innovation, allowing upcoming vendors to check more boxes by providing more of the applications restaurant operators need to run their businesses. As a result, the big traditional restaurant application vendors are racing to do the same. This will likely cause the operators to shift from integrating best-of-breed vendors to a one-stop-shop model.
But what if you don’t want to put all your eggs in one basket? What if you don’t want to select the best vendor that checks all the boxes (and potentially end up with some applications being substandard) but instead want to continue selecting the best possible vendor for each application? How do you deal with the challenges of getting all these best-of-breed application vendors to integrate without ending up with a complex web of point-to-point integrations?
Restaurant Enterprise Service Bus
One answer is to take an enterprise-level approach and implement an Enterprise Service Bus (ESB) as a middle-ware foundation for integrating a growing list of applications.
First, what is an Enterprise Service Bus (ESB)? Wikipedia defines it as “implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA)”. Stated in business terms, it is a middle-ware solution that sits between all applications with each application only having to integrate with the middle-ware once, instead of having point-to-point integrations between each application and every other application that needs to communicate with it. The following diagram illustrates this architectural shift:
The ESB model provides an efficient way to enable real-time data exchange between multiple applications. Some key functions performed by the ESB include:
- Transportation: exchanging data in real-time between applications
- Service Mapping: translate a business service to a corresponding service implementation
- Transformation: transform the data from one application into the format needed by another application receiving the data.
- Routing: provide intelligent routing and load balancing of data between applications.
- Security: provide a layer of secure access control to services
Integrating applications can become increasingly complex as you add new applications to your business and as they become critical to your business success. Pursuing an ESB architecture requires a significant commitment and investment to plan, implement, manage, and enforce compliance over time.
Our Experience with ESB
My personal experience with implementing an ESB architecture was during my time at Starbucks from 1998-2005. While I was program managing the initial Starbucks Card program, we implemented a middle-ware that we called Enterprise Data Transport (EDT) in 2001 to send POS transactions to corporate for translation and routing to the gift card processor.
After I left Starbucks in 2005, my co-workers today at Peak Portfolio, all ex-Starbucks as well (Brian Christenson as Dir of IT M&A, Steve Schell as VP of Retail Systems, and Keith Meador as VP of Intl Tech Alignment), continued to grow the EDT architecture into an enterprise-level ESB over the next decade.
More recently, Peak Portfolio introduced the ESB concept to Dunkin’ Brands in 2015.
Is it worth it? Here are some benefits and drawbacks to consider:
Benefits of the ESB Architecture
- Less integrations by having each application integrate once with the ESB versus integrating with every other application that needs to communicate with it.
- Easier to leverage more than one of the same type of application as other applications are only integrating with the ESB and not both applications.
- Easier to manage a slow migration between two applications for the same reason as the previous bullet.
Drawbacks of the ESB Architecture
- The ESB platform can become a single point of failure so it is imperative to select an ESB platform with architecture that automatically re-routes traffic to another instance in a different region if the primary data center goes offline.
- May cause slower communication time between two applications by putting an ESB in the middle versus a point-to-point integration.
Keys to Success with the ESB
What are the keys to a successful ESB implementation?
First, view ESB as a long-term foundational strategy that will not pay dividends immediately. Build a 3-5 year roadmap to gradually move application integrations over to the ESB. We also recommend selecting non-critical applications for initial ESB integrations and saving the more business-critical applications for a later time when you have more experience and expertise in managing your ESB integrations.
Second, take the time to do your diligence in selecting the right ESB platform or technologies to build your own ESB platform.
And finally, expect and plan for a learning curve for your IT team to become experts in the ESB model. Consider hiring ESB experience in addition to educating your current team members. Also consider leveraging consultant expertise until you are confident your team is ready to take the baton and run with it.
Alternative Vendor Ecosystem Strategy
An alternative strategy to the best-of-breed vendor ecosystem strategy (and ESB approach to managing the complexity of all the application integrations) is to migrate to the restaurant technology vendor who is best positioned to deliver a Restaurant Platform-as-a-Service (PaaS) model in the coming years. This reduces the number of integrations needed by having one vendor provide the bulk of the applications you need to run your business.
