Restaurant Technology Network Reveals Open API Framework
Restaurant Technology Network (RTN) introduced the industry's first and only Open API Framework during a webinar on February 22.
RTN's Open API Framework provides a standard approach for successful integration.
Abigail Lorden, VP and Publisher of Hospitality Technology and Co-Founder of RTN, explained that the Open API framework was one of the “founding principles” on which RTN was created.
“RTN launched just about two years ago at our 2019 MURTEC event,” said Lorden. “ When we launched, one of the key pain points in the restaurant industry were challenges with respect to interoperability. These were challenges that would slow down innovation, not only among restaurants, but also among technology suppliers, hampering their ability to innovate and move quickly. So, this was one of the initiatives that RTN, at the outset, wanted to work really quickly and deliberately to address.”
The cornerstone of RTN is its workgroups, where restaurant operators and tech vendors work together, virtual think-tank style, to find solutions to common problems. The end result takes the shape of published best practices, technical guidance or industry standards. To define RTN’s Open API Framework, more than 200 workgroup members worked together for approximately 1,500 hours, explained Angela Diffly, Co-Founder RTN.
Gagan Sinha, SVP Restaurant Tech, Inspire Brands; Phil Crawford, CTO, CKE Restaurants; and Jim Vitek, VP Digital Commerce, Yum! Brands, are embracing RTN standards, and spoke out as industry leaders embracing RTN’s Open API Framework on the webinar.
8 Key Principles
1. Self-Service Sign-Up for API partners
An easily accessible, straightforward process to initiate the integration project, which may include automated product API access. This may include API publishers or subscribers.
This step will benefit developers and IT projects everywhere. How so? “We can accelerate innovation by automating some of that access,” said Sinha.
2. Public-Facing Documentation
Thorough, easily accessible public information about how to access, consume, and receive support for the API.
“This one is very, very critical for having clear information on what type of APIs exist,” Sinha explained, “so that whether it's technical folks or a business analyst, they can clearly understand how the integration needs to happen and what type of data is going to be flowing on both ends.”
Sinha said he was excited about the impact these two principles may have on his development team in the future. “I'm hoping my team is able to leverage [these principles] in the future as we explore different technology options, products that are out there, to be able to look at the APIs and to be able to figure out what it would take to do the integration, so very excited on both fronts.
“Public-facing documentation … can facilitate high quality, defendable integration. It is important to have those documents publicly available,” Sinha explained.
3. Standardized Terms & SLAs
Easily understood terms, requirements and expectations across all levels of support and agreements.
“It's really about strengthening the relationship inside the SLA (service level agreements), and it basically, enables stakeholders to have a structured conversation based on agreed upon terms. Why is that important? Because not only does it define the urgency, but it also increases productivity and morale,” explained Crawford.
When creating SLAs, Crawford offered some sage advice: Set a baseline. Get feedback to make sure the SLA is what’s best for the company. Build a draft SLA; get rid of the non-important stuff, and get support from your leadership.
The industry vet boiled SLAs down to four principles: 1) Make sure it has time to track for a resolution, 2) Keep it simple. Use clear naming convention on the SLA. 3) Breakup large SLAs into smaller ones that are measurable and definable (to keep it all manageable), and 4) Set different attainable goals based on different levels of the SLA.
4. Testing / Sandbox Environments
Appropriate and easily accessible testing suites utilizing commonly available tools.
Crawford said these testing suites are “incredibly important for us to mimic a live environment, without impacting the organization or the consumer experience whatsoever.”
5. Extensibility, Enhancements, Flexibility & Updates
The API must be actively supported with an appropriate roadmap (including end-of-life announcements).
6. Pricing & Business Model Transparency
Pricing and business models are easily understood and predictable.
“Just make sure the models are easily understood and predictable,” explained Vitek. “Nobody likes gotchas.”
7, Validation and Certification
Business partners must be able to audit & verify connectivity and appropriate usage.
8. Re-Use of Best Practice Data
The API should use standardized data models across functions, where possible.
“This is all about defining objects in a consistent way across systems, so these objects could be a menu item, like a burger, you can customize an order or something else,” explained Vitek. “The industry has ISO or other de facto standards from big tech for common objects like addresses, dates and so on, but there's no real coverage out there for objects specific to the restaurant industry, and so that's the gap we're trying to fix with this here.”
In related news, RTN also released its Menu Synchronization Standard. Both the Open API Framework and the Menu Synchronization Standard are available online here.
“Overall, we're pretty excited about this. We have a lot of current integrations from our restaurants in 150 different countries today. We're contributing to the architectural experience to this effort with the hope that down the road, this is going to ease integrations with other systems,” said Vitek.
Coinciding with the launch of the API Framework is a Supplier Readiness Survey.
The webinar is available on demand here. This article was updated Feb. 23 at 3:45 pm EDT.