Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Domain-level Technical Debt - "Domain Debt"


Published on

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! ===

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.

Published in: Data & Analytics
  • Be the first to comment

Domain-level Technical Debt - "Domain Debt"

  1. 1. Harald Störrle, Marcus Ciolkowski @stoerrle, @M_Ciolkowski Domain-levelTechnical Debt ("Domain Debt") Kallithea, 2019-08-29 Euromicro/SEAA'19 SEAA 2019 Software Engineering and Technical Debt
  2. 2. QAware 2 It looked so easy when
  3. 3. QAware 3 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. 4. QAware 4 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 whose impact 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 (Dagstuhl definition)
  5. 5. QAware 5 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. 6. QAware 6 "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. 7. QAware 7 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. 8. QAware 8 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. 9. QAware 9 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. 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,2TB 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. 11. QAware 11 "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 these data are meaningless
  12. 12. QAware 12 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 group labels (aka inconsistent namings within or across domains)
  13. 13. QAware 13 Case 2: Inconsistent namings domain-specific labelsnormative labels Domain (a) Domain (b) Domain (b) Domain (c)
  14. 14. QAware 14 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. 15. QAware 15 Root causes
  16. 16. QAware 16 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 hopelssly outdated. 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. 17. QAware 17 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. 18. QAware 18 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. 19. QAware 19 Domain-level technical debt is much more relevant than implementation-levelTD. Yes, it is also much more difficult to capture & research. But sticking to implement- ation-levelTD amounts to searching under the lamppost.
  20. 20. QAware 20