hamburger-customhamburger-custom-close
custom-cover-arrow

The Moral Hazard Problem

The failure to consider sustainable software development and the dangerous consequences for companies:
The Moral Hazard Problem

In my articles on the process-driven approach, I always emphasize the importance of sustainable process digitization, including my article on the motivation for the process-driven approach (germany only). But what exactly is meant by sustainability in process digitization or in software development in general, and why does it play such an important role? I would like to address these questions in the following article.

The topic of sustainability in software development has accompanied me throughout my entire professional life. Unfortunately, I myself have all too often had to maintain poorly developed software, have been annoyed by programs that no one could see through anymore and where every change degenerated into pure gamble. Not to mention the time and associated costs a company ultimately faces in order to get through and ultimately eliminate the mess. In this regard, I am branded from former experience. As a result, I very much appreciate the value of quality software development, and companies would do well not to underestimate its importance. On my homepage www.volkerstiehl.de I have already briefly outlined my own idea of sustainable software development. This idea can be aptly summarized by the three terms efficiency, transparency and flexibility. It is important to me that software is:

  • Time-efficient to develop

  • easy to extend and adapt

  • easy to maintain

  • easy to operate

  • easy to adapt to changing market conditions

  • easy to adapt to changing IT systems used by the solutions

  • transparent (in the sense that you can see what is happening)

These requirements are met, for example, by software systems that are developed according to the process-driven approach, which also prompted me to develop the process-driven approach at that time (details on my motivation for the process-driven approach can be found here, german only).

However, observing current trends in software development and the general usage of software in companies, you get the impression that all good intentions are thrown overboard. So, it's worth taking a closer look and examining the impact of certain developments in terms of sustainability. I will also explore the reason for increasingly poor software development quality and why nothing is done to prevent it, despite better knowledge. To illustrate my arguments, I will refer to the currently popular technology of “Robotic Process Automation” (RPA). But first, I would like to discuss the moral hazard problem, before I analyze RPA in terms of its sustainability. So let's get started.

Moral Hazard (Moral Risk, Behavioral Risk)
The starting point and motivation for this article is a video from Prof. Christian Rieck (german only) and his explanation of the relationship between sustainability and game theory. I would like to summarize the essential statements of this video in the following.

In the mentioned video, Prof. Rieck investigates why people tend to act in a non-sustainable way. The reason for this lies in the problem of moral hazard, which I would now like to illustrate using his example of a forester, responsible for the management of woodland.

The term "sustainability" originated in forestry. Here, sustainability means not to fell more trees than new ones follow within a year. The problem here is that the forester does not know how many trees he is actually allowed to cut per year, since there is a long period of time between the planting of the trees and their subsequent felling (and thus the harvesting of the yield). The connection between cause and effect, that is, between what has grown,what you have done for it, and you’ll receive, is no longer obvious due to the large time gap. Prof. Rieck states that this large time gap leads to problems, because unsustainable behavioral incentives are set.

Why is that? Just imagine how the forester earns his money. Ultimately, he does so by selling the timber. He can decide anew each year whether to cut down a lot or a little. If he cuts a lot of wood, he earns a lot of money; if he cuts little wood, he earns less. To make matters worse, no one knows how much wood has grown back in a year. According to the aforementioned rule however, it is precisely this knowledge that is necessary  to be able to make a sustainable decision. This lack of knowledge naturally opens the door for our forester to simply estimate the amount of wood that has regrown a little higher in order to be able to justify cutting a larger amount of wood. The nasty thing about this is that an outsider can judge the forester's actions even less than the forester himself. Indeed, the forester himself does not even know where the boundary between sustainable and unsustainable lies. The boundary is therefore blurred.

According to Prof. Rieck, it is precisely this initial situation that is meant by moral hazard (moral risk, behavioral risk) in game theory. A protagonist is in a moral dilemma in the case of moral hazard. Referring to the example of our forester, he can now cut down as much as he wants, and nobody will notice that he has acted wrongly. Even if he cuts down less and earns less money, no one can judge his actions in terms of right or wrong.

How will the forester act in this situation? Since nobody can judge anyway whether he acts correctly or wrongly, he will probably cut down a little more and get more money in this way. He will now repeat this behavior year after year without feeling any consequences. As a result, he is regularly overcutting his forest with the consequence that the forest thins out over a relatively long period of time. Obviously, he is not acting in a sustainable manner, increasing the problem of forest depletion.

