Adriano Mota, a Solution Architect at Ford Motor Company, demonstrates how an API-first internal strategy has fueled their digital transformation efforts. 

Digital transformation enables businesses to speed up old models that need to be modernized, helping them face new global markets. Maintaining agility with the help of such digital strategies has become critical for all organizations, small and large.

A vital aspect of digital transformation is the use of APIs. In this article, we’ll demonstrate how we at Ford worked with APIs to solve issues and modernize our business. By following these practices, others can similarly enact positive change within their daily work.

The Firsts Steps

Our first experience with APIs started with the requirement to speed up the process of sharing information. We wanted to do so in a more accurate way and without the need to wait for batch processes.

As you may know, batch processes from a mainframe environment may run during the night or twice a day, depending on the volume of data and the activity of the job. We work in the automobile industry and continually need the production status of our vehicles. Though most of our primary systems were legacy mainframe, we realized we couldn’t work in this structure forever; our customers shouldn’t have to wait through slow batch processes. We knew that the scenario had changed in the automobile market, and we needed new ways to work.

That was the moment when we started thinking about APIs. APIs are the most efficient way to deliver accurate and updated information to the customer or other applications on the web or mobile. We identified that this was an opportunity to use this new approach.

However, before we started developing our first API, we needed to do our homework to understand how the data we would deliver was created.

On the legacy mainframe layer, we have several interfaces with other systems, using text files and typed information in application forms. After all this information is loaded into the database, it is consolidated in the batch processes. That was our main challenge: understand the flow of the information and share it online.

After we understood this scenario, we were ready to search for a better software architecture to develop and feed the APIs that we needed to build. Also, we were forward thinking; we wanted new API versions to be backward compatible.

Adopting the API-First Mindset

We started this as an MVP (Minimal Valuable Product), using an API-first approach, designing the API and defining how it would interact with the applications that consume it.

Lesson: Base API Design on Consumer Needs

As we see it, an API-first approach should place API thinking first on the client-side, putting the needs of consumers as a top priority. To do that, one must consider: What is the most valuable information? How can it aggregate value? Working from the perspective of an API consumer is essential, as this will help avoid rework and minimize the impact of changes to your API versions. This was our first lesson learned.

Once our API was designed well and documented, we started working on the architecture that would retrieve the data from the legacy system and how we could translate it to a common standard.

Lesson: Follow Standards And Best Practices

One of the requirements of our API was to share information in a common standard to allow other systems (legacy or new ones) to read the data and use it without the need for a second level of work. Once again, we learned how important it is to have good practices for API design. By using correct error codes, JSON formatting, and following other industry best practices, we were able to improve overall usability.

Lesson: Choose Your Tools Wisely

Regarding the code, we started a proof of concept using Spring Boot Framework (our better-skilled developers work with Java) and deployed it to our cloud environment. We also used Swagger for web documentation. (OpenAPI (fka Swagger) has become a standard for API documentation, and it is imperative to engage developers on this task).

After some improvements, our proof of concept was stable enough and ready to be tested and consumed by a web application. We started monitoring the use of this API, sharing metrics internally. After all this work, we began to notice customer satisfaction improving, as they were receiving the most immediate and accurate information possible – our most significant accomplishment.

The Second API

This first API helped spark other ideas and so a second one was developed, capable of returning the information of a Vehicle Life Cycle. Just like in the first one, we used the API-first concept to design it. A similar stack (Java + Spring Boot + Swagger) was also used in the development of this new API.

Since we had the architecture to work with, the new API was easier to develop without disrupting routine business. Now, customers must no longer wait on batch processes to run at night to receive the last information. This grants the customer greater efficiency to streamline decisions made along the sales process. Also, this API is reusable by other systems, and each one can use the data according to its needs.

Once again, we monitored the metrics of access and data traffic through this new API, and we were convinced that this was the right way to scale our legacy, improving efficiency and also, the most important, delivering value to your business in taking decisions process.

At the end of this MVP, we delivered it to our leadership and shared our journey through API development. Now it is clear to us that, to dive into digital transformation and scale the business without disruption of our core, an API-first approach must be adopted.

The Barriers

When leading digital transformation, culture can often be the most challenging barrier. Trying to convince your team and leadership to break deeply-rooted concepts can be harder than the technical issues. However, when we started to demonstrate the API culture, along with all the benefits it could bring to the business, the doors begin to open, and we finally start working on it with more support.

The Future

And after all, we want more. Now we are working to change the culture of the company, trying to share the knowledge we learned during our API development. We have presented two lectures for the whole IT department, and now other teams are on board, thinking about the value that they can deliver to their customers using APIs. Now our primary goal is to create a set of useful APIs for internal use, and after that, enable this list on an API manager. The next step is to increase the maturity of the API culture in our company and start opening up partner APIs.