Extensibility

Table of Contents


EXTENSIBILITY

TTM ROI Sellability Agility Reputation

Extensibility is the ability to increase the scope (functionality) of a solution with relative ease.

The ability to easily add new behaviour(s) is an important characteristic of software. It is a business enabler, allowing new functionality to be delivered with minimal impact.

DEFINING EXTENSIBILITY

Extensibility is often described qualitatively - e.g. low, medium or high extensibility. Yet these terms mean different things, on different systems, to different stakeholders.

Generally, it is difficult to add new functionality to a system exhibiting low extensibility traits; whilst highly-extensible solutions greatly facilitate the addition of new functionality.

The ideal extensibility trait is one where we may support change, yet not require us to change the existing solution. With this approach we attach (plug-in) new functionality using a core extensible framework, preserving the existing code, and thereby significantly reducing effort and risk - such as reducing the likelihood of introducing new bugs, and any supporting Regression Testing effort surrounding that. This approach is likely to improve TTM, and ROI.

PUBLISH-SUBSCRIBE & EVENT-DRIVEN EXTENSIBILITY

This approach - attaching new behaviours - is foundational in many modern architectures and techniques, including the Publish/Subscribe model, Event-Driven, and Streaming architectures.

If extensibility is so important, shouldn't we always aim for highly-extensible systems? Unfortunately, the answer is less definitive. It depends upon: the solution's (and stakeholders) needs, whether it adds unnecessary complexity (Overprocessing in The Seven Wastes parlance), and how long the enterprise is willing to wait for delivery (Short-Term v Long-Term).

A CONVINCING ARGUMENT FOR EXTENSIBILITY?

Convincing stakeholders of the benefits of extensibility can be challenging as it sometimes involves refactoring the existing (functionally competent) solution, not adding new, sellable features. From this perspective, business stakeholders see no functional advances, only structural changes driven by engineering, so why would they subscribe to it? Additionally, improvements such as these are hard to quantify (e.g. “Did the customer benefit from these changes? Did they even notice?”).

The benefits lie in areas that see lots of change (either in adding new functions, or in replacing certain elements), making it possible to support many changes with little disruption. That equates to speed, and low risk.

PILLARS AFFECTED

TTM

A system that is highly extensible (in appropriate areas) promotes TTM, because (a) any addition has minimal impact (e.g. limited Regression Testing), and thus, (b) can be delivered (relatively) quickly.

ROI

We may achieve good ROI by supporting extensible mechanisms in appropriate areas (however, overusing this approach across an entire system is one of The Seven Wastes). If done correctly, these mechanisms promote a high opportunity for change, offering ways to easily tailor a system to specific customer requirements.

SELLABILITY

Systems that easily support the extensibility needs of customers promote Sellability. Negotiations are much easier if the solution easily demonstrates (efficient) support for a customer's needs. However, this does not suggest the employment of these tactics across a system's entirety (a form of Overprocessing).

AGILITY

Systems that are extensible to the needs of customers demonstrate that business' ability to be agile (and receptive) to customer needs, tailoring their systems to customer needs both known and, (as yet) unknown.

REPUTATION

Extensibility can also affect Reputation. If a client wants to add a behaviour to an existing solution, but the software is incapable of easily supporting it, then any change is either (a) technically infeasible, (b) inordinately expensive, or (c) too risky to undertake. All options can lead to potential reputational damage and a loss of sale.

SUMMARY

Like most architectural decisions, achieving high extensibility depends upon other factors. For example, extensibility (or quality) may be sacrificed to meet impending timescales.

The Open-Closed Principle [1] is a design principle that caters specifically to extensibility, advocating that the existing solution should not change to add new functionality, and therefore promoting TTM and ROI.

FURTHER CONSIDERATIONS