As companies look for ways to improve operational efficiency, the need to integrate
multiple systems and automate business processes can grow exponentially over the years.
This in turn creates complexity, and as a result increases the overall Total Cost of Ownership (TCO)
of integration platforms.
However, various integration platforms can have a very different cost curve over the years. Choosing the platform that will provide the lower overall TCO can be a complex decision, and involves many factors above the initial acquisition cost of the platform. This article dives into various cost drivers that are relevant when selecting an integration platform, and identifies the top factors that can help lower overall TCO.
Because the cost of ownership varies over the years, it is important to evaluate the overall TCO with a timeline in mind; the actual timeline varies, but many organizations look at a 5-year TCO analysis; so, we will limit this analysis to costs that make sense for a 5-year timeline. Separating the overall TCO into sub-categories helps with larger decision-making initiatives such as platform replacement, upgrades and staffing. Note that complex TCO calculations can have many cost categories, such as KLO (Keep the Lights On), MSP (Managed Service Providers) and more. For purposes of establishing a high-level TCO model, let's separate integration platform costs into two main categories: Platform and Integration.
An integration platform provides the necessary plumbing for implementing
specific system integration solutions. At first, implementing a new platform
involves the identification and rollout of the selected
platform, and additional costs such as ongoing maintenance, patching, and general support.
Once implemented, the platform itself rarely changes, and as a result the platform
costs can be very predictable (for Platform-as-a-Service (PaaS)
solutions, the Platform costs could be very low, and most of the TCO would shift to Integration Costs).
Platform costs include ongoing maintenance costs can be significant (sometimes 20% or more of the platform
Traditionally, platform deployment and management costs include initial acquisition, initial configuration, environment (licenses, servers), platform support maintenance, and ongoing support (a Full Time Equivalent (FTE) and/or Managed Support Provider (MSP)).
In the above chart, assuming an acquisition cost of $100, we are simplifying the Platform TCO to include roughly 20% yearly in maintenance cost from the initial investment made in Year 1, and we are assuming a platform upgrade in Year 3 for an additional 20% of the acquisition cost.
An integration project involves building a technical solution between two or more systems
on top of the platform. Integration projects include
those required for business process automation, employee onboarding automation,
B2B integration, system monitoring and more. This cost component includes building the
technical solution, and the ongoing maintenance of the various moving parts of the solution
that may need to be modified over time, such as changes in the system's API layer, security
standards, upgrades, and business drivers changing the integration requirements.
Integration costs usually include development, solution deployment, system connection licenses (such as ODBC drivers or additional connectors/adapters), and ongoing integration-related support (FTE and/or MSP). As a result, overall integration costs increase for every new solution added to the platform.
Calculating integration project costs can be complex; we will assume going forward that integration costs are divided into two sub-components: initial build and ongoing support. The ongoing support cost is usually proportional to the build cost; the more complex, and as a result the more expensive the initial build cost, the more expensive the ongoing support cost.
In the above chart, we are assuming an initial build cost of $100 for a single integration project, and a 10% maintenance cost every year thereafter to maintain this solution. Organizations typically build many integration solutions over the years; as such, this cost is cumulative in nature.
Once the platform and integration TCOs are understood, we
can start putting together what a 5-year cost curve could look like for a given integration platform.
For example, assuming a platform cost of about $50,000 in year 1, 10 integration projects at roughly
$15,000 each spread out every 6 months, and an SDK development fee of $25,000 (to extend the platform),
the total TCO for the integration platform would look something
With the above initial investment of $50,000, the Cumulative Overall TCO for a 5-year period for this integration platform is estimated to be about $358,000 assuming the individual project costs as stated previously. An additional $25,000 is earmarked as an Integration cost in Year 1 for the purchase of the SDK needed to extend the platform (we will discuss extensions later). This TCO curve should be considered a rough estimate only, used for illustration purposes, and provided as a starting point to calculate a TCO. Nevertheless, this curve can be used to discuss potential strategies for choosing the right integration platform based a TCO comparison of various vendors. In this example, we can see that the cost of building integration solutions surpasses the cost of the platform itself.
We can also see that the Integration TCO is, in this example, over twice the amount of the platform TCO itself. This important observation gives us a clue as to what to look for in an integration platform over the long run: complexity.
Now that we have a TCO baseline for a single integration platform, let's explore some of the key
factors that can help reduce the TCO numbers significantly.
Conceptually, the more complex the integration solution, the more time (and money) it takes to maintain it over the years. It is important to note that each organization will experience complexity differently; some organizations may already have the required skills to build systems using a specific platform, hence reducing the learning curve and project timelines.
However, if we limit this discussion to relative complexity between two platforms, two variables will matter most: the platform itself on which the solution is built, and the complexity of each individual integration.
Some platforms are harder to use than others;
for example, which platform will be more complex to maintain between MuleSoft and
SSIS (SQL Server Integration Services)? Or between MuleSoft and Boomi?
One way to infer complexity, at least
directionally, is to look at the availability of professionals that know the platform,
and their hourly rate. The idea is that the more complex the platform, the fewer the
number of certified professionals, and the higher their hourly rate.
Platform complexity impacts both the platform cost and the cost of all future integration projects regardless of their individual complexity. So, when it comes to comparing complexity of various platforms with the intent of driving a lower TCO, we can reduce the platform complexity discussion to a matter of resource availability (reflected by an Hourly Rate).
Each integration project can be
more or less complex. Defining integration project complexity involves multiple
factors, such as Lines of Code written, number of API calls made with external systems,
the language used to write the logic, authentication methods in use, number of decision
branches, external system complexity, custom extensions and more.
In other words, determining integration complexity can be... complex.
However, when it comes to comparing various platforms, some of the factors that drive integration complexity can be ignored. We are mostly interested in the factors that will vary based on the platform itself: relative effort, and extensibility. So to compare integration complexity from multiple vendors, these two factors can be viewed as the most influential:
Level of Effort (LOE) - in software, generally, the fewer the lines of code, the simpler the solution is, and as a result the simpler it is to maintain. However not all integration platforms allow you to code; some use drag-and-drop as an example. Drag-and-drop design surfaces are not necessarily simpler; many require specialized skills. As a result, this factor can be viewed more generically to represent the volume of work (in hours) to build a solution. In some cases, establishing a LOE required works better when it comes to comparing integration platforms, and apply a Complexity Factor (lower or greater than 1) to estimate the relative LOE of another platform.
Extensibility - extensions may be necessary when the platform doesn't support
the necessary external system(s), or if additional features are needed. Some platforms
can be hard to extend, require C++ skills, or incur additional development costs. In fact,
each integration platform vendor may have different options when it comes to extend their
platform; in some cases, a Software Development Kit (SDK) is required and is sold separately.
However not all platforms offer this capability; in this case, extending the platform could
require building custom services which could drive additional development hours.
The extensibility cost can be significant both in terms of initial development, and ongoing
support and license costs.
We discussed previously that the overall TCO was made of two separate costs: the platform cost, and the
integration cost. The former is largely driven by the vendor's acquisition cost and its associated
deployment/configuration costs, while the latter is driven by additional
licensing costs and development costs (which is a function of complexity).
To apply the Complexity Factor into the TCO analysis, we need to first baseline the level of effort with one of the platforms. Preferably this is an estimate of hours of work on a platform where the team has some basic knowledge; for example, if your team has knowledge of the MuleSoft platform, it shouldn't be too hard to estimate an average size integration project. Once the baseline LOE has been estimated on Platform 1, the team then estimates a high-level complexity factor for Platform 2. This could be based on industry analysis, documentation, prototyping and experience. For example, let's assume using Platform 2 simplifies development by a factor of 80% (so if it takes 100 hours to build a solution with Platform 1, it would take 20 hours with Platform 2). If Platform 2 also uses more broadly available resources (hence cheaper by the hour), the effect on the TCO will have a multiplying effect.
With the above definition, the Complexity Factor (CF) will have two effects: it will reduce the build
time (hence cost) of an integration solution, and it will lower the maintenance cost of the solution
over the years. We will use this formula to calculate the Development Cost of a specific
integration project with a given LOE, an hourly rate (that represents the platform complexity) and
an integration Complexity Factor.
Development Cost = LOE * Hourly Rate * Complexity Factor
Given the above formula and the following parameters,
|LOE||Hourly Rate||Complexity Factor|
|Platform 1||250||$150||1 (baseline)|
Avg Development Cost P1 = 250 * 150 * 1 = $37,500 Avg Development Cost P2 = 250 * 100 * 0.2 = $5,000
Now that we have outlined the important factors of establishing a TCO for integration platforms, let's compare two theoretical platforms with the following cost structure, assuming Platform 2 is cheaper and integration solutions are much simpler to build (CF = 0.2). Another important factor the availability of resouces to build solutions (reflected by the lower Hourly Rate).
|Platform 1||Platform 2|
|Platform Acquisition Cost||$50,000||$25,000|
|SDK Development Upcharge||$25,000||$0|
|Platform Maintenance Cost||20%||20%|
|Platform Upgrade (Year 3)||20%||20%|
|System Connector / Adapter (per project)||$5,000||$2,500|
|Avg LOE (hours) per Integration Project||250||250|
|Development Hourly Cost||$150||$100|
|Integration Support Cost||15%||15%|
While the initial cost of acquisition for Platform 2 is 50% lower, the overall TCO savings over 5 years is estimated to be close to 75% when using Platform 2. This is due to lower maintenance and license fees, and significantly lower complexity (which reduces development and support costs). We can see that the Integration TCO makes a significant difference for each platform.
The following factors contributed to the overall TCO differences of both integration platforms:
In this blog post we discussed how to create a Total Cost of Ownership (TCO) model using key factors that
can significantly influence the cost curve over a 5-year window. We also discussed how to incorporate
platform and integration complexity in the TCO model to account for efficiency and lower
maintenance costs over the years. We also discussed how to incorporate complexity into TCO
calculation models, both as a factor of Platform complexity and Integration development costs.
Last but not least, we compared the theoretical TCO cust curve of two platforms and reviewed the
primary cost drivers that can reduce overall TCO and influence platform selection.
To review how Enzo can reduce your TCO quickly and how it compares with other platforms, contact our sales team at firstname.lastname@example.org .
To try Enzo at no charge, download the latest edition of Enzo Server on our website and see how Enzo reduces complexity drastically compared to other platforms.
Over 50 adapters are available