Transact

Campus services technology company cuts 80% API Development Time by adopting Design-First

      
https://d33wubrfki0l68.cloudfront.net/f9d39b6d567473e84dd02033f6101deb86e8eee1/398b2/images/case-studies/transact.svg

Industry: Technology
Location: Phoenix, AZ
Employees: 100-500

Customer Overview

Transact helps educational institutes make experiences mobile-centric, personal and individualized with transformative payments and credential-driven transactions and privileges.

Use Case

API Governance

Solution

Linting, Visual Design and Collaboration

Tools

Spectral and Studio

Like many organizations with robust product lines, campus services software company Transact knew it had technical redundancy. From the outside, their products were distinct and integrated well. Internally, there was a different story, which the company wanted to address before it became a larger problem. The result was adopting Stoplight, improved efficiency, and better internal partnerships.

Before making changes, the team took a step back to evaluate their process, specifically around how data is accessed and shared. Their goals were to enhance legacy applications, increase collaboration, and improve consistency in their products and methods. They tackled these objectives with a design-first philosophy and a new API workflow that runs through Stoplight.

Quote

In the process, as you’ll see in the sections that follow, the team reduced time to market, found a new motto, and built a foundation that will continue to serve the company in future projects.

CHALLENGE

Maintenance headaches across 13 legacy applications

Over the years, individual applications served Transact’s customers well. The campus services include payments, door access, and attendance, among others. The maintenance upon the integrations between their 13 legacy applications was becoming an internal strain. With some of these services in use for 25+ years, the company wanted to pave the road for further success.

Like many organizations, Transact manages a range of services that include applications built decades ago, applications obtained through acquisitions, and more recent initiatives. They’ve integrated these applications over the years, but each held onto its distinct flavor.

For example, a student named Rob might use one application to access doors on campus, another application to track his attendance, and a different application to pay with his cafeteria meal plan. While Rob’s experience is seamless, Transact must store multiple copies of Rob’s data. This scattered data burdens resources and inevitably forces inconsistencies. Sometimes something as core as Rob’s email address is different depending on the application.

OBJECTIVE

Design-First and reuse driven by OpenAPI Specification

These challenges led Transact to evaluate how they build software by breaking down the following questions:

  • What: What data is stored?
  • Who: Who’s requesting the data?
  • How: How is the data returned?

As they discussed the topics above, the importance of API specifications became clear. They determined that the most crucial task when building software is outlining the API design first, so the team can understand which data is needed and how they can ensure it uses existing services and models, if available.

SOLUTION

API-First Across the Organization

It’s not enough to simply declare API-first within an organization. Instead, Trevino took part in wide-ranging, reflective discussions with others at Transact. In addition, they started small—with a single team and API—to prove the value. Through the experience, they found a new way forward and adopted a mantra of putting the API design before all else.

The shift in focus created a new methodology around their API program:

  1. Define: Set the vision for the API
  2. Build: Follow the design specifications
  3. Review: Collaborate with stakeholders

The first objective is discussing the philosophy behind an API. This step clarifies the intent for the API and defines its requirements. While some engineers might get itchy for their keyboard during the design phase, it’s important to determine these details before a single line of code is written. Transact uses Stoplight’s OpenAPI designer to guide the discussions, generate documentation, and share the results.

The team then fleshes out additional API details, such as outbound requests, responses, error handling, and the remaining features documented in OpenAPI. They can pull in existing design artifacts, to ensure consistency.

Finally, it’s time to review the current design with stakeholders. So far, most of these conversations have been internal to Transact, but they expect to use a similar process with existing partners. This last step is their secret to increased collaboration: they simply share a URL to the Stoplight project to guide the conversations. No more technical details lost in translation.

Quote

This new mantra and methodology saves time and streamlines development. And it’s opened the door for an important project to unify their data, which will eventually impact all of their applications for the better.

Centralize Data and Expose It Everywhere

Transact optimized development by deciding API design comes first. Their new workflow uses Stoplight’s OpenAPI tools to save time and limit frustration by getting it right the first time. Trevino’s development teams are now taking on the larger issue of redundancy.

Remember Rob, the student whose email address and other data is copied across 13 different systems? Transact’s new API-first mantra inspired a shared services team. Shared service applications oversee the common APIs required for transactions, attendance, campus access, and other functionality.

By examining the broad picture of what, who, and how, they outlined the core APIs needed. Within their Stoplight project, they modeled the APIs, collaborated with other teams, and tested functionality. By using the design-first motto, they centralized and exposed their data, which significantly reduced redundancy.

Rebuilding applications currently in use can be risky, but Transact is taking it one project at a time. At the foundation is the API design-first philosophy and the new shared services team.

New APIs Can Follow Proven Templates

To enable others to achieve their same success, the shared services team needed to help other Transact teams learn from their experience. In addition to teaching their API-first process, they needed to codify the design decisions they already made. Just as an API design is held within an OpenAPI document and Stoplight project, so is the starting point of future API projects.

To ensure new APIs are built with uniformity, Transact created a template project. Every new API now includes:

  • Standard structure of files for a Transact API project
  • References to data models used by shared services
  • Style guide rules to ensure new APIs adopt company practices

The template project cuts the time needed for each team to get up to speed. They can focus on their specific problem, instead of the overhead needed to get started.

Quote

Transact increased collaboration and cut development time by 80% by adopting a new mantra and using best-in-class API design tools. Its 13 products, once internally disjointed, are working toward internal consistency, with the help of a shared services team—and a documented understanding of what every Transact API needs.

Create your own Stoplight workspace and discover how you can put your APIs first.