The Stakeholder Perspective – The Ecosystem

This is the second article in a series about a recent paper our team submitted to the SEI arguing that technical debt should be defined from what we called “The Stakeholder Perspective.”  As we discussed in the introduction, there are many different perspectives from which quality can be evaluated.  Ward Cunningham proposed the most commonly referenced definition of technical debt which takes a very developer-oriented view on intrinsic factors influencing quality.  While this perspective is indeed valid, it tells only part of the story.  The story on quality has major interdependencies and managing any piece of it in isolation creates challenges.  Technology environments behave similar to biological ecosystems with each layer having dependencies on the others.  A big enough gap in any one area can cause the entire system to crumble.  Therefore, we believe that managing gaps in quality (i.e. technical debt) should be centralized and undertaken as a collaborative effort between key stakeholders.

Leveling the Playing Field

The price an organization pays for deferring the implementation of a feature often has the same principal and interest structure as a code base in need of refactoring. The same considerations must be evaluated when deciding how to prioritize these two gaps. Therefore, Cunningham’s definition only tells part of the story that stakeholders need to consider.

Since business people are a key audience for communications about issues related to technical debt, the current definition needs to be expanded upon. Business partners do not generally differentiate between the costs associated with missing features and those associated with code needing to be refactored. The following four components describe the impact of technical debt and provide the basis for comparison [4].

Principal – given a particular type of technical debt, the estimated cost of eliminating that debt

Interest probability – the probability that a particular type of technical debt will in fact have visible consequences

Interest amount – the added cost of performing maintenance on the part of the system that contains technical debt

Expected interest – the interest probability multiplied by the interest amount which gives a risk adjusted interest cost

Technical debt redefined

We propose the following revised definition of technical debt in pursuit of better alignment with the stakeholder perspective:

“Technical debt is any gap in the technology infrastructure which has a measurable impact on quality and an organization’s ability to achieve strategic objectives.”

This definition establishes a quality-based criterion and will provide a more level playing field for prioritizing gaps in the technology environment. For example, the implications of deferring new features could be compared side-by-side to the benefits of a refactoring initiative using the principal and expected interest of each course of action.  The interest amount also needs to be expanded to include the financial impact of risks to which the debt exposes the organization.

Evaluating alternate strategies

Defining the metaphor broadly also levels the playing field for alternative strategies during greenfield development. When any of the Triple Constraints are altered, project teams must collaborate with business partners to evaluate alternatives. A common approach is to step through and evaluate the following three options for each system requirement:

1. Do it right – no debt

2. Do it quick – take shortcuts and assume debt

3. Do it later – defer functionality and assume debt

It becomes difficult to identify the best strategy without expressing the cost of each option in similar terms. Objective analysis requires an estimate of the immediate and ongoing cost of all options. However, Option 3 falls outside of the current scope of technical debt even though the metaphor still makes sense. When features are postponed, the desired solution is essentially being “borrowed” upon similar to when design shortcuts are taken. The main difference between doing it quick and doing it later is which part of the organization borrows and pays interest. If the development team borrows by taking shortcuts, they pay the bulk of the interest. When features are deferred, end users make most of the interest payments. Either way the organization must service the accrued debt. Therefore, from the stakeholder perspective it makes sense to manage these debts consistently.

The Technology Ecosystem

Areas of the technology infrastructure are interrelated to form a structure similar to a biological ecosystem. Each area of the ecosystem has inherent dependencies on the others. Examples of these areas are represented as the slices in Figure 3 that give the triangle its depth. Gaps in one area almost always impact the others.

For example, weakness in the control environment often results in data quality issues. Poor platform suitability often results in a suboptimal user experience. Insufficient documentation impacts engineering practices. A big enough gap in any one area can cause the entire ecosystem to crumble. As such, no gap should be managed in isolation. Consider some examples of gaps that do not qualify as technical debt but can pose risk to the broader ecosystem.

Functional quality

One of the biggest risks of deferred or partially implemented features relate to data quality. A source of this risk comes from users “cramming” data from missing attributes in unintended places. This can occur when they do not have the data elements or functionality they need to do their job efficiently. Consider the example of an entity that is missing the ability to be deactivated or deleted. To differentiate between active and inactive records, users sometimes concatenate strings such as “(Inactive)” to the name field. This behavior has a denormalizing effect on the database and will impact downstream processes.

