This post was written in partnership with Green Irony and Alexander Solomon, Lead Insurance Industry Marketing Manager at MuleSoft.
Many IT leaders are predisposed to think, “Why do I need to buy a platform to handle my integration needs? I’ve been handling my integrations with no platform up until now.” I understand that perspective, and as a software architect with a career spent in middleware and back-end integration, I used to think that way too. But then I discovered MuleSoft’s Anypoint Platform and saw how it solves enterprise integration challenges as a strategic investment. In this post, I’ll outline the key considerations when evaluating a build vs. buy strategy for integration needs.
The details on why MuleSoft is so valuable for solving today’s integration challenges are deeply technical, and effectively communicating these complexities in a blog post is challenging. If you want to dive deeper into this topic, read The Value of MuleSoft Anypoint Platform. It provides a deep dive into build vs. buy along with a comparison ROI case study showcasing homegrown vs. MuleSoft for two identical scenarios.
The challenge of modern integration
Integration is an expensive area for enterprise IT organizations. A 2018 survey projected 63% of the $800 billion spent on integrations went toward keeping the lights on instead of innovation. What could you accomplish if you put that budget toward moving the needle for your business rather than treading water?
Today’s digital transformation initiatives levy incredibly demanding integration requirements that are afterthoughts to the business but must be executed by IT. These “afterthoughts” are a leading cause of business initiative failures. Every relevant system’s data must be accessible, and we must weave this data together into something meaningful for each digital interaction. But, many of these systems holding critical data were not built for today’s connected world. So our challenge is two-fold:
- Unlock systems that weren’t intended for use in the digital age.
- Build for the future with reusable patterns that minimize maintenance costs and maximize agility.
The traditional approach to systems integration calls for directly connecting one system to another, embedding all business and transformation logic within code that sits on one or both sides of the integration. These brittle point-to-point integrations are difficult to maintain and even more challenging to enhance or replace. They lead to what MuleSoft founder Ross Mason refers to as a “big ball of mud.” Everything is mushed together and interconnected, and as investment in new integrations in the enterprise grows, so does the complexity of the big ball of mud.
MuleSoft breaks this paradigm with an architectural concept called API-led connectivity. In a nutshell, this approach leverages APIs that provide contract-based inputs and outputs as reusable building blocks within a multi-tiered integration architecture. Leveraging this approach means that — unlike the big ball of mud — as the number of APIs grows, the complexity of each new integration shrinks. This approach decouples each system from the overall integration logic, fueling an environment where systems can be modified, sunset, or swapped without impacting other systems and integrations. This approach enables organizations to be more agile, or as MuleSoft eloquently states, “increase the clock speed of the business.”
But APIs have been around for a long time and are not specific to MuleSoft. So why do I need it?
Build vs. buy
While it’s true that API-led connectivity is an architectural strategy and not a toolset, going this route without the proper tools is ill-advised. Addressing non-functional platform capabilities like development tooling, infrastructure, security, deployment, and problem determination is necessary before starting on your requirements.
Organizations attempting a “build” path almost always under-estimate the number of technologies and the amount of platform-level development work necessary for success. See the list of required tools in our aforementioned whitepaper.
There are a number of technologies that must be mastered by development teams working in homegrown API-led integration environments, leading to steeper learning curves, overly complex development, and debug scenarios, and large IT investment allocations dedicated to platform code. The software will also need to be integrated together to work cohesively. Yes, you’ll need to integrate your integration tools as a prerequisite to tackling your backlog of existing integration requirements.
By investing in Anypoint Platform, MuleSoft customers manage fewer technologies and instead leverage a purpose-built platform to accelerate an API-led integration strategy through every phase of the systems development life cycle. MuleSoft’s R&D organization provides an ever-evolving integration platform that makes day-to-day challenges easier to solve quickly, freeing resources to drive greater business impact.
Total cost of ownership
The advantages we’ve discussed come together to create compelling numbers where it counts in IT: Total Cost of Ownership (TCO). MuleSoft’s lower TCO can be attributed to several key areas:
- Asset reuse
- Speed and agility to deliver more projects faster and unlock new revenue opportunities
- Development acceleration for new projects
- Savings on the maintenance of existing infrastructure
- Retiring legacy integration solutions and corresponding licensing costs
- Human capital cost savings by doing more with less
These are explored in detail in Forrester’s Total Economic Impact of Anypoint Platform. Our experience at Green Irony with the platform echoes and re-enforces Forrester’s findings. Additionally, the side-by-side comparison build vs. buy case study included in The Value of MuleSoft Anypoint Platform provides a more detailed look at the TCO of two companies who had almost identical use cases but with different sets of technologies driving them.
