How to reduce IT cost of ownership with… app development and operation
Although many of the terms related to application development and operation sound too technical, they still fall into the vocabulary of managers for successful decision-making.
Such terms and concepts include refactoring, automation, CI/CD (Continuous Integration, Continuous Deployment) or legacy systems. However, these areas are not only reflected in the IT budget. They are factors that affect operational risks, continuity or the ability of a company to respond to change.
Which of these and other terms you choose will have an impact on the long-term ability of your company to remain efficient, competitive and, most importantly, in operation. All of these areas are the responsibility of management, so let’s take a look at how to navigate the world of application development and operation from a managerial perspective.
The basic problem – the context of reasoning
In a nutshell, one could say that the context of thinking in connection with the development and operation of applications is short-term and segmented.
Why short-term? – Application development is perceived as a cost item and a project. A certain time and budget are allocated for it. This actually puts managers of the task. But the problem is that the way in which the application is developed has long-term impacts on the efficiency of the company’s operations. In addition, it can become a tool for reducing the costs of long-term ownership and operation or optimizing in the event of the arrival of new technologies or procedures.
Why segmented? – Managers often separate the development of an application and its operation because they are different cost items. But the development and operation of an application are closely related. How you set it up is how it will run. And how it will run has an impact on the functioning of all areas of your company and its adaptability.
Another gap in the context is potential changes. If management accepts development and operation, changes to the application are then often problematic. But the ability to adapt internal tools to the changing technological environment will be an increasingly important ability for companies.
The most common mistakes and myths
And we will continue. In order to focus on the benefits understanding application development and operation brings, we must first clear up a few fundamental misconceptions.
1. The legacy system works, there is no need to refactor it. -> Functionality is not efficiency. You can still ride horses… It is possible that you can effectively run a legacy system on modern technologies in a way other than refactoring. But the idea is still the same – change the way legacy systems operate to a more efficient option.
2. CI/CD automation is a technical luxury. -> Yes, if you live 15 years ago. Currently, it is an approach that allows you to keep pace with necessary changes. And keeping pace equals being able to adapt.
3. Outsourcing is always cheaper than an in-house team. -> In IT, none of these absolute statements apply. In order to use such a sentence, it is necessary to add in what context, under what conditions and taking into account specific needs.
It is necessary to abandon the idea that this is how things have always worked best. Or at least well. The technological ecosystem is changing at such a pace that it is impossible to rely on the best practices of the past. The best practices of the present are slowly becoming insufficient.
Real impacts on the company
So let’s apply the three concepts mentioned above – now free from basic myths – to the corporate environment and its context.
Legacy systems refactoring
If a company runs a legacy system on hardware, it spends a large part of its budget just to keep it running. It neither develops it nor makes it more efficient, it just keeps it alive.
Why is this? Legacy systems were often created in the past, when systems were running on unoptimized hardware. In addition to the costs of the system itself, there were also costs for operating and maintaining the physical infrastructure. It had to be oversized to accommodate future growth. And that without virtualization and the ability to use computing resources efficiently.
But since then, more efficient ways of using physical computing resources have emerged, as well as other concepts – mostly cloud-based – that help optimize the need for physical resources.
So staying in the original operating mode means ignoring the possibilities of optimizing and reducing the costs of physical infrastructure.
CI/CD
Software changes and patches used to be an event where you had to wait and see how it would all turn out. Changes and fixes were accumulated and released into the world every now and then.
These approaches posed a high risk to operability. From preparation, through testing, deployment and troubleshooting, this process was complex and highly risky.
However, when a company switched to a more modern CI/CD approach, huge banquets became canapés. Changes are released more frequently, continuously and with less burden on operations and change implementation. This is then reflected in costs, because it is possible to optimize the entire process of changes in the system.
Outsourcing vs. in-house
This decision is not just about the price tag. Each approach has its advantages, but each also has its application under certain conditions. These are determined by the specific situation of your company. According to the priorities that your company has, you will find out what mix of internal and external work you will require.
If your priority is to maintain zero dependency, then the in-house route is a clear choice. It will probably be more expensive, but it will fully meet your requirements. If you are more interested in zero investment costs, then you are looking at the necessity of outsourcing.
But without setting your priorities and needs, you will not know what this mix should look like in your specific case.
How to change the perspective?
We have already dispelled the myths, looked at individual concepts from a global perspective, so all that remains is to change their definitions to reflect reality.
Refactoring legacy systems is not about changes and a different way of running them. These are steps that lead to optimizing future costs and better equipping the company to respond to changes in the technological market.
CI/CD is not a technical topic. It is an attitude that helps reduce risks and increase the quality of changes in systems.
Where to develop a system is not a question of lower price. It is a strategic decision that helps manage risks and also set digital sovereignty according to company goals.
These are not technical decisions, but strategic ones.
You don’t need to become an IT expert in addition to being a decision-maker. But you do need to view technological concepts as strategic management tools. You need to understand how current IT decisions relate to technology debt and how to successfully minimize it using alternative approaches.
You may not be interested in how it works in detail, but you need to understand what impacts individual approaches or tools have on your uptime and business continuity.
So how do you ask without getting bogged down in technical details?
- How many legacy systems do we run?
- How much does it cost us now and what options do we have to optimize operating costs in the long term (even at the cost of investment)?
- How do we deploy changes to the system and how does this affect the level of risk and cost?
- Why do we use the current ratio of outsourcing to in-house development?
- Is it possible to optimize costs without compromising our priorities and needs?
Tranquility and control instead of improvisation
The basis of everything we have discussed in this article is a timely solution. If you take the time to research the current state and the possibilities provided by modern technologies and approaches, then you will find a solution that will not be an improvisation or a compromise, but a conscious decision of management that knows what it is doing.
