#esb#integration#team

How Much an IT System Really Costs and Why Development Is Only the Tip of the Iceberg

We break down IT TCO: what makes up the total cost of owning a system, which costs are often forgotten, and how to reduce them.

  • What makes up the total cost of ownership of an IT system
  • How application and integration architecture increases TCO
  • "Do what is needed" is one of the principles for reducing TCO
  • Maintenance and scalability

  1. 19.11.2024 How to calculate the economics of owning an IT system, what to include in the calculations, and what hidden, costly risks to watch for. We explain what can be done to reduce the Total Cost of Ownership of an IT system.

  2. The article was published on the KT.Team blog on vc.ru. Reading time: 9 min.

  3. When calculating the economics of IT systems, it is very easy to attribute almost all costs to initial development. There is some logic to that: after all, how much can integration and support for an already finished system really cost compared with the salaries of dozens of expensive specialists who built it over months, and sometimes years?

  4. But the reality is that initial development or implementation is usually only a small part of the system's total cost of ownership.

  5. Much like the visible part of an iceberg, which is only 10-15% of its true size.

  6. This principle applies when a system is poorly designed and improperly integrated into the existing IT architecture. In this article, we will talk about what actually goes into the Total Cost of Ownership (TCO) of an IT system and which factors should be included in the formula from the start, so that an "inexpensive system" does not end up eating half of your annual IT budget.

  7. There will be examples from KT.Team's experience and global practice.

What makes up the total cost of ownership of an IT system

At first glance, the costs of owning an IT system fall into three major groups.

Capital expenditures are the most obvious. First, this includes the cost of developing or implementing the system. All the direct costs that you or your contractor can estimate before the project starts: system design, team costs, additional infrastructure, upfront license fees, testing, and production deployment. The second, and often no less expensive, part of capital expenditures is integration with existing systems.

This component is affected by the state of your architecture, the types of integrations used, and the availability of ready-made API and connectors for integrations between systems.

Operating expenses This is where the costs begin that are harder to predict during development. Support and maintenance. The system requires constant monitoring, enhancements, bug fixing, and regular support. As the business grows, you will inevitably need to adapt the system to new needs, improve existing integrations, and build new ones. For example, you have a PIM system for which you have set up the required class and product card templates.

But as the business grows, you will add more and more product classes and new templates, and that will slow down your PIM, forcing you to look for other approaches. For example, in one of our cases, to maintain system performance for a very complex catalog, we had to add an extra Pimcore tool. You will connect new sales channels, such as marketplaces and dealers; you will add new suppliers; and you will redesign product relationships to support cross-selling.

All of this will require modifications, which means involving the IT team, additional infrastructure, integrations, testing, and more.

Indirect costs This cost category is not usually talked about openly, but it is often the most expensive one. Imagine that a CRM system, on which you spent tens of millions to implement and support, goes down for three hours in the middle of Black Friday because of overload. Customers will come to your site, fill their carts, and then... land on an endlessly loading checkout page. In just one failed Black Friday, you will lose as much as you spent on implementation.

A poor customer experience that causes you to lose repeat buyers will cost even more. That is the cost of just a three-hour system outage! Another hidden risk is tied to the team. If the system constantly generates bugs and the integrations have to be rebuilt all the time, your team spends its time on repetitive, draining support tasks. Ask any IT professional whether that kind of routine is their dream, and they will say no.

Routine will burn out your team, employees will start leaving, and you will have to find replacements. Team turnover may seem normal. But instead of the usual 10-20% turnover, routine can push it to 30 or 50%. That means losing key employees, spending on recruiting and training new ones, and losing motivation and efficiency across the team. A direct consequence of high turnover is also knowledge loss. When the system's creators or key employees leave the company, they often do not leave complete system documentation.

Those who inherit the system from them will have to figure out many details on their own, with the risk of breaking something at the worst possible moment. End up in that position? No, thanks. Better calculate TCO in advance.

How application and integration architecture increases TCO

System architecture directly affects its cost both during development and later during maintenance and scaling.

Complex and closed systems can make changes harder, increasing the risk of downtime and costs.

Here are several signs that a system's TCO will be high:

The system has a closed architecture (a black box) or is poorly documented.

If access to certain parts of the system is restricted, making changes in-house will be difficult or impossible.

The same applies to poor code documentation:

  • you will have to spend a long time figuring it out
  • what each specific piece of code does
  • how it is connected to other system functions
  • what the consequences of a small change will be

The team will spend a lot of time on every change, and in extreme cases you will have to turn to the vendor for advice and custom work.

The system is split into services incorrectly: there are signs of low cohesion and high coupling (read more about cohesion and coupling in one of our previous articles). Imagine that your e-commerce division and accounting department work in the same system.

The concept of a "product" can be used in both departments' contexts.

But for accounting, a "product" is an SKU plus price

The e-commerce team also sees a product the same way a customer does: sneakers of the same model but different sizes are, from this perspective, the same product in different variants.

Whose context and language will be the system's main one, and who will have to adapt?

Will this disrupt normal sales, accounting, or purchasing processes?

How will each change, even a small one, need to be approved, since a change in one part of the system will affect several departments at once?

How much will you need to budget for testing and debugging across all parts of the system after each change?

Integrations with existing systems are built on a point-to-point principle: this type of integration implies strong mutual dependence between systems.

Every change inside any one of the systems will require changes to all related integrations. In practice, this can mean a cascade of dozens or even hundreds of modifications.

