There are numerous great reasons for using Anypoint Platform at MuleSoft. You might even assume that inside the company there would be little competition. But like many organizations, using Anypoint here required competing with the inherent desire people have to use custom code for integrations.
Custom code integrations have a natural gravity to them. The practice generally starts with the desire to satisfy curiosity about how using a service could be automated with an API and diving in with a common toolset such as Python, Ruby, Javascript, Powershell, etc. From there, the exploration of what is possible within an API begins to evolve into a whole other beast. And thus a custom code integration/automation is born. And from that comes this feeling of self accomplishment – that something was built from scratch – a custom tool has entered production. The proud creator of the custom code integration is excited.
That’s where IT at MuleSoft started too — custom code automations are a natural part of IT. They evolve out of the desire to automate repetitive work; in addition, they consist of components that IT understands. I myself have built my share of custom code integrations. As proud as I have been of what my team was able to accomplish with custom code, my chief concern revolved around the rigidity of these types of solutions. While writing custom code has significant benefits in developing a solid working understanding of the problem to be solved, I could not help but wonder about the long term value of the work.
- Would we be able to make custom code flexible enough to evolve with the business or would we end up spending significant effort re-writing whenever processes or needs changed?
- What value does the custom code bring as a stand-alone solution? How much effort will be required to make this consumable by other departments/services?
- Would the code used in all of the custom code integrations make enough sense to the team as a whole to be able to support and enhance them?
- Comparatively how much effort would be required to build solutions with a guaranteed long term value?
Building anything custom requires investment and I want that investment to provide long term value. I know from experience that flexibility and maintenance are the first things to wane as custom code grows.
In looking at achieving those goals using Anypoint, my team discovered very quickly that we could not only get rapid results, but that the process of prototyping, building, modifying, and testing were terrific. My team enrolled in the “MuleSoft.U Developer Essentials” course (it’s free!) and found ourselves exploring the platform’s capabilities at record pace. After only a half-dozen modules in the coursework we were already prototyping solutions to replace custom code.
But the much larger reason to pursue this effort has to do with the full yield we plan to get. Building the integrations helps us become deeply familiar with the business process associated with the systems and data. But what we really begin to see is the beginnings of a model for how we could build APIs around business functions. Building integrations with Anypoint allows us to create scalable automated processes now that we can later make consumable as business APIs using the exact same tools! Anypoint provides a common symbolic approach. My team can look at a “flow” in the UI and understand the function quickly. Other team members can modify and work with the integrations visually. Thanks to the assortment of connectors (especially the incredibly flexible HTTP connector) and the logical visual elements in the tool, my team can do much more than before and we can accomplish our goals in ways that have long term strategic value.
For more about how MuleSoft uses MuleSoft, check out this upcoming webinar:
