Domain-level Technical Debt - "Domain Debt"

Euromicro/SEAA 2019, Kallithea (Greece): Talk by Marcus Ciolkowski (@M_Ciolkowski, Principal IT Consultant at QAware) & Haralld Störrle (@stoerrle, Principal IT Consultant at QAware)

=== Please download slides if blurred! ===

Abstract:
Background: Technical debt is a metaphor for trading software quality for business goals, reminding actors of the deferred cost associated with such trade-offs. The bulk of the literature on technical debt focuses on source code quality debt. Much less research is devoted to other forms of technical debt, such as documentation debt or architecture debt. In practice, however, we often observe technical debt pertaining to high-level, domain-oriented design issues.

Goal: We aspire to fill this gap in the study of technical debt and establish "domain debt" as a first class citizen in the discourse on technical debt. We aim to explore sources, indicators, and potential remedies for domain debt.

Method: We present real-life examples of domain debt, representing common design flaws of Enterprise Information Systems. These examples are taken from our work in industry and allow us to characterize "domain debt" precisely. We explore the genesis and impact of these design flaws, and analyze the differences to other forms of technical debt.

Results: Once a name is coined, instances of domain debt pop
out surprisingly often.

Conclusions: Domain debt is a useful notion in practice, and it
can be made operational. It is suitable to steer the conversation around business trade-offs towards higher levels of system design quality.

1. Harald Störrle, Marcus Ciolkowski
@stoerrle, @M_Ciolkowski
Domain-level Technical Debt
("Domain Debt")
Kallithea, 2019-08-29
Euromicro/SEAA'19
SEAA 2019
Software Engineering and Technical Debt

2. QAware2
It looked so easy when

3. QAware3
It is based upon experience
not on systematic empirical evidence
Why do we propose to discuss domain debt?
Because most of the TD work focuses on technical issues (implementation-level design and code)
But domain debt really hurts in practice
As a community, we need to broaden our perception of TD
This is a Discussion Paper

4. QAware4
In software-intensive systems, technical debt is a collection of design or implementation constructs that are
expedient in the short term, but set up a technical context that can make future changes more costly or
impossible. Technical debt presents an actual or contingent liability whoseimpact is limited to internal system
qualities, primarily maintainability and evolvability.
Technical debt can effect the value of the system, the costs of future changes, the schedule, and system
quality.
The business objectives of the sponsoring organization developing or maintaining the software system
are affected in several ways: through delays, loss of quality for some features of the system, and difficulties in
maintaining the system operations (continuance).
A TD item is associated with one or more concrete, tangible artifacts of the software development process,
primarily the code, but also to some extent the documentation, known defects, and tests associated with the
system.
Technical Debt(Dagstuhldefinition)

5. QAware5
The metaphor was intended for all artifacts and aspects of software engineering.
The current practice is mostly focused on a very thin slice of software engineering activities and concerns.
Research fails to address the biggest and most pressing issue.
Technical Debt Levels

6. QAware6
"Technical Debt" is a metapher
convey the impact of technical
decisions to stakeholders without
adequate technical background.
TD is taken into account knowing-
ly and temporarily, trading off
technical quality against business
priorities.
Taking on (technical) debt can be
useful (and beneficial) for many
good reasons.
However, it incurs payment of
interest, on top of payment of
principal.
Implementation-level
technical debt

7. QAware7
Domain level technical debt are
debt of decisions in the problem
space rather than decisions in the
solution space.
Technical debt at both levels is
independent from each other in
the sense that one doesn't incur
(or heal) the other.
However, problem space
decisions underly solution space
decisions, revising them, thus, is
hugely more impactful (and
expensive) than revising problem
space decisions (→frontloading).
Domain-level
technical debt

8. QAware8
Working Definition: Everything to do with requiring domain knowledge to detect it
Domain debt is the mis-representation of the
application domain by an actual system.
The technical solution may be perfectly sound, but the system does not correctly represent
processes, use cases
(organization/domain) structure
Domain debt requires domain knowledge to spot it
experts needed, or
→can we use NLP?
What is Domain-Level Technical Debt?

9. QAware9
TD Principal
System needs to be restructured
often: cross-cutting requirements →expensive
involving many stakeholders →expensive, takes a long time
TD Interest
business value reduced
low usability (users pay with time and inefficiency)
development/maintenance
reduced productivity
added overhead (questions, irritations)
risk of incorrect implementations/solutions
What are typical principal and interest of Domain Debt?

10. 10
Project: Repair Research provides repair & maintenance information
for vehicles and combines information from 23 domains
Index (Solr)
27 languages
63 mio. objects/lang
1,2 TB index
used word-wide
ca. 50.000 users
~500.000 vehicles/week
integrates information
from 23 domains
Project start: 2012, 15-20 FTEs
System A
System B
System C
System F
System M
System Z
Loader (ETL)
Index loaded from
> 30 backend systems
integrates ~10 systems at
runtime