Other sources of risk include missing or inadequate controls. Validation control weaknesses decrease data quality by allowing invalid data to be entered into the system intentionally (e.g. cramming) or unintentionally (e.g. duplicates, typos, etc.). Weakness in access control implementation also presents risk to data quality and security. Access controls keep unauthorized users from viewing or editing certain data. Users are not permitted access to certain data because they do not have the training or clearance to interact with it. Data integrity will suffer when the controls that protect that data break down.

Risk imposed by unimplemented features also takes the form of hidden factories. Missing functionality often forces users to implement workarounds to complete their tasks. These workarounds result in hidden factories that decrease data quality and security. Examples of this include spreadsheets being used to process or report on data because the system that should provide that functionality does not. The logic contained in these spreadsheets is usually not sanctioned nor controlled which leads to inconsistency and several “versions of the truth.” Additionally, once the data leaves the confines of the system, any controls designed to protect it are taken out of play. Hidden factories are unregulated and pollute the environment with non-value add activities and risk to data quality and security.

Data quality

If we think of the infrastructure as an ecosystem, then data would be analogous to the water flowing through the river system. When it is polluted, other downstream areas will be impacted. We discussed that while deferred functionality is not considered debt, it can introduce risk to the ecosystem by polluting the river system with bad data. Ironically, the data quality gaps that can result from missing features are not typically a part of the technical debt discussion either. The toxic effects of defective data can ripple across an entire infrastructure. Bad data will impose cascading interest on any process or system that interacts with it. Inaccurate or incomplete data impairs a system’s ability to provide reliable intelligence and integrate with other systems. The unpredictability data quality issues introduce also create new technical debt by requiring workarounds in data movement logic.

Depending on the type of data involved, gaps in data quality can also create increased regulatory risk which can have severe consequences. The cost associated with poor data quality is estimated to be in the hundreds of billions of dollars annually for businesses in the United States alone [7]. Correcting this missing or inaccurate data is one of the more challenging and expensive remediation activities. This is because data defects rarely follow a consistent pattern and require significant discovery work.

Platform suitability

For purposes of this discussion, the “platform” refers to everything that allows the software to run. This includes hardware architecture, operating system, programming languages and frameworks. The computing platform provides the foundational topography upon which the technology ecosystem is built. How well the ecosystem is suited to its host topography differentiates success from failure. Further, the opportunities and limitations of the topography dictate how the ecosystem evolves. Likewise, a computing platform not well aligned to needs of the systems it supports limits capabilities and obstructs evolutionary paths.

Every component and subcomponent defined in the ISO software quality model is dependent upon the underlying platform. As such, nearly every decision made in software design and implementation is influenced by the host platform. However, the only platform related gap typically mentioned in technical debt discourse relates to the potential shortage of qualified resources to support legacy platforms. This is sometimes referred to as platform experience debt [12]. There are occasionally vague references to platform suitability concerns but they are usually reclassified as “IT debt” [13] or “infrastructure debt.” It is surprising that platform related deficiencies are not typically defined as technical debt given its current focus on factors influencing intrinsic quality.

Interdependency

In addition to the three areas we explored, there are several more examples that present risk but are deemphasized in technical debt discussions. This is a missed opportunity given how well the debt metaphor applies to these cases. The principal and expected interest associated with these gaps should be visible and subject to governance processes. Abstracting efforts to manage factors influencing intrinsic quality from that of extrinsic quality ignores the highly interdependent nature of the technology ecosystem.

Given this tightly coupled and interdependent nature, it seems critical that technology teams form a united front with business and project leaders in addressing risk factors. Active participation from software development teams is critical to any successful technical debt governance strategy. Designers understand the relationship between user experience and adoption rate, database developers know what to expect if proper validation controls are not present and systems administrators are aware of the risks associated with legacy platforms. This expertise must be leveraged to ensure effective management of the ecosystem.

The next and final article will discuss how the concept of technical debt is currently fragmented and the additional challenges that creates.

References will be provided in the last article in the series.

From http://blog.acrowire.com/technical-debt/the-stakeholder-perspective-the-ecosystem/