What is the technical value and what not?
The value of a business is difficult to estimate in a bottom-up fashion. That is why one prefers to use the market value, the valuation based on what someone is ready to invest or to buy the business for. A due diligence analysis is usually set or justify a market value. As this value is yet to be found, it is not available in this context. There are, however, models to estimate the value of a business based on performance indicators, such as profitability, market shares, market ranking, repeated orders, the rate of customer acquisition, average length of employments, and a long list of financial variables. Among those there can be physical, tangible goods, such as vehicles, real estate, computers, office furniture, and other fixtures, or intangible items, such as intellectual property and the technical value. For IT companies, the developed software is often the central intangible asset. We refer to the value of this software as the technical value and define it as the re-implementation effort, i.e., how many Person Months (PM) would be required to reimplement the code of the system. It is part of, but not equivalent to the overall value of an IT business.
Why is the technical value important for investors?
The visible system functionality that creates business value can be implemented in different ways. Consider, e.g., two hypothetical companies offering customer relationship management (CRM) solutions; we call them EnforceSales and SalesEnforce. Assume further EnforceSales interfaces to SalesEnforce and offers novel charts and views based on functionality and accumulated data of SalesEnforce. When looking at both companies from an end user perspective both companies offer the same functionality. However, EnforceSales has only implemented a thin shall of frontend code around the bulk of back- and frontend code of SalesEnforce. Consequently, SalesEnforce has a system with a technical value of 1000 PMs, i.e., one developer would reimplement the system in one thousand months, and EnforceSales has a system worth 100 PM. The technical value of EnforceSales is only a fraction (10%) of that of SalesEnforce, to let away license and dependency management issues.
High technical value provides good protection against competition, often the only protection, as software patents and other classical means of IP protection are hard to establish and to maintain. For example, the effort to reimplement the views of EnforceSales, if they are attractive and add value to those of SalesEnforce, would only require a fraction of the effort to reimplement the backend code of SalesEnforce. EnforceSales is therefore less protected against competitors than SalesEnforce.
How can we estimate the technical value?
There exists a number of software cost estimation models that are used in forward engineering to estimate the expected development effort. Models include COCOMO, SEER-SEM and SLIM. They are two-stage models: first a size is estimated based on the functionality and complexity of the envisaged system, the second a productivity adjustment factor maps the expected size to the expected implementation effort. While the models have their basis in estimation research conducted before 2000, they can be and have been updated with new calibration data from modern software development. Also, the first stage of size estimation can be replaced with accurate size measurement reducing the estimation error.
However, one should account for sources of errors in this way of estimating technical value. The most important error arises from the level of abstraction provided with modern software environments (frameworks, platforms, libraries, and programming languages). Functionality that used to be part of a bespoke software solution is nowadays available (often for free) in these software environments. Hence, not any code line in a legacy system needs to be reimplemented for rebuilding this system based on modern software environments. Without any correction, technical value assessment based on software cost estimation models tends to overestimate the value, and this error is increasing with the age of the assessed software.
Why is it important to not forget the technical value when looking at the technical debts?
In the technical due diligence of IT companies, one often focusses on technical debts, next to organizational, competence, and legal aspects. Technical debts reflect the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer (https://en.wikipedia.org/wiki/Technical_debt). We can understand technical debts as a loan that needs to paid back in terms of additional effort and costs for development in the future. Assume we assess the technical debts of an IT company to one year, i.e., one year estimated development time to fix all the shortcuts and to turn their central IT solution into a profound, sustainable system. Is it ok or too risky to invest in that company?
As with monetary depts and loans, the risk can only be assessed relative to the value of the corresponding asset. The loan-to-value ratio is therefore an indicator in risk assessment. The same holds for technical value and technical debts in software development. For example, look at the two companies SalesEnforce and EnforceSales again, each with this technical debt of one year. The loan-to-value ratio for SalesEnforce is almost neglectable 12‰ and much higher for EnforceSales, namely 12%. In a technical due diligence of SalesEnforce, we would point at the technical debts and recommend paying them back as part of regular software development. For EnforceSales, we would maybe raise a “red flag” instead as a substantial amount of the development needs to be redone. Indirectly, we would also assume competence and/or organizational issues leading to this accumulation of debts.
Summary
Technical value is the reimplementation effort of a software system and often constitutes the central intangible asset of an IT company. High technical value protects against competitors. On a balance sheet, it is on the opposite side of technical debts, which is often much more in the focus IT due diligence. Technical value can be estimated based on adjusted software cost estimation models.