The nasty thing is that the result will only be visible after a very long time(long time between cause and effect) and the responsible forester will probably be retired or no longer alive by then. Even worse, the forester who caused this bad condition was in a good position all along, probably overly praised for his outstanding management of the forest. On the other hand, the successoris faced with a pile of rubble and it is attributed to him that the forest is now in this thinned out condition.

What can we learn from this example? With long-term developments there exists a very strong tendency to work unsustainably!

As Prof. Rieck puts it so nicely in his worth seeing video: "You can do something that cannot be judged by others and then of course you do what is good for you and not what is good for others! So you do not act sustainably.”

This is the summary of the essential statements of Prof. Rieck's video, which is well worth watching.

Moral Hazard and Robotic Process Automation
This scenario can now be aptly applied to current trends in software development. To illustrate this, I will first use the example of RPA. Everyone is currently talking about RPA. For example, in the latest issue of the journal "Applications and Concepts in Information Systems" (AKWI for short, issue no. 13 dated July 23, 2021german only), the "increased relevance"  of RPA is reflected in three articles. Companies with RPA solutions spring up like mushrooms and almost every business podcast recommends shares in RPA providers for asset accumulation. Such shares are even recommended for a so-called confirmation portfolio, which should actually be geared to long term measures (see Deffner & Zschäpitz podcast, episode 171, minute 24:22). This makes me wonder whether the technology has really been understood respectively how such questionable recommendations emerge in the first place, since shares of RPA providers are certainly not a long-term investment. The justification for the investment in the podcast is correspondingly vague and based more on a poorly understood set of buzzwords and the principle of hope.

It therefore seems necessary to take a brief look at the technology. After all, the term "Robotic Process Automation" basically refers to software used for filling in user screens. Inputs that would otherwise be made by humans are now taken over by software. That is basically the whole secret: not particularly earth-shattering and already known for decades in the software industry. Now, in the course of process automation, it is of course a compelling argument for introducing this software into companies on a large scale.

The argumentation of the supporters is always the same: the software robot takes over boring, repetitive, sometimes mindless work. It releases the human being who, freed from boring tasks, now has more room for the real work. Just take a look at the commercial by the company UiPath explaining RPA on YouTube and you'll understand what I mean. Software robots work around the clock, seven days a week, with higher reliability, a much lower error rate, they never get sick and don't need a coffee break. A use case is quickly calculated. You just select a company process which is operated as often as possible per day and that contains steps of human interaction. Now you use the software robot instead of the human and calculate how much the robot achieves in comparison to the human. By multiplying this by the large number of process instances per day and the above-mentioned characteristics of round-the-clock availability, the use of RPA can be calculated very quickly. If the supporters of RPA deployment now also drop buzzwords like "artificial intelligence" (which some RPA solutions use to train the robot), "automation", "robots", and "process digitization", the budget for acquiring the RPA software and training the employees is very likely to be approved by the management. Finally, you're on board with the important topics of digitization, automation, and even artificial intelligence – just by using a single solution. Superb!

Consequently, the RPA software is procured, deployed, the company possibly saves the targeted costs, the quality of data supply increases, the error rate decreases, process cycle times are reduced and everyone is happy. The project manager is promoted to a higher position due to his valuable contribution to the company and his project success.

So far, so good. But where is the flaw? It has something to do with sustainability and moral hazard. Because every time companies use RPA, they incur huge technical debts that only reveal themselves after a relatively long time. But then, they appear all the more disastrously!

According to Wikipedia, technical debt is "a metaphor commonly used in computer science for the potential consequences of poor technical implementation of software. Technical debt is the additional effort required to make changes and enhancements to poorly written software compared to well-written software."

Why does a company incur technical debt by using RPA in the first place? And why should it therefore be used with extreme caution? Because RPA is built on the weakest and most fragile interface of a system: The user interfaces (UIs)! UIs,  through which the system is supplied with data, change most often and fundamentally. If they change, then unfortunately the entire sets of rules and scripts that ultimately control the software robot no longer work. This is because the rules and scripts are designed for the old screen templates and can no longer do their job correctly with a new version of the underlying system, which is fed via screen templates. For example, new fields are not filled in, or the robot tries to fill in fields that no longer exist on the screen. The fields may have been moved to another form or have been replaced by other fields. Such a redesign of user interfaces is not the exception, but the rule. They take place constantly, even if it is "only" for reasons of better usability. The more systems are operated via software robots, the higher the risk for the company of processes breaking down. But the person responsible for this disaster will probably no longer have to take the blame, since he or she has long since been promoted or has already moved on to another company.

You can probably see the parallels to the moral hazard example above with our forester. The project manager responsible for the RPA implementation is our forester. Since no one understands the long-term consequences of the RPA deployment, he or she can install one robot after the other without hesitation. The short-term success proves the project manager right because the increasing technical debts are not visible at first. Only after a comparatively long time, the full extent of the problem becomes apparent. According to our definition of sustainability given above, the person responsible for the project did not act in a sustainable manner. Long-term corporate success serving the general public was sacrificed for short-term personal success. In the end, it is the successor who has to pay for the disaster since he or she  is in a bad position completely unjustifiably, not being responsible for the emerging malfunctions.

Therefore, when using RPA, if it is indeed unavoidable, every project manager should definitely develop a plan to exit the RPA solution in a timely manner, wondering: By when will the planned RPA solution be replaced by a sustainable interface? It is essential to answer this question before the project starts and to monitor its implementation later on. The person responsible for the project must also be responsible for the adherence to this plan. In this way, a responsible approach to RPA technology is encouraged and (hopefully) avoids a major conflagration in the company later on.

One last note to conclude this paragraph on RPA: The marketing departments have really done a great job with the term "Robotic Process Automation". Chapeau! The clever combination of three buzzwords virtually electrifies readers: Robots automate my processes – how great is that! Taking a closer look,  it is individual process steps that are automated, not complete end-to-end processes. And the supposed robot is a piece of software that controls screens. So, in a way, this is labeling fraud since expectations are being raised that the solution cannot deliver.

After reading this section, you may understand why I recommend that you consider RPA deployment carefully and approach the technology with due skepticism. What is important to me is that you make a conscious decision.

Moral hazard and other examples from the IT industry
But is RPA the only example of moral hazard? Unfortunately, no. The IT industry in particular is extremely prone to this kind of downright panic. The FOMO effect, i.e. the fear of missing out on a decisive development, is high.

Microservices
For example, microservices and their linkage to processes via events (so-called event-driven microservices) are currently the subject of heated discussion. Here, too, I consider their usage to be unsustainable, even fatal, because the transparency of links and dependencies between services is completely lost over a longer period of time. Effects of changes to event links are no longer predictable and adapting software to new market conditions becomes a gamble. At the end of the day, such software ends up in an unmaintainable process monolith, although the original idea of microservices was once to precisely avoid these monoliths.

Ironically, event-driven microservices end up in a process monolith that is much harder to maintain and manage than programmed process monoliths. Why? With the programmed process monolith, I can still see the individual steps of a process represented by interactions between the services in the program code. However, with so-called “publish-subscribe relationships” between event-driven microservices, the dependency network becomes so confusing over time that changes become nearly impossible. Again, the problem only becomes apparent after a longer period of time – moral hazard at its best.

The microservices approach also falls short of my own definition of sustainability according to the requirements of efficiency, transparency, and flexibility. Nevertheless, the approach is being used in companies.

Programmed processes
You will surely wonder now whether programmed processes are the better solution? Well, at least better than microservices linked via events. In terms of "transparency", programmed processes score a little better than event-driven microservices due to the process steps visible in the code. Otherwise, things look similarly bleak in terms of efficiency and flexibility. In my opinion, this is not a sustainable basis for the future.

Purchase of standard software
Let's look at another option that is reflexively chosen in my experience by companies: Buying off-the-shelf software. It is certainly the most time-efficient and probably the most cost-effective way to solve process problems quickly. But is it sustainable in the long run? I have strong doubts, as this solution option also fails on the points of transparency and flexibility. Purchased solutions are black boxes and deny the buyer an insight into the inner workings of the processes, their states and thus the possibility to intervene in what is happening. Transparency and flexibility are therefore practically non-existent and the purchase of standard software is no longer a sustainable option.

Don't misunderstand me: Programming new processes and buying ready-made solutions to cover standard processes has been the right approach for many decades. But this is no longer valid in the age of digital transformation (see also my article on digitalization vs. digital transformation). A fundamental rethink must take place here in all companies!

No-code/low-code platforms
The contemporary hot topic of no-code or low-code platforms also belongs to the category of unsustainable offerings for me. However, the shoutouts of platform manufacturers are also too tempting for companies, as they promise foolproof development of apps without programming knowledge – a long-cherished dream finally seems to come true. The manufacturers come thick and fast with their promises. There is Microsoft Power Apps, which supposedly anyone can develop. ServiceNow with its Now Platform or SAP with its purchase of AppGyver stress the importance of this current trend. In addition to the simple development of UIs, the creation of workflows is also becoming increasingly important.

But is the use of such platforms really sustainable? I am firmly convinced: NO! The disadvantages outweight the advantages of the rapid provision of new solutions. Obviously, the disadvantage of vendor lock-in is worth mentioning here. The manufacturers are currently trying their best benefit from this emerging market and to convince the customers. After all, the "winner takes it all" principle beckons in the platform market. In addition to the dependency that companies obviously find themselves in (they are at the mercy of the manufacturer and a later change is associated with enormous costs), they should not underestimate the risk of making a mistake when selecting their manufacturer. What if the wrong horse was bet on and the platform manufacturer of choice ultimately doesn't catch on and gives up? Which manufacturer survives and which doesn’t? It would take a crystal ball to be able to predict this. And who can do that?

Besides, in real life you will always reach the limits of a platform. How easy is it then to close these gaps? The question of expandability inevitably arises. The manufacturer, for its part, will try to meet the wishes of the customers and continuously adapt their platform to these wishes, with the result of an ever more extensive juggernaut that is increasingly difficult to manage. What started small and lightweight ends in a heavyweight fiasco. We have seen this development countless times in the history of computer science. Apparently, however, the appropriate lessons are not learned from this...

Even if the selection came down to the future winner and the limits of the platform are rarely reached, who can guarantee that this manufacturer will provide compatible updates to the platform in the future? Again, experience shows that as soon as new technologies appear on the horizon (and they will), a manufacturer will take advantage of them, even if it means breaking compatibility with the existing platform. Customers are then forced into costly migration projects due to vendor dependency. Not a pleasant thought!

As briefly indicated in the beginning, some of these new platforms also include workflow functionality. Here, the use of proprietary modeling environments is  criticizable/questionable. Support of recognized standards such as BPMN? Missing. Everyone has their own agenda here.  Interchangeability of process models is ruled out from the beginning. Good for those who can avoid these dependencies.

Even if one is aware of the arguments already listed and decides to live with these risks, there is still the all-important question whether companies can afford it when new apps and workflows emerge on every corner? Companies have to ask themselves: Do I really want this? After all, apps and workflows can hardly provide reasonable functionality without access to the existing system landscape (e.g., for master and transaction data). For IT departments, however, this inevitably means more administrative expense: Which apps/workflows access which systems and when? There will be an uncontrollable proliferation. Pandora's box is opened here! And just like in Goethe's sorcerer's apprentice, companies will sooner or later have to realize that they are no longer in control. A nightmare!

You already suspect how this could end? The detailed answer follows in the next section on the consequences of unsustainable software development. My conclusion for the use of no-code or low-code platforms can therefore only be: Hands off!

Process Mining
Last but not least, the question inevitably arises as to how companies try to counter the transparency problem. This is particularly important due to the use of all the "solution options" discussed in this article. The answer is: through even more software, specifically in the form of process mining. However, the use of process mining is accompanied by other problems, as I have explained in detail in my critical article on its use (german only). A vicious circle! But you can escape it, as you will see in a moment.

Consequences of non-sustainable software development or the non-sustainable use of software or: How to ruin a company using IT

As you can see, the topic of sustainable software development or the sustainable use of software is very close to my heart. But it is also too important for companies to neglect or even ignore, because the long-term effects that I address in this section are so serious.

In my webinar of 08.09.2021 on sustainable process development with the process-driven approach, to be looked up at this link, I showed the following figure (Figure 1):

Figure 1 Current state of capacities in IT departments and desired target state.

Figure_1

The figure originally came from my former SAP colleagues, who used it to express the urgent need for change in their business unit. They were running at the limit of their capacity, mainly driven by recurring routine and administrative activities. There was less and less time for work on urgently needed business innovations. Their desire for more freedom to innovate in their core business symbolizes the desired capacity distribution in the right-hand column of the figure. In fact, the target state was ultimately achieved by the largest project to date based on the process-driven approach. 

The basic statement of this figure can now be easily transferred to the current situation of IT departments in companies, which I was able to gain from many discussions with companies. On the left-hand side, it shows the current state of the burdens on IT departments in companies. The total capacity of IT departments can be seen in the vertical. This means the total time available for work of all IT employees.

This capacity can now typically be used for two types of activities. First, it can be used for base load tasks. These are recurring administrative and routine tasks that literally keep the "store" running (recognizable by the dark rectangle labeled "Keeping the lights on"). These tasks include, to name just a few:

  • Set up new users
  • Assignment of rights for the various systems
  • Installation of security patches
  • Updating software
  • Monitoring the correct operation of the systems
  • Correct termination of various batch processing runs
  • Very popular: time-consuming release changes of purchased standard software
  • Consolidation of systems to reduce the IT landscape
  • Integration of systems for new purchases or after merging companies
  • Outsourcing of functionalities to the cloud
  • Error analyses of all kinds

Of course, the list makes no claim to completeness.

On the other hand, capacity can also be used for business innovation (shown in Figure 1 by the blue box labeled "Business Innovation"). The heights of the respective rectangles are used to express the distribution of capacities for the actual and the target state.

The core message of the figure can therefore be briefly summarized as follows: Currently, IT departments are burdened with far too many tasks that merely serve to maintain operations (basic load). There is comparatively little, if any, room for business innovation (current situation, left column). In view of the digital transformation, however, the exact opposite would be necessary (target situation, right-hand column): less time consumption for the base load and more free space for business innovations. After all, the digital transformation is driven by IT-based process innovations! But how is this innovative power supposed to work for companies if there is no capacity left at all on the part of IT?

To put it in a nutshell: In the age of digital transformation, it is one of the most fatal decisions of all to further restrict IT capacities by using dubious solutions and thus depriving the company of its innovative power!

However, not many companies seem to understand this basically simple. How else can one explain the disproportionate amount of investment in software, technologies and implementation approaches that grow the base load column and take even more air out of IT? All of the technologies, approaches and solutions discussed above contribute to the fact that IT inevitably only has to deal with itself even more. It is precisely this development that I find disastrous and highly worrying!

Do companies recognize this development? In my observation, those responsible do not see (or do not want to see) these dormant dangers, especially since the increasing technical debt extends over a long period of time, as is typical with the moral hazard problem. Each individual decision taken on its own may be logically understandable and supposedly justified. In total, however, such high technical debts can only end in an IT fiasco for the companies sooner or later! To put it bluntly, companies are virtually maneuvering themselves into digital extinction by using the above approaches.

The combined use of RPA, event-driven microservices, the constant purchase of standard software, programmed processes, the use of no-code/low-code platforms, etc., even has the potential for companies to produce a "perfect storm" in IT and ruin a company.

However, far be it from me to just want to complain. We need constructive criticism. That is why I would like to oppose this ruinous trend with the process-driven approach. Only the process-driven approach provides the basis on which technical debts can be really reduced and which gives IT departments back the freedom for business innovations!

Knowledge about the process-driven approach is therefore more valuable than ever for companies. So help spread the knowledge about the Process-driven approach!

Conclusion
This article is an appeal to companies to finally let sustainable software development as well as the sustainable use of software become a core topic, because this is so incredibly important in the age of digital transformation. The future of too many companies depends on it. Digital transformation needs the freedom for IT-based process innovation as much as  air to breathe. Any investments in software, technologies, and implementation approaches that are not sustainable work against this desire for freedom and consequently need to be critically scrutinized. Unfortunately, the insidious problem of moral hazard contributes to a creeping increase in enterprise technical debt. Executives need to be made aware of the devastating effects of the moral hazard problem, and this article aims to contribute to that effort.

My recommendation: Every IT investment decision must be examined with regard to its impact on the technical debt level of a company. If necessary, measures should be taken and monitored to reduce the level of debt again.

The process-driven approach starts exactly at the point of reducing technical debt and is therefore unique. Only the process-driven approach currently enables companies to finally free from ever-increasing base load shares of IT departments. Therefore, help spread the knowledge about the approach so that as many companies as possible can benefit from it! Be part of the PiDiArtify® initiative, which aims to make its contribution to sustainable software development. You can find more information about the initiative here (german only).