Systematic Re-use

Re-use is based upon one of the fundamental principles not only for lazy software engineers: DRY (Don‘t Repeat Yourself). Instead of reinventing the wheel developers and architects may re-use existing artifacts instead of reinventing the wheel again and again. 

Re-usable assets come in different flavors:

• Code snippets are small building units developers may integrate in their code base. 
• Patterns are smart and proven design blueprints that solve recurring problems in specific contexts.
• Libraries comprise encapsulated functionality developers may bind to their own functionality.
• Frameworks also comprise encapsulated functionality. In contrast to libraries developrs integrate their own code into the framework according to the Hollywood principle (don‘t call us, we‘ll call you).
• Components/Services include binary functionality (i.e., they are executables) that developrs may call from their own application.
• Containers represent runtime environments that provide functionality and environments to applications in an isolated way.

Apparently, these are different levels of re-usable assets with varying granularities, complexities, and prerequisites.

Software engineers may not only use re-usable software assets, but other types as well. For instance:

• Tests, Test units, Test plans
• Documents
• Production plans
• Configurations
• Business plans
• Software architectures
• Tools

While some assets such as code snippets may be used daily in the code-base, patterns or software architecture templates need to be instantiated in an easy way. 

The more impact re-usable assets have on applications and the more abstract they are, the more systematic the re-use approach must be. The most challenging projects are product lines and ecosystems that require different assets at different re-use levels. For example, they introduce the need for a configurable core asset base that is re-usable across different applications. Furthermore, they support a whole class of applications that share the same architecture framework and other assets. A core asset in a product line or ecosystem affects not one application but a whole system family.  Thus, its business impact is very high. 

In such scenarios, core assets often are inter-dependent and must be configured for the specific application under development.  As a prerequisite for the development of a core asset base, a Commonality/Variability analysis is necessary that determines what applications sharing the same core assets have in common and how they differ. A core asset needs a common base relevant for all applications that use it as well as configurable variation points to adapt it to the needs of an application. 

A bad or insufficient  Commonality/Variability analysis incurs higher costs a may even lead to project failure. 

Core asset development and application development might happen separately by different teams or  by the same teams. Each approach has its benefits and liabilities.

Due to the high business and technical risks of these advanced approaches, all stakeholders need to be involved in the whole development process. Building a product line or ecosystem without management is not feasible. Managers need to re-organize their organisation, spend budget for core asset development and evolution. 

Most product lines and ecosystems fail, because:

• lack of management support,
• insufficient consideration of customer needs,
• inappropriate organisation,
• inadequate Commonality/Variability analysis,
• insuffient or low-quality core assets,
• underestimation of testing or inadequate quality assurance,
• bad software architecture,
• neglectence of competence ramp-up activities,
• no re-use incentives,
• missing acceptance by stakeholders.

Consequently, product lines and ecosystems need a systematic approach for re-use  and must involve  different types of stakeholders. They need a manager  who is able to guide the approach and has the capability to decide, for example, on budget, organisation restructuring, competence ramp-up activities, or business strategy. 

Re-use comes in different flavors and the higher its impact the more systematic the re-use process needs to be

[to be continued]