Schneider Electric (SE) is a 184-year-old global company leading Digital Transformation in energy management and automation. We have been creating and managing APIs, using API management platforms since 2014. We use API management platforms to manage the API lifecycle for both SE consumers (our software applications, including web app, mobile app, and IoT devices) and external consumers (the software applications of our partners, suppliers, and distributors).

At the beginning of 2019, we felt the need to take stock of our API-estate and check it’s health. We conducted a six-week-long discovery towards this end. As part of this exercise, some symptoms presented themselves, which indicated the API-estate was not in perfect shape. Some key findings included:

• Multiple API management solutions: We found that various teams within SE used multiple API management solutions. API management tooling differed across different business units, line of business, and regions (like IT teams in EU, NA, or China).
• API design hangups: We could only find API designs for a handful of APIs. Moreover, teams had created API designs in isolation without using proper collaboration methods. In some cases, they weren’t consulting functional subject matter experts (SMEs).
• Limited API reusability: We found that nearly 40% of the APIs were not used by any application. Since most APIs weren’t created with future projects in mind, the majority of them were not reusable and required frequent changes. We found poor developer and user experience to be major contributing factors to this issue.
• No API design and management standards were followed: Teams maintained API documents in MS Office such as Word, Powerpoint, and Excel.

Subsequently, with the desire to fix these issues, the top management took a firm decision to reset the API program to drive true transformation.

I was entrusted with the work to define the transformation roadmap and subsequently set up a team and realize the objective, following the transformation agenda: to make the best quality APIs with superior user experience.

Transformation Objectives and KPIs

APIs are the building blocks for modern software applications, and they should open data and functionalities. With this goal in mind, we constructed our core objectives.

First, we wanted to open visibility into SE’s entire API catalog by building a superior API platform to enable open governance. To achieve this, we realized we needed an API management strategy that could evolve as a product, and that considered the people, processes, and the right tools for the job. The next step was to converge all other existing API managers into this new platform to reduce technical debt.

In my long experience, I have noticed that visibility drives transparency. When we can see something, we can provide valuable feedback, which helps improve quality. In the world of APIs, an improved API quality and better developer experience can enable higher API reusability. This reusability, in turn, can drive operational cost reduction and increase software application delivery speed.

In addition to these project objectives, I established two golden Key Performance Indicators (KPIs) to track our transformation progress. The first was the API Usability Index (AUI). This KPI denotes the average number of applications calling an API. We derive AUI from the ratio of API subscriptions to API count. At SE, AUI stands at around 3.6, but we aim to reach 4. The second KPI was simple: Tech Debt Reduction. We wanted to reduce the number of API management solutions to one.

9 Steps Toward API Transformation

The next part was actually transforming the way SE handled APIs. To realize this transformation, I defined and implemented the following nine steps.

1. Foster Internal Community

Set up a social community within the organization to break silos and bring like-minded people from across the entire global organization together to share and promote social learning. This will slowly start influencing and engaging the business to prepare for the change.

At SE, we started with an API challenge to demonstrate to the senior management the power of APIs and how, when done correctly, they can bring significant value to the business. The API challenge also helped generate excitement among the technical groups in SE.

2. Define the API Standards

Define the API standards for the organization. This includes the API naming standards, API security approach, error handling, API management method, as well as other best practices.

At SE, we created a Developer Experience (DX) mandate, which included a set of ten golden rules on how to improve DX. We then shared the DX mandate with the community to help them influence and apply these standards as part of open governance (i.e., governed by the community not by any central group).

3. Use Visual Design Editors

Bring API design-first concepts to life by introducing a visual API designing tool to speed up design. This visual design is particularly favorable for non-developers, especially the functional (domain) experts who contribute to the overall API definition. At SE, API documents are now auto-generated from the OAS (Open API Specification).

4. Automate Design Consistency

Create an API-focused team and tools to automate API design consistency across the organization. My team was able to build API standards into our design tools, thereby the enforcement of standards is automated and requires zero “policing.” With this change, every API design is consistent and compliant with our standard. We promote mocking APIs before making.

5. Adopt an API Management Tool

Setup a new API management (APIM) platform while keeping DX, security, and scalability in mind. For scale, SE leverages a cloud-hosted API management vendor. To enhance security, we are using an AI-based bot detection and prevention module that checks all API calls in real-time for malicious traffic.

6. Consolidate APIM

To avoid technical debt, and improve consistency, consolidate to use a single APIM. We replaced the largest APIM platform by migrating (essentially re-building) around 300 APIs into the new platform and switched over roughly 200+ connected Applications (API consumers).

7. Automate CI/CD

Automation is the key. We leveraged CI/CD for automatic deployment of source code across multiple platforms, using Github as a source code repository.

8. Make APIs Self-Service

Self-servicing and democratization are critical factors for APIs. At SE, they are crucial to our DX mandate. We validate against these concerns for every new or enhanced capability that we introduce.

9. Define Clear Roles

Define roles and responsibilities for three new roles: API Provider, API Consumer, and API Designer.

Following these steps to transformation, APIs become no longer a technical or IT subject but an organizational topic of high importance!

Key Takeaways

In less than one and a half years, we have completed the transformation mentioned in the above steps. SE now houses all APIs in one place, whether internal or external or in production or still being developed. This has improved visibility greatly.

Now, APIs are treated like products. They are viewable and searchable at the project and attribute levels. APIs are available in a self-service model for anyone in the organization to test. Since API documents are auto-generated from Open API Specification, developer experience has significantly improved.

Our community was a pivotal factor in this journey. All this work has been possible with an API team size of nine members and a community of 600+ people. Our model was a community-driven, standard-based adoption of a design-first approach, using visual designers and a “mock before make” philosophy. I will suggest replicating a similar process in other transformation areas too.

Challenges And Room For Improvement

If your organization intends to drive a similar API transformation, you should anticipate certain challenges. For one, an API design-first approach needs stakeholder buy-in. To participate in collaborative design requires a mindset change. Instead of viewing APIs as an afterthought or purely technical subject, they must be treated as “first-class citizens.”

Secondly, encouraging an API culture works better under community-driven, open governance models. If your organization follows the traditional ‘Command and Control’ culture, people may find it difficult to adjust to this new approach to working.

Our API transformation journey at SE has mostly been successful, but we strive to continue to improve. Areas we are improving include having the API design and management platform to support serverless architecture, identifying APIs for monetization and planning our go-to-market strategy, and adopting other API types such as GraphQL.