The Value of Understanding Your Technology Assets

By Mikhail Kurkov, Head of the European Markets Division, Exactpro

"Never invest in a business you cannot understand," – the famous quote attributed to Warren Buffett also holds true for fintech innovation and may suggest that lack of knowledge about your technology assets can put your digital transformation budgets at substantial risk.

The healthy way to own an asset is to know what is inside and what governs it. If this is the case, you will be able to put this asset to work and get returns on your investment. 

Imagine you decide to renovate your own home. This may play out as a nice demonstration of your craft skills and, at the same time, help you save on costs. However, if you choose to pour your creativity onto the walls without knowing where exactly the electrical wiring runs, the outcome of hammering a nail into the wire is likely to spoil both perceived benefits.

Similarly, the feasibility of investing in a technology transformation project depends on the depth of your understanding of the platform in question.

The financial benefits of knowing what you own

Consider two examples.

The first example is around large-scale technology migration within a market infrastructure being handed over to a new parent entity. The current technology is thoroughly tested, its functionality is exhaustively modelled through an end-to-end regression test library equipped with automated execution capabilities. What is more, the team has extensive knowledge of the technology platform, as well as an understanding of its correct and incorrect behavior. The migration is planned with this knowledge in mind.

The second example features a financial institution who started their technology replacement efforts by engaging a third party to create a requirements specification for a new system based on the organization’s business need and then asking them to develop one. The resulting system, though impeccable from the functional specification point of view, however, turns out to be unable to function through multiple interfaces connecting it to the surrounding infrastructure components. In this case, the organization has only a few people familiar with the original system from performing superficial manual tests against it.

Given the two situations, it will not come as a surprise that the first project proved to be a much better investment than the second one, which achieved the only transformational goal of turning an impressive budget into a waste of time and human effort.

Let us try to understand what is involved in “knowing what you own”.

Understanding: the process of knowledge acquisition

What is knowledge from an epistemological point of view? Knowledge is different from just an opinion in that it requires evidence to support it. In other words, the process of understanding deals with building a model of reality and subsequent assessment of this model against the reality itself.

Any technology platform is a fragment of the world designed to perform specific meaningful functions. To understand how it works means to build its model and challenge it.
From the knowledge acquisition perspective, this approach is implemented through rigorous testing as opposed to a box-checking exercise, which in the financial technology world is a very common activity accompanying regulatory reporting tasks. The main difference between the two lies in the mindset: to get a good understanding of the system under test we need to challenge our assumptions about it rather than try to prove that they simply comply with the requirements and stakeholders’ expectations.

Models: reflecting the reality

An important point about understanding is that it is a process rather than a static snapshot of current reality.

To make this process effective, mere mind power is not enough – it is important to support knowledge acquisition with tools. The deeper  the needed degree of confidence in the system under test is, the more complexity would be required from the tool that we use to assess it.

A tool that is fit to the task is essentially a model of the system under test, which rivals it in terms of complexity and degrees of freedom. Such a tool is capable of modelling all of its possible interactions, both internal and external, and capturing the data flow. Analysis of this data can be leveraged for the model improvement.

Test oracles vs. human judgement

As any technology project evolves, the accompanying testing activities result in building a comprehensive model of the system under test in the form of a large regression testing library. This is a valuable artifact per se, as it significantly improves our knowledge acquisition capabilities.

However, if not subjected to constant improvement, such a model will inevitably decline, losing the ability to serve its main purpose – to drive the evolution of what we know about our technology platform.

According to common understanding, the ability to tell right from wrong, correct from incorrect is considered to be the essence of the test oracle concept. However, when this reasoning capability is cast in stone (i.e., built into a finalized test library) it means that we are delegating our judgement functions to the machine.

An alternative view on the test oracle suggests that its purpose is to serve as an alert mechanism prompting humans to intervene rather than taking over their decision-making responsibility. This perspective is in line with the principle of constant model evolution: to ensure it, we need the people component to be a part of the equation. Moreover, knowledge by its essence is a social concept, so the understanding of the system under test cannot evolve without humans: people act as a collective distributed database used to shape judgements about reality.


To be justified in terms of time/money investment, any transformational initiative needs to be assessed in terms of understanding of one’s own technology assets. The knowledge about them rests on three pillars – processes, platforms and people, with all three being part of any rigorous software testing approach.
Invest in software testing. Build a more resilient future.