Can your Restaurant Technology Architecture handle the next major disruption?

Future-proof your restaurant technology architecture to empower rapid innovation and handle whatever comes your way by investing in a Hybrid Cloud Microservices Architecture.

The restaurant and QSR industry has seen its share of disruption from the rise of digital and social ordering to the recent pandemic. Recent articles have highlighted the shift in retail necessary to compete as we come out of the pandemic. One example, The Restaurant of the Future: 6 Ways Restaurants Can Future-Proof for Success in a Post-Pandemic World notes how the pandemic has driven new business priorities such as increased digital and delivery options, customer and employee safety, contactless and streamlining your menu and ordering processes across all channels. To support any business shift and compete in the restaurant and QSR space it is essential that you have a restaurant technology architecture that facilitates rapid change and rapid innovation without impacting stability.

In the past year, there was a dramatic shift from on-premise dining to off-premise dining. Any retailers that were not able to quickly shift from transactions using their in store POS and kiosks to take out and delivery transactions were crushed. Rapid change that leverages less than optimal solutions takes a big toll on staff. For example, adding a delivery partners tablets in store to see orders and then having to manually re-enter orders into your POS takes a toll on staff and order accuracy. Bottom line is your retail architecture must be ready for the next major event and the only way to do that is to build a more flexible, open API (Application Programming Interfaces) driven modern retail architecture.

The primary goals of a restaurant technology architecture should include the following key traits:

Cost and economies of scale

Cost has to be aligned with your budget and growth should not explode your costs. In evaluating solutions be on the lookout for excessive additional fees for components. In the past year plus we have seen an abundance of 3rd party solutions for digital, off-premise ordering and payment. If each 3rd party you engage charges a monthly fee your true costs will explode. It’s essential to find solutions that have most or all of the components you need to minimize the additional component costs that will add up.

Vendor experience and partnership value

Any complex architecture has many players and the vendors who provide components to your architecture must be great partners who don’t let bureaucracy get in the way of your success. Be on the lookout for vendors that make it difficult or shy away from discussing innovation and new features. Also be very wary when any new costs pop up, especially those that were not communicated in advance. All good vendors also have a very vested interest in assuring you have the support you need regardless of who provides that support.

Features and flexibility to meet your specific business requirements

Selecting or building components that have the features you need is pretty much a given. However the key here is flexibility. You need components that can grow and flex to align with your business needs. This includes some flexibility in configuring the application for your specific needs and they should have a path to readily add new features that you need.

Easy to customize and change

To be successful and future proof an architecture it must support hyper-rapid innovation — able to change, add or remove components easily and quickly. To support this your architecture needs to have an open API integration architecture.

Easy to monitor, maintain, report and support

With many disparate components it will require a means to get all data needed to report on and support your architecture components to a central data repository. Centralized data allows you to create seamless dashboards that tell the end to end business picture and monitoring story. This requires an Open Data sharing architecture that provides the ability for any component to get its transactional data and log data to a central repository.

Hybrid Cloud Microservices Restaurant Technology Architecture

To build a restaurant technology architecture that supports these goals and future-proof your restaurant technology landscape to handle whatever comes your way — you should invest in a Hybrid Cloud Microservices Restaurant Technology Architecture as depicted in the diagram below.

Future-Proof Architecture Components

Let’s review the major components of the Hybrid Cloud Microservices Restaurant Technology Architecture:

Order Producers

At a high level a restaurant must generate and receive orders and then process and deliver these orders. Any method that creates an order is an order point or an order producer. Order producers are growing rapidly and can include on-premise POS, mobile apps, kiosks, delivery aggregators, social ordering applications, mobile text messaging, table-side ordering and more as they are invented. One of the major keys of this architecture is the ability to add new order points without impacting the applications that process and deliver orders.

Order Consumers

Order consumers are any element that leverages or acts on orders. A core order consumer is the kitchen application for restaurants so orders can be made and delivered to the customer. As with producers there is also a growing number of order consumers such as automated drink machines, back end food management applications like fryers, order status displays, contactless pick-up devices like digital food cubbies, etc. Once again — the key of this architecture is that I can easily add an order consumer by simply subscribing them to the order stream from your order producers and letting them decipher their actions from that stream.

Enterprise Cloud

The Enterprise Cloud in essence contains any of your restaurant applications that do not have to be on-premise in a store. Real time data engines for business reporting, health monitoring and support are a key example of enterprise cloud components. The Enterprise Cloud also houses configuration applications to manage your item catalog (e.g. menu) and centralized device/application settings as well as the routing infrastructure to deliver this data to your restaurant landscape.

As new components are added they should be evaluated for the cloud first as anything on-premise will have a heavier change management element if it has to be managed in hundreds or thousands of locations. A hybrid cloud architecture brings the benefit of forcing a location evaluation for every new component.

3rd Party Cloud

The 3rd party cloud includes all cloud components that you do not own and store in your enterprise cloud. These will typically be 3rd party order management applications such as delivery partners or social ordering partners. The 3rd party cloud will also include other business applications such as cloud based loyalty engines and back-of-house applications.

Cloud Integration Data

A key component of any architecture is centralizing all data needed to operate, track, support and report on your restaurant business. This data will originate in your restaurants, your Enterprise cloud or your 3rd party cloud but ultimately the right data must be centralized in your Enterprise Cloud so you can effectively report on your end to end restaurant business. One critical challenge to address is making sure you get the data you need from delivery aggregators and other 3rd party components.

IoT Orchestration Engine — Restaurant Hub Server

The Internet of Things (loT) orchestration engine is a physical restaurant hub server in each restaurant. This restaurant hub server houses the order orchestration engine, API microservices and other microservices that allow your disparate components to tightly integrate yet operate independently.

