Increasing Chances for Software Reuse
Accelerating software development through reuse has long been a goal of IT. Previously, I discussed that development methodologies tend to encourage development rather than reuse. Because Agile is so focused on quickly delivering to the customer, it could be particularly susceptible to subtly discouraging reuse. Code Conjurer is an interesting plug-in for the Eclipse development framework that is designed to complement Agile, test-driven development by automating reuse of fine grained software components. Though Code Conjurer has the potential to be beneficial, it only addresses part of the total opportunity for reuse.
Code Conjurer is explicitly focused on finding small pieces of code to reuse, which means that many big opportunities are outside the scope of Code Conjurer. Rather than waiting for the team to find opportunities for reuse, IT leaders should increase chances for reuse on a large scale. Creating opportunities requires leaders to move further upstream from individual projects; they must influence the environment in which projects are created. In this article, I will introduce a few ideas to indicate the breadth of the topic and the need for senior IT leadership involvement, but I will also recommend some resources for further details.
Pyramid of Reuse
I will use a pyramid to visualize an approach to maximize reuse. The base is architecture and strategy. The next level is management practices and culture designed to encourage reuse. Finally, at the top of the pyramid are tools such as Code Conjurer, which promote reuse.
The first layer in the reuse pyramid is to ensure that enterprise architecture and standards are in place. Having an enterprise architecture that specifies the major systems at the core of the IT infrastructure encourages reuse on multiple levels. Most obviously, it avoids multiple systems solving the same problem.
If the corporation’s architecture is built around SAP Customer Relationship Management (SAP CRM), the SAP engine is reused for many functions, and the corporation avoids buying Oracle CRM. Likewise, standards for development and integration such as coding in Java or requiring MQ Series for integration provide yet another level of guaranteed compatibility. In Reuse-Based Software Engineering, Mili, Mili, Yacoub, and Addy detail the ways that architecture and standards can support reuse. Having an enterprise architecture and enterprise standards is the foundation of the pyramid and maximizes the opportunity for later, fine-grained reuse.
The next layer in the pyramid is to create development processes and an environment that support reuse. From the concept and requirements gathering phase of each project, a person knowledgeable of corporate standards should assist the business in setting requirements. In many cases, requirements are created from the baseline of a product with which the users have experience–often, it is the product they used in a prior job. If requirements in that context are malleable, using the corporate standards as the baseline will maximize later reuse. Guiding requirements gathering without negatively impacting the team’s ability to establish the “true” requirements requires a sophisticated executive and a corporate culture empowering that executive.
Later in the development process, designs should be reviewed by an architectural committee for compliance with enterprise standards and for leveraging existing systems where possible. Of course, the design should also be reviewed to ensure it presents appropriate opportunities for reuse of newly created objects. The project architectural review should be supported by the employee review process. A project that does not fully leverage reuse opportunities should suffer in terms of project score, and the individuals on the project should feel the impact on their annual reviews. Ultimately, compliance metrics should be tracked to ensure the organization continues to move in the right direction. Jeffrey S. Poulin in Measuring Software Reuse gives an introduction to measuring reuse as well as the financial benefit of reuse. Project processes and development processes should reinforce and encourage reuse.
With those layers of the pyramid in place, the final layer is made of the tools that support the enterprise standards and business processes. At this level, Code Conjurer is a significant addition to our reuse pyramid; it searches for reusable components that are guaranteed to satisfy our test requirements, and it minimizes impact on the developer’s work.
As you can see, there are many aspects to reuse: small and large scale as well as reactive and proactive. Software reuse will not happen by accident. In fact, without focused attention, developers will develop and redevelop. IT leaders must create a pyramid of architecture, process, and tools that actively promotes reuse. The value of that pyramid should be communicated with metrics that show both financial and time savings to ensure the topic remains a priority at every level of the organization.