Great! "It's Saturday morning, I only dream of one thing, go buy new tires for my car! Let's be honest, I hope you never said that in real life. No doubt you have never experienced the slightest pleasure when buying and changing your vehicle’s tires. You've certainly waited until the last moment, you've certainly cursed the mechanic and his exorbitant rates, and you've certainly grabbed the best available promotion, without really worrying about the TCO (total cost of ownership) of your tires. Rest assured that’s normal. Even though this is not the best way to make this kind of investment. Nevertheless, if you do this when choosing an integration platform,it is more troubling!
Indeed, your tires are one of your car's essential elements. They are the interface between it and the road. Their condition determines your safety, whatever the weather; but tires also play a major role in your fuel consumption - their condition could affect 20% of fuel consumption. By choosing your tires too quickly and without a precise study, you make a choice that will have a major influence on the grip of your vehicle and the cost of your trips, for several years and tens of thousands of kilometers.
Of course, I'm not here to talk about the holidays that just ended, but about your information system. The comparison between the data integration functions of your information system and the tires of your car is relevant. It's all about the total cost of ownership, and how to keep it under control.
I could have drawn another analogy, that of your home's pipes, and the plumbing cost ... it doesn't matter, you have grasped the idea. By focusing on one part of the integration cost - often the initial purchase of a software - sometimes you make a bad decision over the long term. Whether it's tires, plumbing or data integration, what's important is the overall cost. By focusing on just one of the components, you have the impression of getting rid of the problem. In fact, you risk paying a lot more for it, a few months later.
Selecting software is more and more complicated
In the early 2000s, at the peak of the traditional software world, it was relatively simple to calculate the software cost. We bought a license, an investment that amounted to I, as well as an annual maintenance contract M, and we evaluated the use of it all over a number of years n.The overall cost was, therefore, the present value (VA) of the whole:
Software Investment Cost = VA (I + M x n)
Today, companies' offers are more complicated to compare. You can still invest the same amount I, but you can also choose an "as a Service" offer ("aaS"), the cost of which will depend on several factors, like the number of users, usage (number of flows, volume transferred ...), machine power, and sometimes ... depending on the creativity of the company in question, the age of the commercial director.
It becomes almost impossible to guarantee the amount of the investment over several years, except by making some assumptions, which from the beginning are known to be false. Moreover, the notion of investment no longer exists. While the software license purchase could be amortized over one to two years, an "aaS" contract becomes a variable cost.
It is, of course, interesting for a company that wishes to match its degree of use with its invoice, but it all depends on the duration of use.
And I'm not talking about "open source" solutions, whose appeal product can be apparently "free" but whose gratuity is largely compensated by selling complementary modules, maintenance and provision of services at a high price.
According to a study conducted in 2016 by the CXP (French analysis group in the information technology sector), the average duration of use of an ERP is 9 years.
In terms of data integration, I often meet clients who are considering investing in a software tool for at least ten years, in some cases for up to 20 years!
By the way, this is also the minimum lifespan of a good pipe. And for a good tire, it's 50,000 kilometers ... a little less than 5 years.
So, how to calculate the cost of our software investment? First of all by being realistic about the number of years.
Some "aaS" companies will give you advice for the short term. "Yes, Mr. Customer, our software, over 3 years, is much cheaper than that of our competitor" ... certainly over 3 years ... but what about 5 years, 8 years, 10 years ...? The calculation will be different.
In the case of an investment, once the amortization is completed, only the maintenance is invoiced. The extra year of use is not very expensive. In the case of an "aaS", each year will cost you the total price of the subscription.
- Begin by realistically estimating the actual duration n, during which you plan to use the software, and its subscription A;
- Anticipate year after year, the growth of the variable v used by the software company (number of users, data volume, number of flows ...);
- Anticipate year after year, the coefficient of possible subscription increase p, for example, 1.05 for 5% annual increase;
And apply the following formula to several hypotheses:
Software "aaS" Cost = VA (A (n1) + A (n2) x p x v + A (n3) x p x v + A (n4) x p x v + ...)
You will then have a way to compare between the investment and the rental model.
And for safety, you will also calculate the cost of an extra year in both models.
I know from experience that you will undoubtedly find that over a short period, less than five years, the variable model has the advantage, but over a longer period, the traditional model is much less expensive. The equilibrium point is often between 4 and 5 years.
Do not forget the operating costs
The software is only part of the investment, and often the smallest one, although we usually focus on it.
The indirect costs of running the software are critical, and again the new cloud offers do not simplify comparisons.
It's a fact, everyone goes to the cloud. But be careful, this does not mean that there are no more IT costs. It is the service provider who takes care of them; Of course, he makes enormous economies of scale, but these costs are billed to the customer.
The hosting service costs will have to be calculated and compared with an internal solution. Remember that all options are possible: software billed "aaS" on an internal platform, software purchased but hosted in the cloud, software "aaS" in the cloud, and purchased software hosted internally.
It is for this reason that we will separate the two equations, those for the calculation of software cost and that for the calculation of its operating costs.
The formula for calculating the operating costs will be based on:
- The cost of machines M
- The cost of storage S
- The cost of bandwidth BW
- The cost of managing the whole Mg
- Not forgetting the hypotheses of growth, uses, and prices
And we will calculate again the present value VA of the whole, over the envisaged number of years of exploitation.
Operating Cost = VA ((M + S + BW + Mg) n1 + (M + S + BW + Mg) n2 x p x v + (M + S + BW + Mg) n3 x p x v + (M + S + BW + Mg) n4 x p x v + ...)
Can we also put the human component into the equation?
It is undoubtedly the hardest part to anticipate. How long - and at what cost - will it be necessary to develop and evolve the different integration flows?
Indeed, data integration is not a finite duration project. To be honest, once again, you have to accept that a data integration project is never finished.
An easy way would be to count the number of data streams to be integrated, and to multiply it by an average number of days ... this gives you ... a very big approximation. What are the challenges you will face in reality?
- Your integration work will spread over time; several people will be in charge of different integration processes, sometimes developed in parallel;
- On the same integration batch, several people will succeed one another; perhaps you will create a team specifically in charge of the management and development of data flows. The management of these teams will be a key point;
- Integration is a work of data transfer between a point A and a point B. But A and B evolve, just like the details of the path between them. Integration flows must be maintained, evolve according to needs.This maintenance of flow development must, therefore, be budgeted.
Impossible here to write an equation of the human costs of integration. But, depending on your activity and your organization, you will think about writing your own formula, again taking into account a realistic lifespan of your integration platform.
I have tried in this article to share with you a calculating method for the full cost of data integration. What is the underlying message? You got it. Do not focus excessively on the initial software cost. It would be like choosing a tire based solely on its price, regardless of the number of kilometers it will allow you to travel, its wear, the installation cost, etc.
An integration platform whose costs you have miscalculated is like a leaky pipe. It may have cost you less initially, but every month you lose 10% of your water consumption. It doesn't matter? So, no problem, do not change anything. But if you are a responsible manager, you will understand that it is better to build your integration platform on a good basis, and avoid leaks.
Do not underestimate the total lifespan of your integration platform, be honest in your forecasts, and calculate separately the three elements: total software cost, total operating cost, annual human cost of integration tasks.
Mastering all the components of data integration cost, modeling it to understand it, then optimizing it, is finally, as the slogan of a large tire manufacturer says, "a better way forward." Have a safe journey towards an intelligent management of your integration costs.
About the Author
Senior account executive at Stambia, engineer with a master's degree in computer science at INSA de Lyon.
Jean-Noël has more than 15 years of experience in the data sector and particularly in the field of data integration.
He began his career in an SI (System Integrator) specialized in digital transformation (7 years with Astek) followed by 8 years at DIMO Software, System Integrator and software company.
In 2014, he moved to the developer side by joining Stambia, an agile solution specialized in data integration.