Home>Case Studies>
Schneider Electric

Schneider Electric

Global leader in energy management and automation cuts weeks in development time with OpenAPI linting and design libraries.

https://d33wubrfki0l68.cloudfront.net/ced96d95c7c93e42912979135668627d6be4bd39/d0798/images/case-studies/schneider-electric-vector-logo.svg

Industry: Electrical & Electronic Manufacturing
Location: Paris, FR
Employees: 100,000 +

πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— Customer Overview

Schneider Electric is a global leader in energy management and automation. The company has 170,000 employees serving customers in over 100 countries, helping manage their energy and process in ways that are safe, reliable, efficient and sustainable.

Use Case
API Governance, Reuse and Visibility
Solution
Linting, Visual Design, Design Libraries and Explorer
Tools
Spectral and Stoplight Platform

πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— CHALLENGE

A Black-Box approach to building APIs that was compromising speed and quality

After over 180 years of business, you might expect Schneider Electric has gone through many transformations. The Fortune Global 500 company specializes in energy management, and industrial automation. Like many companies of this size, it has a mature API program, but it struggled to keep up with the recent growth.

While APIs are sometimes seen purely as technology, the Schneider Electric team realized the importance of people in its process. The teams were working hard to manage all of their old and new APIs. In fact, they identified duplicative effort was often needed to launch new APIs. The back-and-forth needed to design, develop, and manage an API meant it was hard to keep the technology and business needs on the same page. This black-box approach led to guess-and-check API designs, which required additional work.

Quote

Suppose a Schneider Electric team needed a new API built. In that case, they’d have a first meeting with a separate team specializing in APIs regarding their expectations. A few days later, the API team would return a new API that missed the mark more often than not. The back-and-forth that followed to solidify the new API would usually take weeks. While the end product would get the job done for customers, the APIs lacked the consistency required for cross-functional use. Therefore, if another team needed a similar API, they’d have to go through the same new API process instead of simply reusing the existing one.

πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— OBJECTIVE

Improve transparency and resuability

After decades of bringing their customers efficient and sustainable solutions, Schneider Electric wanted similar results of their internal processes. To maintain its existing APIs, as well as enable teams to quickly build new interfaces, they’d need to adjust their black-box approach to APIs and embrace more modern methods. Among the goals were to increase API reusability and lower their development costs. Using Stoplight’s tools, they have improved quality and taken weeks off API development time.

Quote

πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— SOLUTION

Design-First approach to API Development

Schneider Electric knew the siloed API development process lacked the clarity needed, which led to a design-first approach. That’s when the team found Stoplight, to help guide teams through the new Schneider Electric API workflow.

πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— Shared Libraries Improve API Quality

Schneider Electric’s black-box approach to API design increased development times, but it also led to inconsistency among its APIs. Despite a central team building each API, there were not published guidelines, and each project was treated separately. With Stoplight as the knowledge base for its API workflow, Schneider Electric turned to design libraries to increase API consistency and quality.

API reviewers knew the API governance benchmarks to look for in new APIs. However, the teams looking for an API review didn’t always understand these criteria. A common model might have existed, but it was obscured in the black box. To solve this ambiguity, reviewers used design libraries. These are instantly shared across the organization and can be adjusted over time on Stoplight. The clear guidelines removed uncertainty, secured consistency, and ensured reusability for the future.

Quote

Design libraries took Schneider Electric’s APIs to the next level, so they looked for other ways to automate more of the process.

πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— πŸ”— Easy Linting Rules Saves Time

Following the benefits of design libraries, Schneider Electric turned to Stoplight’s linting capabilities to advance its API workflow. With programmatic rules, many common API issuesβ€”custom expectations specific to Schneider Electric APIsβ€”can be identified early. Stoplight Studio has linting built-in as a straightforward tool to provide even more time savings during API reviews.

Quote

The Schneider Electric teams use the linter’s pre-built functionality to check for things like the correct case. When APIs employ a consistent approach to endpoint and field names, API consumers (often internal teams or trusted partners) can easily integrate across multiple APIs without looking into syntax. Stoplight has most common case choices built into its platform, which saves the trouble of implementing regular expressions. However, for more detailed requirements, the Schneider Electric reviewers can write custom rules. By applying this automatic review during the design phase, the team noticed a significant decrease in the time it took to review.

You’ve followed Schneider Electric’s journey from the pains of designing APIs in a black-box to creating transparency, higher quality code, and saving time with just a couple of tools in Stoplight Studio.

Create your own Stoplight workspace and make your APIs more consistent.

Want to streamline API Design and Devlopment?