I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.
The biggest challenge for big companies doing APIs is always about people and culture. Change is hard. Decoupling things at large companies is difficult. While APIs can operate at scale, they excel when they do one thing well, and aren’t burdened with the scope, and complexity of much of the software systems we see already operating within large companies. These large systems take large teams of people to operate, and shifting this culture, and displacing these people isn’t going to happen easily. People are naturally skeptical of new approaches, and get very defensive when it comes to their data, content, and other digital assets, as it can be seen as a threat to their livelihood–opening up and sharing these resources outside their sphere of influence.
The culture that has been established at large companies won’t be easily undone. It is a culture that historically has had a pretty large gulf between business groups, and the IT groups who delivered the last generation of APIs (web services), that weren’t meant to be accessible, and understandable by business users. Web APIs have become simpler, more intuitive, and have the potential to be owned, consumed, and even in some cases deployed by business users. Even with this potential, many of the legacy rifts still exist, and business users feel this isn’t their domain, and IT and developer groups often feel APIs are something that should stay in their domain–perpetuating and confusing existing challenges already in place.
While there may be small API success within large companies, they often experience significant roadblocks when they try to scale, or spread to other groups. A huge investment is needed in API training amongst not just business users, but also developer and IT groups who may not have the experience with the web that is needed to make an API program successful. This can be the most costly and time-consuming aspect of doing APIs, and with many APIs being born out of technical groups, and are often under-funded, experimental efforts, investment in the basics of web literacy, and API training is often anemic. Setting the stage for what is happening when you begin unraveling legacy systems and processes is essential to minimize friction across API implementations. Without it, humans and culture will be your biggest obstacles to API success.
Web literacy, and API training really isn’t much different than other areas where corporate training is being applied, but for some reason many companies just expect the technology folks to know what they know already, or problem solve and learn on the job. This might have been find when things got done in purely technical circles, but web APIs aren’t purely about tech. They are about leveraging the web to solve problems people face within a company, getting access to resources, and working with external partners to help move business forward. IT and developer staff aren’t always ready for this type of external facing roles, and if business users aren’t up to speed on what is needed, API implementations will stumble, sputter, and ultimately fail. Think of the partnerships it’s taken to make the web work at your company, everyone is using the web, why should it be different with APIs? If APIs are done right, and people are properly educated, there is no reason an entire group can’t work in concert.
Every API effort I’ve seen fail had one common road block–people. There were IT groups that sabotaged, sales teams that felt threatened, executive leadership who didn’t understand what was happening, or partners who were in proper alignment with API efforts. Sure, sometimes the challenges are purely technical. Lack of proper API design. Insufficient security or capacity. These are simply API training and education issues as well. You can’t throw the need for integration of resources between internal groups, external partners, or 3rd party developers using the web at any technical group and expect them to understand what is needed. Similarly, you can’t mandate APIs across business groups, and just expect them to get on-board without any friction. Invest in the web literacy skills, API training and awareness, and communication skills that will be required to do APIs right, and the chances your API efforts will succeed will greatly increase.
