Aleksei Akimov, Adyen

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore the world of APIs through the lens of business and engineering leadership. Joining me today we have Aleksei Akimov, head of API at the payment platform Adyen. I found Aleksei’s API-first journey to be really insightful, and I learned a lot from his approach, and found his embrace of standards and that strong belief in the power of APIs to be pretty refreshing.

Welcome. Who are you and what do you do?

Hello Kin, hello everyone. I’m Aleksei, or simply Alex. I’m the head of API at Adyen. I’m based in Amsterdam, and I’ve been a software developer, then switched to technical writing focusing on APIs and integrations, spent a good chunk of my time improving developer experience, setting up public developer relations, and now I’m responsible for Adyen API design, API strategy, and other API-related projects and processes.

What is Adyen? I know it’s a payment industry, payment API, but is it global, is it regional? What do you do?

Yeah, good question. So basically Adyen is a payments company with Dutch roots, and it’s indeed available globally nowadays. It started in 2006 but has become widely known only maybe in the last few years. Maybe we’ve heard a few years ago when eBay chose Adyen to become a payment service provider, and of course now with the pandemic everybody wants to go online, everybody is looking for a way to accept payments, so Adyen is becoming more and more popular, huge growth. And it’s interesting, because when I joined Adyen five years ago it was still a startup before IPO, so several hundred people, not more, 700 people for a startup. But just recently I’ve read in one of the articles where Adyen was referred to as a payment giant, and I was surprised, like, are we a giant? And looks like we are. So basically Adyen is now defining the face of the payment industry in many areas. We are serving as a global payments provider for many brands, and we provide payments on multiple channels like web, mobile, point-of-sale devices, all together presented in a unified commerce product where brands can also manage their shoppers and do a lot of analytics on top of that. And Adyen is presented in multiple regions in the world and is supporting more than 200 different payment methods globally, which of course also means a lot of complexity and customizations. In addition to that, Adyen is also providing APIs for marketplaces, for platforms such as eBay, as well as now provides card issuing and more products to come in the coming years.

It’s impressive. It’s definitely got to be a challenge to support all the different countries and regions and how people see the payment industry. I want to dive into your journey delivering those APIs, but I’m a little interested in how you ended up there. Did you join Adyen as a “hey, I know a lot about APIs, I’m going to come do APIs for you”?

Yeah, thank you for the question. When I joined Adyen I was only at the beginning of the journey. Of course I already knew the API world, but I joined as a technical writer focusing on APIs and integrations, because we were starting a team with a goal to really simplify the way we explain our integrations and APIs and have top-notch documentation on developer portals and everything. This was an amazing journey, we even won several developer portal awards, and then I was focusing also more on developer experience, also becoming like an advocate, externally, of what can be good for us to create great APIs, great API design, what the industry trends and standards are, and then started heading our API design efforts in general across the organization. So this is super exciting if you think about the scale of Adyen, the amount of things happening, the amount of APIs and services, but challenging at the same time, because everybody is doing things differently, and you always think, okay, what’s the big picture, what’s the vision, how can we harmonize all this, what’s the impact for our customers, and also what’s the impact for our developers, how can we make sure that all things work together?

So what, it feels like as a technical writer you were kind of the front line of questions and complaints and the pain that developers feel. Is that what drove you to want to refine the quality of the APIs and the overall life cycle?

Yes, correct. So as a technical writer, and also I always consider myself as a developer at the same time, I was able to try a lot of things to see really the complexity, where some things cannot be patched with documentation. Ideally we need to think how we can simplify our products. And there are always, in every organization, a great number of people working on the customer side, being able to see how you integrate with APIs, including technical writers, technical support, developer advocates, other developer experience folks. So all together, also at Adyen we have quite a big team of people helping other teams, product teams, when they’re developing APIs. We have applied processes and now also the API review group, where we can set up the guidelines, where we can own the vision of the API design, and we can help with proper tooling and proper design review sessions to make sure that we are creating great APIs altogether.

There’s a phrase used in the space called “API first.” You see it thrown around a lot, and it means a lot of different things to a lot of different people. Do you consider yourself API first?