The order orchestration engine moves orders and status throughout the restaurant and can be messaging based (e.g. RabbitMQ) or database based using a SQL Lite or noSQL (e.g. Couchbase) database.

Microservices, small applications and databases can be housed in Docker or Kubernetes containers. The primary role of the server is to house and manage your order orchestration engine and microservices and provide change management to manage versions and deploy updates to your enterprise. There are numerous software options now to manage your Docker or Kubernetes containers. A governance model is essential with any restaurant hub server to assess all new containers to minimize duplication and manage growth against server resources.

It is feasible to run this architecture without a physical server by housing all IoT Orchestration components including order orchestration and microservices on every device. While this architecture has the advantage of not requiring a physical server in every restaurant, it has numerous disadvantages such as requiring a higher performance device for all endpoints (e.g. high RAM on all Android device tablets). Deploying a physical server in every restaurant provides the following key benefits:

• Minimize the cost of your operational device hardware like POS and Kitchen screens
• Minimize the risk of driving a required device upgrade for every device in every restaurant as you grow your business
• Reduce the complexity of Integrating and deploying 3rd party components by leveraging the central server vs. requiring a 3rd party component on every end point device

Deploying a Restaurant Hub Server as your IoT Orchestration engine truly liberates your architecture and its components and facilitates growth and innovation better than alternative architectures.

Why Does This Architecture Work

Implementing a Hybrid Cloud Microservices Restaurant Technology Architecture with a store IoT orchestration store hub server will essentially allow you to individually manage order producers (e.g. POS, Kiosk, Mobile) and order consumers (e.g. Kitchen, Order Confirmation Boards, Enterprise Bl Systems) while delivering a synchronized real-time reporting and support infrastructure. This centralized orchestration engine allows you to add, build and change applications in the restaurant independent of each other by having each component communicate through the microservices on the IoT orchestration engine. Technically separating restaurant applications allows each application to operate and update however they need to without impacting other parts of the restaurant!

This application independence of the Hybrid Cloud Microservices architecture provides the following benefits:

• Innovate without barriers and at a much faster pace than ever before
• Minimize adverse affects of growth such as having endpoint hardware performance limit your ability to innovate and grow
• Revolutionize and simplify support through a true centralized end-to-end support and monitoring infrastructure
• Provide a more robust real-time reporting engine and open wider doors to AI and data science to improve your key business indicators
• Simplify testing and migration to a new component via this true plug and play architecture

Critical Success Factors

The benefits of a Microservices based Hybrid Cloud Restaurant Technology Architecture are enormous but if you take on this architecture you will need to assure appropriate investment in the following critical success factors:

All edge applications must support an open API framework

Some larger retailers have embarked down the path to this architecture via a custom build approach while most retailers opt to purchase an all-in-one type POS solution. Regardless of whether you build or buy this architecture and its components, it is essential that you adopt an Open API framework for all components. To be future proof any application needs to be easily inserted or removed as needs change. Well defined API’s for all inbound and outbound interfaces will support this need. Any solution you buy or build must be able to operate independently through microservices to all of its connected elements. This requires well-defined API’s for all interfaces including operational elements and data sharing elements for application monitoring. The Restaurant Technology Network has recently published an Open API Framework that will help educate and facilitate adoption.

One of the added attractions of a true Open API architecture is that its makes your solution easier to report on and support as long as your architecture and its components support open sharing of your real time transactional data, logging and device health data. With an extremely modular architecture with many different components it is essential that reporting and support data is centralized to facilitate end to end visualization.

Change management

In the extreme case where you have a single massive application that does everything — a new release may be an update to one very large component. Now pushing one massive component out to thousands of retail locations has its own challenges but from a versioning management standpoint you have one component version to manage. Contrast that with a highly flexible but modular hybrid cloud microservices architecture that may have 50 or more components that include edge applications, micro-services and other components. Now rolling out a change to only the updated components is a big win but keeping the versions of 50 components in sync and aligned is where the challenges come in. In the last few years we have seen the emergence of IoT Orchestration engine software to help you manage the containerized microservices on your restaurant hub server. Reliant’s RPM (Reliant Platform Manager) on-premise edge platform and AWS suite of cloud and on-premise tools are two examples of solid tools to manage a Microservices based Hybrid Cloud Architecture.

System monitoring

Building a component based architecture will require that you tie all the pieces together from a monitoring standpoint. There are many open monitoring tools that can do the job here such as Elastic Cloud. As noted earlier this requires that your solution components have open logging APIs. An open monitoring tool can do a better job of monitoring your system than what is built into packaged applications. Building a robust open-ended monitoring system will allow you to add automation into your support portfolio by triggering fixes off of specific monitoring events. For example, an error on one of your restaurant micro-services could trigger a simple restart of the service. This fixes the issue immediately before the restaurant would even notice they have an issue. This saves the time and resources in store and in enterprise needed for a call to the help desk. So while this will require investment there are many benefits to spending the effort to set up an open monitoring platform.

Resource investment

To build and manage a component based architecture you will need to invest in resources to manage all of your components. This primarily includes the vendor support infrastructure for your all in one solution but it must also include other components that you bring into this open architecture. This architecture will likely require a larger combination of internal resources to supplement 3rd party support resources.

Bottom Line

A Hybrid Cloud Microservices Restaurant Technology Architecture will position your restaurant technology landscape to best handle whatever changes come your way in the future and will provide your business an architecture that can innovate as fast as you need to. The advantages of this future-proof architecture does come with some investment, however the wins of this open, resilient architecture are endless! Move to an architecture that will never limit how fast you move or how big a challenge you need to tackle!

Enjoy the Journey!

Written by Pete Nagel, Retail Technology Advisor and Do Less Champion.