A rare technology stack or vendor lock-in risk: using niche technologies or solutions, or being tightly tied to a single supplier, can lead to dependence on a specific development team or to eventual costs from having to migrate to other technologies. Netflix is an example of poor planning.

When the company transformed from a DVD rental business into an online streaming service, it relied on a monolithic architecture, but as the number of users and the amount of content grew, the system could no longer handle the load. This led to outages, and the service became difficult to use because of high latency. Netflix was as fragile as dalgona candy. In the end, Netflix decided to move to a microservices architecture, which significantly improved flexibility and development speed.

Each microservice is responsible for a separate function, which simplifies testing and system updates.

The move to the new architecture allowed Netflix to roll out new features quickly and scale rapidly in response to growing demand.

This solution also helped reduce system response time and improve overall service reliability.

Assess where AI can deliver impact in your process

clients@kt.team Telegram @kt_team_it

"Do what is needed" is one of the principles for reducing TCO

  1. Avoiding unnecessary work in IT is almost an impossible task.

  2. Just look at your backlog and the list of tasks you hand over to the IT team for execution.

  3. How many items are there: 10, 100, more? And are they all important... or does it just seem that way?

  4. There are endless tasks, and to rank them by priority, you need a clear understanding of your key constraints. Several frameworks can help with this. For example, you can map the company's core business process and identify the constraints at each stage and how much you can gain by removing each one.

  5. Or build a hypothesis map to determine which hypothesis, meaning which implementation, will deliver the greatest economic impact.

  6. Using strategic planning methods helps you avoid unnecessary work and avoid replacing real outcomes, meaning changes in economic metrics, with the sheer number of tasks completed.

  7. They will also help you understand what will actually give you a boost and what will only amplify the impact of key constraints.

  8. The wheel is a boost to speed and load capacity.

  9. But only if you choose the wheels wisely. For example, a company that wholesales auto parts wants to increase its revenue.

  10. Sales managers believe that developing a B2B portal where customers can submit requests for selecting parts for cars and equipment will help increase revenue.

  11. But before investing 10 million in a B2B portal, the strategy team decided to take a hard look at the processes.

  12. They mapped the company's key business process, analyzed the existing constraints, and realized that the bottleneck was no longer the number of customers, but the speed of selecting parts among originals and equivalents.

  13. Managers are simply swamped, picking parts options from a dozen spreadsheets, internal systems, and external portals to prepare a quote for each customer. That means a B2B portal for customers will not increase the number of successfully closed orders and, in this situation, will be a pointless use of the IT budget. You need to look elsewhere.

Maintenance and scalability

A well-designed architecture greatly simplifies system support and maintenance. For example, systems with a microservices architecture are easier to test and update because changes affect individual components.

System scalability is also directly tied to architecture.

Monolithic architectures are always less flexible

Because of this, it is much harder to adapt them to changing business requirements. Loosely coupled architectures make it possible to design a system as a set of independent services that interact through separate interfaces.

This architecture works like building blocks: individual components can be easily replaced or enhanced without affecting other parts of the system.

Main advantages of loosely coupled architectures:

Ease of maintenance: errors and changes in one service do not affect the entire system. As a result, the costs of keeping the system running and rolling out new features are much lower; Scalability: you can add new features and services without major changes to other components.

Scaling and adapting the system to new requirements is much easier and cheaper;

Lower risk of becoming dependent on the team: a documented and transparent system structure makes it faster and cheaper to onboard new specialists and reduces the risk that the project becomes hard to hand over. In addition, loosely coupled architectures lower operating costs.

Each update or enhancement takes less effort and time, and the risk of critical errors decreases because the components exist separately from one another.

This helps avoid prolonged system downtime. In a study (.pdf) conducted for

The IEEE International Symposium on Computational Intelligence and Informatics states that companies that switched to a microservices architecture reported a 30-50% increase in the speed of deploying new features.

Support and maintenance costs, in turn, dropped by 20-40%.

Moreover, 70% of organizations reported greater flexibility and the ability to adapt to market changes.

Several steps that will help optimize TCO

  1. Conduct a detailed analysis of the business's long-term needs during the planning stage.

  2. This will help you choose an architecture that scales with your company. At this stage, it may already make sense to consult an IT partner for a pre-project assessment and implementation planning.

  3. This approach will make it possible to plan the implementation and do exactly what is needed.

  4. Among the available options, choose a solution with a loosely coupled architecture.

  5. This way, you will reduce development and support costs.

  6. Develop a plan for preserving and transferring knowledge and documentation to reduce risks when the team changes and make it easier to train new specialists.

  7. Implement a continuous monitoring system for performance and costs to spot issues early and optimize spending.

  8. Review your TCO strategy regularly, taking into account changes in technology and business requirements. Remember that investments in quality architecture and sound early planning can significantly reduce costs throughout the system lifecycle and improve efficiency.

Discuss the article: How much does an IT system really cost and...

Send via:

By clicking the button, you accept the offer and grant consent to the processing of personal data.

Articles on the topic

All articles

Related videos

All videos
31:47 CEO of Expert LLC, the IT company of the Faberlic Group, on 2025 | Valery Kaplenko (Podcast) 4:44 Business Process Management | How BPM Builds an Integrated Company 33:15 IBTA RUSSIA Chairman on Monopoly, Innovation, TRIZ and Gen Z | Alexey Blagikh (Podcast)

News on the topic

All news