A new group of users
It used to be the case that what we developed, as far as IT goes, was meant for our own organization. Take the example of the banks. When you wanted to withdraw money, you had to go to the branch office and ask the teller to give you money. The ATM machine changed that; we could suddenly withdraw money without human intervention. Online banking created a completely new situation in which we can do a lot of banking ourselves, reducing the need for people or office staff. When you look at what mobile banking is currently able to do, the entire process has become digital and fluid. Digital transformation has been a success and made the banking process much more streamlined. The branch offices are still there, but they are used for different things, more high value transactions (advising customers), perhaps even things that cannot be automated that easily or really need human help. Withdrawing money in a branch office is often done by using the ATM in the office itself.
Easy as pie?
One of the things they found, is that what’s simple for you may not be simple for other people. Designing services should therefore not only be done with yourself in mind, but also with other people. What we see, is that there are different roads to go. One road goes into the direction of redesign (like the car that drives itself and therefore doesn’t need a driver seat). The other road goes into the direction of designing in a way that’s clear to other people. So, what does this have to do with IT and especially your IT?
IT relevance
Developing for a different use case, e.g. client self-service, APIs require a redesign. An example: a bank employee should have access to a larger set of accounts and has more rights than the client on the mobile device who can only see his own accounts. This is the equivalent of the redesign of the car when it becomes self-driving. When you’re opening up your systems to third parties, whether they are clients or partners, you need to make sure a number of things are in place. One of the most important things is that you’ll have less of a captive audience than in your own business. By this I mean that your in-house developers will use your APIs, because they’re employed by you. External people have the choice whether or not to use your APIs, they might use someone else’s if they offer the same sort of service.
Furthermore, you need to make clear how to use it, since they have less knowledge of your IT systems. The key to engaging external developers is creating a community that facilitates a lively discussion about the APIs. Developers can request a new functionality and you can create even better APIs. After the design phase, there’s the whole operational and management phase of the APIs. Ensuring that developers using the API can do this in a way that matches their purpose, but also that other people can do the same. SLAs, management, monitoring and perhaps monetization are keywords in this aspect. The APIs that you offer aren’t offered as a hobby project, but as serious business that other people and businesses rely on. This of course requires an excellent API Management solution. Possibly even with an Enterprise Service Bus solution behind it. If you are interested in the key aspects of such a solution, read our whitepaper on API Management.