Yes, sure. Actually when Adyen was started in 2006 it was already the API-first company from the beginning, because we were building the API platform, which was using a lot of services internally, but then you need to have APIs to connect to different card schemes and local payment methods, and externally of course you expose some APIs for your customers to be able to integrate with your platform. What’s interesting though, that traditionally we were mostly implementing the code-first approach. So of course there was a need to look at API design, to discuss it, to document it, but usually in this case we generate API, OpenAPI files, from code. What we started doing more and more, of course, in the last years, we started implementing the API design-first approach, where we spend quite some time in the beginning to discuss the APIs, where we can include also different people from different teams to really look at how the actual integration will look like, and then together with development teams start implementing these APIs that were designed. Obviously the biggest challenge here, that you cannot spend months and months on designing great APIs, you really need to be fast, you really need to have all the experts in the room from different teams, and all together you need to decide how the API should look like. At the same time your development team also wants to go further, they already want to develop your API. So what we noticed a lot, that quite often we are using a hybrid approach. We have API first for sure, but then it’s code first and design first, it’s a hybrid mode, we’re trying to combine both depending on what’s needed, how the team is going, what they prefer, what tools we have, how much understanding we have. And this is very exciting to see.

Yeah, I like hearing that, it makes me happy, because a lot of folks tend to position it as API design first versus API code first, you’re either one or the other, and so that it can live together, I think, makes me very happy. But would you say, is it more important for companies who are waking up to this, is it more important that you’re API first or that you’re API design first when you’re first getting started with this?

I would say, of course I’m a big fan of API design first, but I must admit it’s super important that you’re API first. So without API first it will be really difficult for you to build a successful company in the modern world, when everybody is going to digital transformation, building APIs, and you know this, an API podcast right now, right? API design first, it’s a very nice concept, but it really requires you to implement things in a perfect way. So you need to have good tooling, you need to have the right experts, and you need to have an ongoing discussion. It’s not something that you can do just once a month, so it should be also a culture of maybe enabling teams, or in every team in your organization. And this means that your other builders from the beginning, or if you’re already an established company you’re trying to see how you can support your teams to become design first. But yeah, it’s more important that you’re API first from the get-go.

Great, and I think it’s important that we separate that for folks and help them understand that. And another area that I see people stumble really quickly, a lot of people believe there’s going to be one API life cycle, start to finish, how you do APIs, and you just establish that and everything’s perfect and you do design first as part of that. How do you view the API life cycle? Is there one life cycle, or is there many ways to get the job done?

Yeah, it’s a brilliant question, because some time ago I really had a goal in mind that, okay, let’s build this perfect API life cycle and let’s make sure that every team is following that. And we did quite some extensive analysis with a lot of learnings. Actually, okay, this is a stage where it’s good to brainstorm on API designs, do some ideation, this is implementation, this is testing, documentation, this is where you do the pilot, test, and launch, and then eventually evolve and eventually deprecate. So it’s always good to have this big picture, but also we know that it’s a lot of iterations and it’s not waterfall, it’s agile, so it’s really always moving based on the feedback, and this is crucial. Then of course there are different teams, different products, different APIs with the different level of maturity, so in this case the life cycle really becomes diverse depending on where you look at. And what I found to be really important is to identify the areas that are critical for you to create good APIs. For example, you know that this team is starting, you need to know as you start, whether it’s with a Jira ticket as starting, or with some code commit or something else, so you need to monitor, you need to make sure that at this point API design is reviewed, or at least you have some basic understanding of that. Also what I learned from that, that on certain stages developers also just don’t know what to do, don’t have the right tools, don’t have the right guidance, and it’s our responsibility to provide these tools to make sure that we can optimize that, it’s not a bottleneck, so that they don’t spend the day on trying to figure out what to do in this case. So yeah, it’s good to have this picture, but at the same time you’re absolutely right, there are so many different life cycles, especially in a big organization if you look at Adyen, for example.

Yeah, I agree, that’s what I’m seeing across the space. And you touched on, I think, an important part of how you define or understand the API life cycle, is the tooling. The tooling really shapes how developers see it, either based upon the tools they already use or the adoption of new tools. How do you see tools affect the API life cycle and how your developers are delivering APIs?

I see tools as a paved road. So basically tools usually define the way how developers or other colleagues in your organization do certain things, and in some sense they also define your culture, in this case, which is a very interesting observation, I would say. In the beginning of my journey I was a bit blind, so I had an impression, okay, we made this nice API design, and now somebody else can do this in the way how we want it. But quite often it didn’t happen, and when I started looking at this I realized, okay, some frameworks that we are using, they just don’t let you do this in a nice way. So when you write code for that you naturally do a different thing, and that’s why I think having good tooling is super crucial, it’s important. And obviously if you think about API governance, API design, there are nice tools nowadays. We are using tools like Stoplight to collaborate on API designs, we are using Postman, because it’s a very nice combination, with Postman you can easily try a lot of examples, and this is also the way how you think about the integration, especially if there is a chain of calls, for example, you can easily test and have this collection always available for everybody who is having the discussion. And of course things like Spectral, for example, is really growing now, and it’s so easy because you can create a huge style guide with a lot of rules, but nobody is going to remember these rules, so you just automate it one by one and include it in your continuous integration so that every developer, before the commit, can already see, okay, is it compliant with what we want to do. So there are plenty of things that we can think of here. And in this case again, my biggest learning is that good API design is not only what you see to the outside, you really need to understand what tooling supports good API development and API life cycle.

