In our recent podcast episode, we spoke with Tanya Vlahovic, Head of the Developer Ecosystem and Lead API Architect at eBay. As one of the first companies to heavily utilize them, eBay’s successful API story is one that fascinates many in the API community.
We sat down with Tanya to learn more about the secrets to their success, advice for those who are beginning to build an API program, and how to arm yourself with the right tools to scale.
Good Governance Feeds the Technical Vision
“At eBay, we believe everything that applies to the public API should also apply to the internal private APIs, and good governance is how we do that,” – Tanya Vlahovic.
The quality of your internal microservices and private APIs directly impacts the quality of your public APIs. In her role, Tanya is responsible for taking care of the public API at eBay. Tanya emphasizes that everything that applies to the public API should also apply to the internal APIs, and having a strong technical vision can help with that. In practice, good governance can mitigate the challenges that stem from trying to follow this best practice.
“Good organizations with a strong governance program actually create a technical vision for the API. I include crosscutting concerns, vocabulary, and consistency. Standards and patterns really help in that whole governance process. They define what is constant across the APIs, and they define the security policies,” shares Tanya.
Practicing good governance like eBay ensures that every API created should fit that technical version, and the process should be transparent and objective.
Nurture a Blameless Culture
“We strongly believe that delivering a successful API is only possible when the teams are in power to innovate,” – Tanya Vlahovic.
eBay’s API success is partly due to what Tanya calls “a blameless culture,” and that culture stems beyond just DevOps. Tanya encourages her team to innovate on behalf of customers and enjoys the flexibility and risks that come with it. Fostering a blameless culture is a strategic part of eBay’s foundational success so that their team members feel safe to innovate and experiment.
“Truly connecting and communicating with the developers is vital; we pay a lot of attention to that. We partner with trusted developers, and that has worked very well for us. If you are building something for the first time, even internally, we collaborate on the internal APIs. We bring in cross-team collaboration at an early stage,” shares Tanya.
Part of fostering that blameless culture includes leaving ample room for cross-team collaboration, and the API team at eBay consists of all types of people. Their API team includes mature developers who have been with the group for over 20 years and new developers who bring various experiences and ideas to the table. eBay provides developer technical support to its developers to help them grow.
eBay also has architects in their organization who participate in all of their forums to ensure that everyone has the resources they need to succeed. Together, all these teams work with feedback groups and customer cohorts to understand what’s most important in their API design.
Then, the developer team can utilize that feedback and innovate until they get it right because they have the safe space to do so. Tanya expresses how APIs are for developers, so it’s imperative that your APIs meet developer needs.
Tanya pushes her team to understand the problem statement they are trying to solve, challenge requirements, and approach every design with a healthy degree of skepticism. Their process involves a starting point of defining use cases, relevant actors, constraints, and actions that end-users may need to take with the API.
In addition, Tanya encourages teams to think about the direction the API will evolve because the chances are that all will at some point. Her developer teams will often put placeholders for eventual extensions in the original API design to account for the future possibilities of innovation.
Bring Older APIs into More Modern Technologies
“We started our process based on the older APIs that are heavily used that bring more value to us. We try to understand exactly how our developers leverage our APIs, how they would integrate without APIs, and how we can update them,” – Tanya Vlahovic.
Iteration is a key part of eBay’s API strategy, which means constantly improving on older APIs to meet the customer needs of modern technology. When looking at which APIs to update, Tanya’s team creates a vast data set of sample developers so that they can understand and calculate the value of every single developer’s application. From there, they assess their API’s value and the value that it brings to eBay.
To determine the value that a particular API brings, their team relies heavily on direct feedback by collaborating with third-party developers, especially when launching additional capabilities or piloting something new. Tanya stressed that indirect feedback is equally important. The data from that feedback is the primary driver to advise their iteration strategy.
“From the data, there are operational metrics and business metrics. These things tell us whether our platform is stable, the scale we operate, and all sorts of things. But then the business metrics are equally important because that’s what can help us figure out how to grow our revenue,” shares Tanya.
View Your APIs as Products
“We actually consider our APIs to be products, and they are first-class products at that. We have a really large and powerful ecosystem of third-party developers and applications that add value to us as well as to our buyers and sellers, which means we truly rely heavily on the developer model,” – Tanya Vlahovic.
Tanya explains how they view their APIs as building blocks that developers put together in a unique way, involving all sorts of different integrations. Developers use their APIs to do a variety of things, including being managers, sellers, and business owners; scaling to provide logistic services, providing bookkeeping services, handling marketing, etc.
“We allow all developer parties to take all of these building blocks and uniquely combine them and from that create great quality experiences. We design these APIs and maintain them so that these developer groups can provide good products to their customers,” shares Tanya.
Starting from Scratch, eBay’s 5 Steps
“It’s painful at the beginning when you’re building out an API program. It isn’t easy. I keep saying if you have four architects in the room by the end of the discussion, there will be at least five suggestions because at least one will change their mind before the end of the meeting,” – Tanya Vlahovic.
For those starting an API program from scratch, here is Tanya’s advice for building a solid foundation for an API program.
- Find the right partners. Partner with the architect from your organization and partner with the business as well to understand the vision for the program, because once again, there is a technical vision and a business vision that need to be aligned from the start.
- Build out the technical vision. Explain what the benefits are of having a consistent API portfolio and then just be patient. Spend a few months trying to get aligned and develop some concepts, standards, and best practices.
- Keep Iterating. Keep innovating, keep changing, keep listening to the field, and keep evolving. But, try to have a team of people who will support that endeavor and create that space to innovate.
- Create a Good Developer Experience. The developer experience is critical to a sound API program, and there are five main pillars of developer experience that make up a quality program.
How to Create a Good Developer Experience
- First, Give them the Right Tools. think building blocks, API feeds, event notifications, SDKs, dropping solutions for Widgets, etc. Check out what API design tooling is available for you.
- Focus on Customer Satisfaction as the Second Pillar. APIs have to be intuitive and easy to understand and consume because they are for human developers. And that customer satisfaction is one of the crucial metrics to measure the success of the API program because it helps streamline integration.
- Documentation is the Third Pillar. The API contract should be intuitive and easy to understand; developers are not supposed to study the documentation to know how to integrate with the APIs. However, documentation is essential to tell a story.
- The Fourth Pillar is Support. Arm your developers with reasonable technical support, and have forums and multiple points of communication and connection for them to tap into.
- The Final Pillar is Growth. Just because you release your APIs doesn’t mean they are done. Enable your team to continue to innovate and grow with the business and take feedback from users seriously.
To hear more stories like Tanya’s and the eBay API team, subscribe to our podcast on your favorite streaming service.
