Our Roundtable Sessions are invite-only events hosted by peers for peers that bring together a select group of senior IT leaders from across industries for topic-driven, intimate, dialog on current trends and topics. We hosted two Sessions featuring a group of CXOs and other IT executives. The groups met remotely to discuss transforming into an API-driven architecture, one led by the EVP Global Operations and CTO of a global packaging and brand experience company, and one led by the VP IT, Head of Corporate, Risk & Operations Technology of a financial services company. The Sessions wer sponsored by Okta.
APIs help create performative, scalable, and maintainable software applications. They enable companies to seamlessly integrate with third parties and deliver data to their customers across different channels and devices. But what does it take to transform into an API-driven architecture? What are some of the challenges, and how can they be overcome? Is it possible to go from an ecosystem with multiple monolithic applications to a micro-service architecture with APIs?
During the discussion, different speakers shared their organizational drivers for API transformation. One said they had been rapidly moving to the cloud, and they could not do that without API integrations. Another mentioned that they need APIs to fulfill the regulatory demands of the federal government. Some speakers added that APIs enable them to stop “reinventing the wheel” and reuse the same applications in different places— saving time and money.
Other common drivers were:
An executive recounted their company’s API transformation journey. Originally, large batches of data used to flow through many of their legacy, monolithic applications. This was a slow process, which compromised the overall efficiency of their organization. To fix this, they started breaking down some applications into micro-services and used APIs to speed up the flow of data. However, they did not break everything into micro-services. Some applications remained monolithic and consumed data batches as it was not architecturally feasible to refactor them. It is important to remember that being API-driven does not mean that everything must be integrated/exposed/built as an API.
APIs are a great tool for data delivery and analysis. However, to build scalable and performant APIs, you need to have a well-designed data architecture. You cannot simply move from a legacy monolith (that uses servlets, e.g.) to an API-driven web server without first adapting your data. If you continue to use the old data models without any optimizations, you may not reap the maximum benefits of APIs.
A speaker told the audience that it is important to shift left while designing APIs. Security should not be an afterthought— rather an intrinsic feature of your architecture. It is important to have an identity management system that allows you to define access policies following the principle of least privilege. You should also use multi-factor authentication wherever applicable. Data should be encrypted at both rest and in-transit using cryptographically secure encryption algorithms.
A participant stressed that customers today want information at their fingertips. They want to be able to engage with a company’s products from different channels (smartphone, laptop, smartwatch, etc.) seamlessly and quickly. They do not want to wait for X number of business days to get a response; they want to hear back in real-time. APIs help companies meet these rising customer expectations. Regardless of which device a customer is on, APIs can help provide them with fast and easy access to all the data they need. Whether real-time order tracking on a smartphone application, refreshable inventory details on an online store, or integrations with other providers (Google, Amazon, Microsoft, etc.), APIs let you do it all.
An attendee remarked that their main challenge was, “where do we begin?” There were so many interconnected, monolithic applications, and they could not decide the starting point for their API transformation. They soon realized that the IT department could not do it alone and had to onboard business stakeholders to find out what mattered most to the company. The first step should be identifying your topmost priorities, establishing a roadmap, starting small, and going from there.
Getting different functional units onboard with the architectural shift can also be challenging. People who have been developing monoliths all their life may not be overly eager to embrace APIs. You may also have to train your workforce in the new technologies needed to implement APIs.
Cost is another challenge that companies face while moving to APIs. All-in-one platforms for building and managing scalable APIs are often very expensive, especially for smaller organizations.