Yeah, I agree, tooling is super important, even, like you said, even for us who know the processes. I know I’ve created hundreds of Spectral rules, but once I create them I don’t remember them, there’s no way I’m going to remember all those rules. So what about standards? How do standards fit into the life cycle and the tooling? You mentioned Spectral rules, this is very much about standardizing the design of the APIs, but wider, how do standards fit into how you deliver APIs?

I believe that standards make your API life cycle really powerful, because then everybody is using the same view, and everybody has the same expectations of how your API should behave, what should be there, how it should be documented, and then you can reuse this understanding by leveraging other tools that are supporting the standards. What I’m trying to say here is that, for example, OpenAPI, which is becoming super popular nowadays in the API community, and I think with version 3.1 it became a very mature standard, now when you document your APIs, whether it’s code first or design first, and store it in an OpenAPI format, then you can use other tools, for example import OpenAPI files into Postman and you can already have the basics of your Postman collection, or use Spectral or other things. I am very happy that now, by the way, we have more and more support from the community, and more and more companies are participating in the OpenAPI standardization and development. But also AsyncAPI is looking into ways how these two standards can be, I think, merged together, I don’t know, somehow combined, and this is brilliant because there are so many things happening. And the more tooling you have, the easier for you to implement this in your organization, but also at the same time to have the same understanding with your customers. In our case, for example, we expose our OpenAPI files, we publish them on GitHub, so everybody can just watch the changes, everybody can subscribe to that and use them to have a better in-depth understanding of what’s going on. And actually we can have much more information in these OpenAPI files than normally might be visible in documentation. For example, in our team we spent quite some time on researching inter-parameter constraints. So actually one of my team members had a master thesis working on identifying the ways of inter-parameter constraints in complex web APIs, and in our case it’s super critical because we have so many different payment methods, and for every payment method you need to see, okay, if you provide for example an address in this country you need to have this set of fields, in another country this set of fields, but also if you have this country then it should be this currency, and all these other dependencies for, I don’t know, your documents that you need to provide to do the KYC verification or things like that. All this is currently represented by a huge validation engine that is mostly part of our platform, but not so easy to expose, not so easy to document, and these things like inter-parameter constraints can be embedded with custom annotations in OpenAPI files, for example you can achieve this level of granularity. So that’s why I think OpenAPI is robust, and of course with support of community it can be much bigger. And in general I’m curious what other things, what other standards can help us all together to be on the same page, so APIs and people who are developing the APIs can easily talk to each other.

Yeah, so it sounds like, I mean, open standards and specifications play an important role, but it’s tooling too, right, open source tooling that supports those standards. It sounds like you have a mix of proprietary tools and open source tools that drive your API life cycle, am I correct?

Yeah, absolutely correct. In general, we assume that a lot of our tech depends on open source tooling, and this also makes us powerful, because then of course it’s evolving, and it’s evolving by the entire community. We see that in our case it’s super crucial that we also give back and support these open source frameworks and tools that are crucial for us, and we invested quite some time and also became sponsors of some of these frameworks, just to make sure that they’re developing, and this is also now becoming beneficial for the entire development community. Maybe another interesting point that I want to mention here, last year we did quite extensive work together with W3C, because we see a lot of benefits in developing standards around payments, for secure payment confirmation, that can become a standard sometime soon, and this is just one of the areas where Adyen as a payments company can help to make user experience better, but also to make interconnections between different APIs in different areas, and not only backend-to-backend APIs but also browser APIs and client-side APIs and other areas, to become more robust, more advanced, and available to the entire development community. I’m really curious to see what is coming in the next years, because there are more and more standards coming. Sorry, I really wonder how many wonderful things can come in the next years, because what we see, a lot of countries, a lot of regulators, they also realize that standardization is important. Now there is open banking and PSD2 and other initiatives. Of course I see there is still a long way to go to make it robust, but with all this support, with support from governments, when they started adopting OpenAPI files for different government APIs and organizations, I see that there’s so much to come, it will be so interesting to see where our industry will be in a few years.

