Read more on the rising value of APIs and how organizations can use APIs to improve business processes and better align IT and the business.
Using Anypoint Platform to improve business processes at MuleSoft has been hugely successful. The good news is that with each successful integration, we are asked to do more and more and more, and we need to figure out how to manage the requests in a sustainable way.
As a rule, like most IT professionals, I find it a great deal easier to think about the projects in the pipeline like making sales more responsive by integrating Slack and Salesforce or automating pulling employee data into our stock management system exactly as they are presented to me – as a linear process that goes from some beginning to some end. It is easier to think about the projects this way for a very simple reason: because that is how business processes work. By nature, business processes tend to be very point-to-point.
Having the demand to complete business automation projects is a very good thing, but I noticed we were running into a problem. Since business processes are described in a very point-to-point way, each project in my list tends to be point-to-point as well. I was starting to think about doing the projects one by one, start to finish, one at a time. But that takes too long. I want to move faster and, of course, the business wants me to move faster as well. Could an API-led connectivity approach help?
Shifting from a project-by-project approach to deploying reusable APIs
There is an inherent comfort to point-to-point solutions in that it is easy to take a project as a standalone process and build automation around it. I couldn't get over this deeper concern though that what we would end up with is really dozens of projects that are all implemented as if they were completely independent of each other when in fact there were underlying shared needs.
We therefore decided to take a different approach. We took the entire project list of business processes that needed automation and decided to break each one down into pieces — services, if you will. Then, we grouped the pieces into functional unit groups. What we found in doing this was that quite a lot of the projects had many needs in common. In some ways, this is a very soa-like approach, but with templatized, well-documented, and reusable APIs that my entire team could use as needed, it wouldn't be a laborious effort to reuse these services for whatever project was on our list.
Reusable APIs that could speed up projects
First and foremost, a key common need that came up was related to sending notifications via email, Slack, or SMS. Since most integrations had this requirement the “notifications” APIs came up early as a quick win for us to deliver. The function of this API is to be able to post information about who to notify, how to notify them, and the content to send in the notification — and then have that delivered to the intended recipients. By creating this as a service, every project can leverage the API's capability rather than implementing notifications as a part of each individual project.
One of the most important aspects of having reusable APIs is knowing where they are and what they do. My team is growing and changing, and everyone needs to have visibility into what we have available, as do other teams throughout the company. We have a repository of all of our reusable APIs, templates, and best practices, and other assets called Anypoint Exchange, which is available to those who need it; once enabled by our central team, being able to discover these APIs is critical to being able to deliver projects quickly.
These assets, really products in and of themselves, can be used by the right people beyond just their creators or even just my team. These assets as well as the wider visibility in Anypoint Exchange saves development time on every project and provides a consistent way to implement notifications, governance, and management in all of our work.
We then focused on creating APIs in front of our CRM, HR, and expense/invoicing systems to provide access to read and write commonly needed objects that often take multiple API calls to cover. By building a microservice in front of those SaaS services, we remove the complexity of every integration project having to make two to four API calls to retrieve the data we are after or write the appropriate data into the system.
This is done by abstracting the process into a single API that we create. As an example, one microservice we call our “worker API” returns information about employees and their position in the organization, manager, office, and other information that is frequently needed in automating business processes associated with our workforce.
Finally, we have defined a set of APIs specifically associated with on-boarding and off-boarding employees and their access to key systems. We have decided to standardize on SCIM for account creation and are building APIs in front of our most common services that allow us to follow the SCIM object model for every SaaS application making user provisioning simple and consistent.
To give you an idea of the analysis, out of 20 integration projects we are considering or are already working on, we were able to identify 30 reusable APIs that can be built. Rather than focusing on the point-to-point processes that we want to automate, we are now focusing on how to make the data we need most often faster and easier to work with. Now that we have our list of microservices, we have begun developing quick RAML specifications and documented requirements for each of them. This allows us to have smaller deliverables overall.
By shifting our focus from individual project deliverables to reusable components, we plan to be able to deliver projects much more quickly. The reusable components also mean that the integrations themselves will be simpler in general.
