Transforming Into an API-driven Architecture

Background

APIs provide a way for software applications to communicate with each other. By standardizing the expected inputs and outputs, they make integrations fast and seamless. More and more companies worldwide are shifting to API-driven architectures to revamp service delivery and decrease the time-to-market. But the shift doesn’t come without its challenges. e.g., how to break a large monolith into multiple services that expose APIs? How to incorporate IAM into APIs? How to incorporate change within APIs?

Challenges Faced While Shifting to an API-driven Model

One executive mentioned how it was hard to convince the C-level execs to altogether ditch the legacy architecture in favor of a modern API-based model. He added that it took almost six months just to get everyone on board with the change. Another attendee added that the technology-aspect of the transformation is the easy part; however, making people forego technologies, tools, and approaches they have been using for a long time is the hard part. For the API-transformation to happen successfully, people need to be motivated to change and collaborate to make it work.

What prompted the transformation to an API-driven Architecture?

Many at the session agreed that delivering a better customer experience was the main reason for moving to an API-driven architecture. Allowing customers to transact with the company digitally and without much hassle. One speaker noted that they wanted to add more customer touchpoints, e.g., mobile and web-based interfaces. But doing that within a monolithic architecture seemed very cumbersome. The solution was to break down the monolith into microservices and consume/offer everything via APIs.

Hits and Misses While Implementing API-driven Architectures

An executive discussed how post-COVID, they felt the need to create an online leasing experience for their self-storage company. Since they were already using APIs and microservices, all they had to do was create a new UI and connect it with the relevant endpoints. Within two months, 20% of all their new customers were coming through this channel.

Another participant mentioned how they forgot about API versioning while architecting the model. API versioning allows API producers to make changes to APIs and release them in newer versions without breaking any existing implementations. However, without it, every deployment/consumer would have the same version, and making consumer-specific changes would not be easy/possible.

One of the participants mentioned how having an API-based model accelerated their solution delivery massively. They added that it acted as an excellent foundation for them to build great things on. Also, breaking down APIs into microservices goes a long way in allowing different teams to operate autonomously and manage their own respective source codes and changes effectively.

Where Does IAM Fit in API-driven Picture?

An attendee mentioned how they tried to build their own identity server, but it didn’t work, the main reason being the inability of the server to provide seamless authentication and access on multiple customer touchpoints. There was no way to provide social logins (Use Facebook or Google etc., to login). He also mentioned that there was no way to secure the APIs exposed to partners/vendors. A representative of a market leader in the space of IAM said how they shifted from using SAML redirects and proxies for MFA and SSO to using OAuth and OpenID. They also slowly started offering all their functionalities via an API-driven architecture. He said that the primary motivator for them was that thousands of their customers were using APIs to build their own customer experiences.

One executive stated that IAM has become a core service/requirement for most enterprises. To truly implement it in the right manner, a collaboration of executive stakeholders is needed. The IT team may own an IAM solution, but people from different teams (HR, legal, privacy, marketing, etc.) should be significant stakeholders in it as well.

‍