You mentioned standards and government standards in PSD2. There’s been a lot of talk around PSD2 over the last couple of years, but Europe, France, Germany have kind of adopted their own version of that, the UK with Brexit has kind of adopted their own, so there’s actually differences in how each market is adopting these standards, and so there’s variances, but then even more, there’s countries adopting PSD2 that don’t even have to, they’re following the standards in Hong Kong and Brazil and other places. So how, standards sound like they stabilize your industry, but it also sounds like it can add some complexity if we don’t do this well.

I totally agree with you. Of course there is probably always two directions that we see. Sometimes countries and technology, they want to make everything more open, more compliant with each other, because it gives you the ability to grow and also to enable others to enter the industry, enter your market, and bring value to each other. At the same time, of course, maybe some countries, they want to have more regulations, maybe basically, I don’t know, the expectations like how the industry will go, or they want to have more control. And personally this makes me feel sad, because I really like what modern technology and what the internet brings to us, it really makes things easy, it really makes things interconnected. I will never imagine, 20 years ago, that I will be able to talk to so many people using Zoom and other technology, and now it’s possible. With a lot of tools that you have, you can achieve much better quality of life, much better fairness, and much more freedom in the world, if I take it to that level. At the same time this means that we need to help each other, we need to enable each other, and we need to have common ways of discussing things and common ways of connecting to each other. This means that API, in that sense, is one of the core technologies that we have right now to build the internet and to build all the future tools and platforms and services, whatever you can imagine. And the more it’s transparent, the more it’s enabling every new developer trying to build a new thing with this new API economy, the more efficient it will be for everyone, and the less disconnected world we will see in the future.

Yeah, I can’t agree more. I mean, this is why I’m doing the API game, and I believe in it connecting us in important ways. Unfortunately I also see it used not for very positive use, used to lock up things, consolidate power, maintain power, and other things. And so I’m a big proponent of the standards and government regulation to do this. But you also touch on the important point that I think is worth bringing out, do you think government should adopt OpenAPI as a standard, and AsyncAPI as a standard, for their own operations? Does it make it easier to deal with government? Because I know the Dutch government put out an official statement that they support OpenAPI and it is the official standard. So do you think this should be something every country looks at doing?

Yes, totally, because then every developer can easily see, okay, this is OpenAPI, this is APIs that, I don’t know, my municipality is providing, and you can integrate, and you can analyze, you can build fantastic things. So actually this way it will make our society much more open, and this will also lead to, I don’t know, a lot of other new products and new services and new communities and new discussions that we can build on top of that. If they would come up with a new appropriate standard for exposing APIs, this would make it much more difficult in this case, I would say. We already have OpenAPI, of course there are other standards as well, but OpenAPI is, as far as I see, widely adopted across the API community in general. So if all the governments start building the APIs and also describe them with the OpenAPI format as an API contract, this will make things much easier.

Agreed. So you talk about making things easy, and APIs can do that. There’s also a lot about doing APIs that can make things harder, and things aren’t always, it’s not easy to change an organization. You can’t just do APIs and the organization’s going to change. In your opinion, are the greatest challenges more technical, or is it more people and teams? What were the hardest things you’ve encountered?

I believe that these challenges rely on, I would call it culture, in your organization, and tech. So you cannot solve cultural issues with just new tools and technologies that you provided, and you cannot achieve the right changes in your development culture without the tooling. This is like the biggest learning that I have, so basically you need to always think about both and how this is combined. And there are a lot of big and small things that I learned from different discussions. For example, first of all, when you start talking about APIs, then maybe it’s important to understand what other people mean by an API, because some people think, okay, I made this service and this is my API, and this is done, and it’s working perfectly, it’s doing what they think it should be done. API is different in my mind, it’s much more, or maybe not much more, but it’s a different entity, it’s more like a product, an interface that you expose, and you need to think differently about that. And at the same time, for example, if you think about API design, again for many people it’s about, you know, studying some things, it’s about, I don’t know, camel case versus snake case, it’s about naming things, but design is much more than that. So it’s architecture, because the way you design your API, it defines how the people will be integrating that, what code should they run, what database structure they should have, what workflows they will be implementing, and sometimes your API then even affects the user experience that they will have, because they will have to show an extra page in between because you have this extra call, or your components required this to do. So this is quite complex, and yeah, I don’t have an answer to all this, but it’s an interesting challenge, it’s an interesting topic to discuss with each other. So that’s why I’m very happy that you have this podcast and are inviting so many people also coming to it and sharing the ideas, and I’m constantly listening to it.

Yeah, no, that’s what I really enjoy getting at, is, I saw early on, I’m a developer, I’m an old database guy, I’ve been doing databases since the 1980s, and I just see how it makes change, it can change organizations at the people level, it can make us work together. It’s brought in all kinds of relationships into my life, people that I know, other experts, other people who are super smart, way smarter than me, and connected me. But it’s not that direct API connection, it’s not that we’re all producers and consumers, but the journey around doing APIs is really rewarding, I would say. So do you think, are you going to keep doing APIs for your career, is this something that you’re happy doing, or was it just kind of this one stop along the way?

To be honest, I feel that I finally found what I was really looking for, because API, from one side it’s very much based on the technology, on the frameworks, on tooling, on decisions, so you really need to understand this part. At the same time it’s an art, it’s a craft, right, so there are a lot of ideas, we need to see more and make something beautiful, and if we go any further it’s a language that different machines, different applications are using, it’s an interface, it should be understood both by machines and people who will be implementing this. So it’s quite an interesting area, there is still so much that you can do there, and so many awesome people looking into that. I always meet a lot of great people at different conferences, now of course online, that we can discuss this, and the more I learn about APIs, the more interesting it seems to be.

Do you think you have to be a developer to be in the API game?

I think everybody should be a developer to some extent. Of course it means, like, “a developer” is also a very generic term. When you talk about developer experience, and when I look, okay, in some presentations they show like an image of a nerdy guy and say, okay, this is a developer, but in my opinion it’s a simplification. It can be different types of personalities, different experiences, it can be a backend, mobile developer, front-end developer, can be a developer working on databases. We all develop, and we’re all creating APIs, platforms, experiences, we all want to do something nice with this small piece of metal and other things that we have in front of us, and we’re all developers in this sense.

Yeah, agreed. I think the APIs, I mean, I always feel a little crazy when I’m talking to people, normal people, because I’m like, APIs exist everywhere, I see APIs, you know, I’m walking down the street, they’re behind the signs, they’re behind the cameras, they’re behind everything, the stop lights, in our pockets, they’re everywhere. And people kind of laugh at me like I’m a little crazy, and I’m like, no, no, they’re really everywhere, and I think everyone should be aware of them. And I feel like it’s similar to our personal finance and our banking and money. You don’t have to understand how the whole banking system works, and how ACH and all the different types of payment systems work, but you should understand that it exists, and you should understand who has access to your bank account, and you should have a little bit of awareness. And so I’m always trying to get people, normal people, understanding that APIs exist. And I’m going to call out my show assistant who’s not on camera, but LaTroy is helping me in this journey for season two, and he’s an API newbie, and we’re going to school LaTroy throughout this season, and I’m curious to see how he views the world when we come out of this season, because it’s an interesting world. So when you look around beyond Adyen, what APIs are important that you think people should pay attention to? I got a “lol” from him in the chat. APIs are important, always trying to convince people, help them see APIs out there. When you look around beyond Adyen, what APIs are important?

I would say everything that allows people to connect to each other, allows people to support their daily life. And again, I will mention payments, because I didn’t realize how important payments are until we came into quarantine, lockdown, for example. At the same time, all the APIs that are helping us to connect to people who are far away from us, or not far away, they sit in another building but then we still cannot talk to them, of course, I can imagine their APIs power and allow infrastructure. And I don’t know, health services, which are crucial for us to, yeah, basically to feel good and to support each other. Almost every API has its purpose, and in this case if it’s important for someone’s life, if it’s making our life easier, if it’s powering some user experience, some web, some good apps, some other things that are needed for us, I would say they’re important. So I am not the one who can judge on the importance of all the APIs, it’s up to every person looking, okay, what they’re using in daily life. As you mentioned, APIs are everywhere, and then you say, okay, in this case these APIs are crucially important, so you need to think about them.

What motivates you, what do you do outside of APIs, what makes you happy, other than programming and building APIs and making change that way, what do you do for fun?

I like to meet with my friends, I like to travel, and of course it’s becoming problematic in the recent years, but in general I’m still, I hope, you know, we can do this more and more often. I’ve got a wonderful family, my wife and three kids, so we love spending time together, playing outside, and maybe sometimes, you know, just disassembling some old computers and phones to see what you can find inside of them. So yeah, basically that’s what I like to do.

I really appreciate you being here today, Aleksei. This is, I mean, I love your view of the space, I love your view of the life cycle, and thank you for being with us, and I hope you can join us again in the future, maybe for some TL;DR episodes, some shorter episodes, and talk more about governance. But definitely stay in touch as you continue your journey.

Thank you very much, thank you for having me, and stay safe.

Thanks again to Aleksei for stopping by. For more on Aleksei Akimov, visit him on Twitter or LinkedIn. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, until next time.