When you consider the economics of IT systems, it's very easy to attribute almost all of the costs to primary development. This has its own logic: really, how much can it cost to integrate and support a ready-made system compared to the salaries of doses of expensive specialists who created it over months, and sometimes years?
But the actual practice is that initial development or implementation is usually only a small part of the total cost of owning a system. About the same as the visible part of an iceberg is only 10-15% of its actual size. This principle works when the system is poorly designed and is not properly integrated into the existing IT architecture.
In this article, we'll talk about what Total cost of ownership (TCO) IT systems actually includes and what components you should immediately put into the formula so that it doesn't turn out that an “inexpensive system” eats up half of your annual IT budget. There will be examples from KT.team wholesale and international practice.
What does the total cost of ownership of an IT system consult of
As a first approach, IT system ownership costs fall into three large groups.
1. Capital costs
The most obvious ones. This includes, first, the cost of developing or implementing the system. All the obvious costs that you or your contractor can calculate before the project even starts: system design, team costs, additional infrastructure costs, initial license fees, testing and deployment.
The second and often no less expensive part of capital expenditures is integration with existing systems. This component is influenced by the state of your architecture, the types of integrations used, and the availability of ready-to-make APIs and connectors for integrations between systems.
2. Operating costs
But this is where expenses start, which are more difficult to predict at the development stage.
Support and maintenance. The system requires constant monitoring, improvements, bug fixes and regular support.
As your business grows, you will inevitably have to adapt the system to new needs, refine existing integrations, and develop new ones.
For example, you have a PIM system for which you have collected the necessary class templates and product cards. But as your business grows, you'll add new product classes, new templates, and this will slow down your PIM and you'll have to look for other approaches. This, for example, was the case in one of our cases: to ensure performance system with a very complicated catalog, we had to add an additional Pimcore tool.
You will connect new sales channels: marketplaces, dealers; you will add new suppliers, you will process product relationships to ensure their cross-sale. All this will require improvements, which means the involvement of an IT team, additional infrastructure, integrations, tests, etc.
3. Indirect costs
It is not custom to talk about this block of costs out loud, but it is often the most expensive one.
Imagine that a CRM system, which you spent tens of millions on implementing and maintaining, will “fall off” for three hours at the height of Black Friday due to overload. Customers will come to your site, fill in their shopping cart, and... land on an endlessly loading checkout page. In just one failed Black Friday, you'll lose as much as you spent on implementation. An unpleasant customer experience that will cause you to lose regular customers will be even more expensive. it worth only three hours system downtime!
Another implicit risk is related to the team. If the system is constantly generating bugs, if integrations have to be constantly reworked, your team is always dealing with similar and exhausting support tasks. Ask any IT guy if such a routine is his ultimate dream, and they'll say no.
The routine will burn your team out, employees will start leaving and you will have to look for new ones to replace them. It would see that rotation in the team is normal. But instead of the standard 10-20% turnover, routine can lead to 30.50%. Which means: loss of key employees, costs of finding and training new ones, loss of motivation and efficiency for the entire team.
A direct consequence of high turnover will be and loss of knowledge. When system creators or key employees leave a company, they often do not leave complete documentation about the system. Those who “inherit” the system from them will have to figure out many of the nuances on their own — at the risk of breaking something at the most crucial moment.
How application and integration architecture increases TCO
The architecture of the system directly affects its cost both at the development stage and during further maintenance and scaling. Complex and closed systems can make it difficult to make changes, increasing the risk of downtime and costs. Here are a few signs that can be used to determine that the system's TCO will be high:
- The system has a closed architecture (“black box”) or poorly documented. If access to parts of the system is limited, it will be difficult or impossible to make changes on your own. The same goes for poor code documentation: it takes a long time to understand what each particular piece of code does, how it relates to other system functions, and what the consequences of a small change will be. The team will spend a lot of time on each change, and in extreme cases you will have to contact the vendor for advice and improvements.
- The system is incorrectly cut into services: there are signs of low cohesion and high coupling (about cohesion and coupling read more in one of our previous articles). Imagine that you have an e-commerce department and an accounting department in the same system. The term “product” can be used in the contexts of both divisions. But for accounting, a “product” is an item plus a price. And the e-commerce department understands a product in the same way as a customer: sneakers of the same model, but of different sizes, from this point of view, are the same product in different variations.
Who context and language will be “central” to the system, and who will have to adapt? Would this not disrupt the normal processes of sales, accounting and purchasing? How will it be necessary to coordinate every, even minor revision, because a change in one part of the system will affect the work of several departments at once? How much will it take to test and debug all parts of the system after each change?
- Integrations with existing systems are built on a point-to-point basis: this type of integration implies a strong interdependence of systems. Each processing within any of the systems will require the processing of all integrations that are associated with it. In reality, we can talk about a cascade of tens or hundreds of improvements.
- Rare technology stack or vendor lock risk: using specific technologies or solutions, or being tied to one supplier, can lead to dependence on a specific development team or to the fact that sooner or later the company will face costs due to the need to move to other technologies.
An example of poor planning is Netflix. When the company transformed from a DVD rental to an online cinema, it relied on a monolithic architecture, but as the number of users grew and the volume of content increased, the system could no longer cope with the load. Because of this, failures began, and it became difficult to use the service due to the high latency.
As a result, Netflix decided to switch to microservice architecture, which has significantly improved the flexibility and speed of development. Each microservice is responsible for a separate function, which makes it easier to test and update the system. The transition to the new architecture allowed Netflix to quickly introduce new features and quickly scale to meet growing demand. This solution also helped to reduce the system's response time and improve the overall reliability of the service.
“Do what you need to do” is one of the principles of reducing TCO
Doing nothing too much in IT is almost impossible. Just take a look at your backlog and the list of tasks you're outsourcing to the IT team. How many points are there: 10, 100 or more? And they're all important...
Or does it just see like it?
The tasks are endless, and in order to rank them by importance, you need to clearly understand your key limitations.
Several frameworks can help with this.
For example, you can build the company's main business process and figure out what restrictions there are at each stage and how much you can benefit from eliminating each of them.
Or build hypothesis map to determine which hypothesis (which implementation) will provide you with the maximum economic effect.
Using strategic planning methods makes it possible not to do too much and not replace meaning (changing economic metrics) with the number of tasks done. They will also help you understand what will really boost you and what will only increase the impact of key restrictions.
For example, a wholesaler of car parts wants to increase its revenue. Sales managers believe that developing a B2B portal where customers can submit requests for spare parts for cars and equipment will help increase revenue.
But before investing $10 million in a B2B portal, the strategic team decided to take a critical look at the processes. She built the company's key business process, analyzed the existing restrictions and realized that the bottleneck is now not the number of customers, but the speed of selecting spare parts from originals and analogues. Managers simply saw themselves up, choosing spare parts options from a dozen tables, internal systems and external portals to create a checklist for each customer.
This means that a B2B customer portal will not increase the number of successfully completed orders and will become a waste of the IT budget in this situation. We should look the other way.
Maintenance and scalability
A well-designed architecture makes it much easier to support and maintain the system. For example, systems with a microservice architecture are easier to test and update, as changes affect individual components.
The scalability of the system is also directly related to the architecture. Monolithic architects are always less flexible. This makes it much more difficult to adapt them to the company's changing requirements.
Weakly bound architects make it possible to design the system as a set of independent services that interact with each other through separate interfaces. This architecture works like a designer: individual components are easy to replace or modify without affecting the operation of other parts of the system.
The main advantages of loosely coupled architects are:
- Easy to maintain: errors and changes in one service do not affect the entire system. As a result, the costs of maintaining the system and introducing new features are much lower;
- Scalability: You can add new features and services without major changes to other components. It is much easier and cheaper to scale and adapt the system to new requirements;
- Fewer risks of becoming dependent on the team: the documented and transparent structure of the system makes it possible to recruit new specialists faster and cheaper and reduces the risk that the project will become indescribable.
In addition, loosely connected architects reduce operating costs. Each update or revision requires less effort and time, and the risk of critical errors is reduced because the components are separate from each other. This helps to avoid prolonged downtime system.
IN research (.pdf), held for the IEEE International Symposium on Computational Intelligence and Computer Science, says that companies that have switched to microservice architecture have noted an increase in the speed of deploying new features by 30-50%. Support and maintenance costs, in turn, fell by 20-40%. More, 70% of organizations reported increased flexibility and ability to adapt to market changes.
A few steps to help optimize TCO
- Conduct a detailed analysis of long-term business needs at the planning stage. This will help you choose an architecture that will scale with your company. Perhaps already at this stage it makes sense to contact an IT partner for a pre-project survey and implementation planning. This approach will allow you to plan the implementation and do exactly what you need.
- Choose a solution with a loosely coupled architecture from the options available. This way you will reduce development and support costs.
- Develop a plan for preserving and transferring knowledge and documentation to reduce risks when changing teams and facilitate the training of new specialists.
- Implement a system for continuous monitoring of productivity and costs to find problems in a timely manner and optimize costs.
- Review your TCO strategy regularly to take into account changes in technology and business requirements.
Remember that investing in high-quality architecture and smart planning at an early stage can significantly reduce costs through the entire system life cycle and increase its efficiency.
