Tool: System Under Development (SUD)

The System Under Development (or SUD) is a critical aspect of the product development organization. It contributes significantly to the Essential Complexity of the enterprise and often is an important driver in terms of enterprise improvement capabilities. So, when unattended, it may create significant bottlenecks to the flow of value, and vice versa, when continuously maintained and pragmatically adjusted, it becomes a significant success factor.

The importance of SUD to the flow of value comes from the fact that SUD represents the actual environment (or medium) in which engineers operate. It is often incorrectly considered that the operational environment for teams is the physical space where they belong, communication and tracking tools, etc. All of these however are accidental to their work while most of the essential difficulty comes from the code they work with.

Different systems represent different levels of complexity and impact the flow of value differently. The following two examples illustrate two software projects, Celery and Django, in terms of the complexity of relationships between modules:

(Images used from on permission from the article author. The images obtained from the actual projects, using Snakefood dependency mapping tool.)

Clearly, operating in a simpler codebase is easier, faster and more predictable. Larger projects are usually harder to deal with; they decrease customer value throughput and dramatically increase variability.

It is vital for a change agent and the enterprise to attend the System Under Development.

There are two important architectural principles to be considered and these expand further on the concept that SUD design should not be uniquely driven by customer requirements but also by concerns pertaining to the enterprise’s delivery capabilities and economics:

  1. Design for flow of value.
  2. Design for responding to change.

Let’s consider some examples.

Example A:

Teams continuously struggle with transaction data validation module of their system, as it is  old and highly fragile code. Only a handful of people in a 90-person program feels comfortable working with this area of code. This creates a serious bottleneck in the flow as well as adds significant unpredictability.

The SUD needs a certain redesign effort to gradually reduce the fragility of the transaction data validation module to provide more readable, understandable and stable code. As such redesign progresses, more people should be involved in learning how to safely deal with this functionality.

Example B:

In a certain system, user profile functionality is significantly coupled with the functionality responsible for loyalty programs. User profile structure is stable and well established in the system and is not intended to undergo any significant changes in the future. On the opposite, new loyalty program functionality dominates the backlog and causes problems as changes in this area affect user profile functionality leading to various inconsistencies in the system.

A good design decision could be to separate the two areas as much as possible via establishing formal APIs between them that, once stabilized, provide significant leverage for responding to change (i.e. realizing new loyalty programs functionality or modifying the existing one without affecting other parts of the SUD).