I’ve been an Integration Architect in IT engineering here at MuleSoft for about one and a half years. When I arrived, our group had a full queue of potential development projects, but were still maintaining many legacy and point-to-point applications created by external developers outside of IT. Each application was designed well and accomplished singular goals that satisfied the use cases from the business owners, but it’s been challenging to maintain these legacy applications within the context of our ever-evolving products.
Additionally, the introduction of more use cases from the business owners and requests for new features posed an extra layer of complexity. To satisfy those needs, our group has had to refactor code or, in some cases, rebuild the application from scratch. With the large backlog of applications in the queue, often our team felt as though we were ‘spinning our wheels’ and not delivering as much as we could.
Our initial thoughts were to throw more resources at the projects. This approach is what IT organizations have been doing for years. But from our perspective, handling technical debt with the old IT approach is unlikely to set us up for success.
To tackle this challenge, based on advice from our customer success team here at MuleSoft, we initiated the MuleSoft at MuleSoft project for the IT group. This means that the IT engineering group would become the first customer of MuleSoft products and use them exactly as they were intended to be used.
Of course, we were already using MuleSoft products, but not in a consistent manner and not following accepted technology best practices. The lack of clearly defined standards for our group of architects and engineers in IT as well as the contributors that need access to the resources we manage created some issues that we needed to fix.
As a first step, we defined a clear set of standards: we created a template to initiate every application that included documentation. In addition, as part of these standards, we defined our source control methodology and required that all IT applications be API-led; this allowed us to expose core services while allowing secure access to reusable assets.
The introduction of governance for every project added the appropriate oversight, a layer of security, and analytics usage demographics. Minimizing our applications and services and exposing those services via APIs has increased and improved the reusability experience. Standardizing the processes for our applications has shrunk our delivery time while also improving performance. Feature requests are not holding us back but can be implemented quickly without destabilization. Secure APIs are exposed for external approved developers. Now, with the introduction of these standards and detailed documentation, we don’t expect technical debt to tie us down in the future. We can focus on innovative new products instead of patching legacy code.
Eventually, we took MuleSoft at MuleSoft to the next level and delivered even better results by utilizing a C4E (Center for Enablement). Look for my next blog post to see how we accomplished even more.