11. QAware11
"Last-Service" vs. "Second-to-last-service"
occurs in interfaces the RR is using
confusing, potentially damaging
caused by misunderstanding/ wrong requirements
discovered too late, not fixed
work around by documentation vs. correction
"Repair scope" vs. "Maintenance"
Renaming a business object from "repair scope" to "Maintenance overview" to "Maintenance"
adapted at UI, but not in code/DB (too expensive)
not a technical problem but confusing
obstacle in onboarding (everyone tends to ask the same questions)
adding to the overall project "friction"
Case 1: Misnamings
distanceLastService
yearLastService thesedataaremeaningless

12. QAware12
Vehicles are naturally described by an aggregation tree, called construction tree.
Many business objects are attached to nodes in this tree, e.g. the engine, brakes, seats, and so on.
Nodes in the construction tree are identified by a four-digit code and a human readable label, that is very
important to the domain experts.
For instance, "1100" refers to the engine, and "3400" to the brakes.
Engine parts have codes starting with 11, brake parts have codes starting with 34.
However, there are several independent and differing construction trees for any one vehicle.
So, the same number may have a different meaning in different trees. And even if it has the same
meaning, it might have a different label, or no label.
The differences lead to substantial communication problems, resulting in the desire to unify all competing
construction trees.
The goal was to have aligned codes, and identical labels all over the company.
2013 management had to admit defeat, realizing that changing all legacy systems was too expensive, and
politically to risky.
It took 5 years to prioritize and implement a solution.
Case 2: Construction grouplabels
(aka inconsistentnamingswithinoracrossdomains)

13. QAware13
Case 2: Inconsistentnamings
domain-specificlabelsnormative labels
Domain (a) Domain (b) Domain (b) Domain (c)

14. QAware14
Principal: Correct inconsistent labels
we found out in 2013 that the cost for correcting labels across domains were too high
the solution taken was: Use domain-specific labels and accept inconsistency
→this is what users know from existing systems
medium-sized effort
Interest included
Users were frustrated, did not find information and did not use RR or were inefficient
→business value reduced
→usability reduced, overhead cost for users
High amount of complaints from users and representatives
→
(no problem with productivity or with technical quality)
Case 2: Principal and Interest

15. QAware15
Root causes

16. QAware16
Implementation-level technical debt is always visible and concrete.
It is present in concrete artifacts like source code, test code, or configuration files.
These files have a formal semantics, so they are amenable to automated analysis.
Domain-level debt, on the other hand, is a property involving the concrete artifacts of the
system as well as its requirements and/or design.
These are often not even expressed as artifacts, or hopelsslyoutdated.
Identifying and naming domain-level technical debt requires comprehensive knowledge of
the system, and its history, which often can only be obtained through system archaeology.
Documentation is often available →can NLP and AI help?
Interest is often paid by user or other stakeholders
In principle, systems with a complete design history are amenable to automated domain debt
analysis (e.g., in highly regulated domains such as aerospace or safety critical applications).
Insights

17. QAware17
Domain debt items can be handled like any other technical debt item.
Paying back domain debt is much more expensive and difficult, though.
It is expensive, because many more artifacts could be affected: Design issues may be crosscutting.
They are also more difficult as they affect multiple stakeholders, and often neighboring systems.
Thus, many people and organizational units may be involved.
Quite possibly, they would have to spend effort to.
"Agile" projects are especially prone to piling up domain debt.
Front-loading, modeling, and documentation are frowned upon by naive Agilists.
When there is "emergent design", domain debt can become overwhelming, leading to technical default
("bancruptcy").
Handling domain debt

18. QAware18
The notion Technical Debt is well established, but usually interpreted in very restricted sense.
There is very little literature on non-implementation level technical debt.
Implementation and domain debt are similar in terms of origin, effect, and tracking, and they are independent
of each other.
But domain-level technical debt is more basic, making it vastly more impactful and expensive to support or fix.
Apart from being "larger" (often: crosscutting), domain debt often affects multiple stakeholders and
neighboring systems, making it incomparably more difficult to reduce.
We suggest to consider this type of technical debt and prioritize research efforts in this area.
It is crucial to acknowledge, first of all, the existence of domain-level technical debt.
Summary

19. QAware19
Domain-level technicaldebt
ismuchmorerelevant than
implementation-level TD.
Yes, itisalso muchmore
difficulttocapture& research.
But stickingtoimplement-
ation-level TD amountsto
searchingunderthelamppost.

20. QAware20