The Reuse E-revolution -- ADTmag

The Reuse E-revolution

By Mike Crooks
January 1, 2001

Software reuse becomes IT risk management for the new economy. It is a solution for delivering better software, more quickly and at less cost.

As the pace of business increases, the gap between the demand for business capabilities and the software used to deliver them widens. The net result of this situation is that software has become a business risk instead of a business asset. CEOs faced with this dilemma have come to realize that "software is the business."

Doing business in the new economy requires responsiveness, agility and anticipation. But the trend of "e-everything" amplifies an already intolerable situation—IT organizations appear too slow, costly and unresponsive to the needs of the business. As businesses continue through the phases of "e-volution"—Web-enabled applications, e-commerce, business-to-business and beyond—the demand for software reuse has never been higher. Further adding complexity to an already chaotic world, IT providers have begun to align their software architecturally with the demands of the market through the use of components. While this has created a challenge for CIOs, innovative IT organizations are looking to turn this potential threat into a business opportunity.

CIOs are rapidly moving to re-invent their organizations and partner with the business through the use of architectural, organizational and economic models. They envision this emerging IT capability as demonstrating a "capability on-demand model" characterized by anticipation of capabilities required in the software, creation of an agile software infrastructure, and the ability to deliver more value, faster, to the business. To implement this vision, they have turned to software reuse as the binding process to enable their success.

The elements of software reuse
Software reuse processes, organizational capabilities and supporting architectures must combine to deliver practical business value—fast. IT organizations are beginning to integrate the power of components and the capabilities delivered through software reuse. Since CIOs have begun to embark on the renewal path, trends toward a "business within a business" model for IT are gaining in popularity. In fact, some CIOs view their organizations as a "Reuse-driven Software Engineering Business"—Reuse Business¹. To achieve full integration of this advanced organizational concept within a business, a company must address these five essential elements of software reuse:

Business Architecture Alignment—To effectively anticipate the required capabilities for responding to market opportunities, IT managers have begun to employ enterprise architectures for the business. By creating a model of the relationships between the business' product alignment to market segments and the operational capabilities required to be competitive and meet corporate goals, IT managers can create a software model capable of effectively supporting the business. Given organizational capabilities as requirements for possible software systems, the identification of the right components and the proper timing for having them available is now possible without waiting for a project to be initiated. Furthermore, by aligning in-year priorities with advanced identification of the potentially valuable components, the capabilities and responsiveness of the IT organization are greatly enhanced.
Project Initiation—The primary role of an IT organization is to deliver value fast and without unnecessary impedance. Typically, the vehicle used is a solution delivery project. Customers of the IT organization measure value through the success or failure of the solution delivery projects. IT organizations can capitalize on the anticipatory information created through business architecture alignment. For this to happen, early participation in the organization's decision on which assets to leverage within a project is critical. By employing a process of requirement analysis to component capability matching, the contribution from a component can be estimated more precisely. Allowing a project manager to accept or reject a proposed solution option (based on risk, cost and time) maintains the industry-accepted project management practice, rather than attempting a very difficult cultural change in the organization.
Additionally, the confidence of a project manager to manage risk is left intact, leveraging the opportunity to save both time and money on the project. The speed at which this "knowledge-based" solution option analysis is performed creates the perception of an organization that is driven by business value and very responsive.
Project Enactment—Because the IT organization is measured on the success or failure of the solution delivery projects, it is vital to "do what you said you would do." In an incomplete model for implementation of software reuse, the project team is usually left to work through component reuse. Given the likelihood that the components are not of "black box" maturity, this is usually catastrophic. The IT organization must follow through on the plans created during the Project Initiation phase. This requires that at least two types of assets be available for a project team. The first, a knowledge asset, is a predefined project framework that includes a process model, solution development environment and a project measurement system. The availability of this framework allows a project team to start off with a repeatable and consistent approach for known project types. Additionally, the identified components, or construction assets, required for the solution need to be available and implemented during the course of the project.
Asset-driven Services—The agility of a business in today's climate is directly related to the flexibility and extensibility of its software infrastructure. The balance required to lower total cost of ownership through reuse of common components and customization for specific business needs is a delicate one. To ensure agility and maintain balance, creation of an organizational entity, a Reuse Center, with the sole responsibility for project success with software reuse, has made a difference in IT organizations. The operating model of a Reuse Center must be that of an asset-driven service provider. The design of the function requires the following capabilities to be resident:
- Asset Administration—the classification, certification, publication and support of the software components for visibility to the solution delivery project teams.
- Asset Provisioning—the creation, acquisition or harvesting of software components and the supporting knowledge assets for the rapid and value-added consumption by a solution delivery project team.
- Project Services—the "contracted" reuse services to enable the successful delivery of business value through the reuse of software components.
- Architecture Management—the identification, prioritization and selection of the right software components to be provisioned.
Since the organization is managed as a "business entity," its survival is dependent upon being contracted by solution delivery project teams. Therefore, the selection and propagation of software components is done with the outcome of business value as a primary objective.
Business Economics—Planning, tracking and reporting the business value of software reuse is the element most commonly missed by IT organizations. This is due in part to the general lack of focus on the outcomes of the reused software as opposed to the metrics related to the software itself (such as complexity, robustness, maintainability and so on).

Although these aspects are necessary for good software management, they are not sufficient as business value measures. Many IT organizations continue to focus on the technical aspects of software reuse and implement in "technology-driven" approaches. The real driver for software reuse, however, must be in recognizable terms such as:

Shareholder Value and Corporate Return on Investment (ROI)—Shareholders are interested in the growth of a business' stock value and thus are very sensitive to the cost structure of the business. IT organizations have long been viewed as cost centers and not investment-driven business entities. By shifting the focus of the IT organization to measure itself and its software spending in terms of ROI, the business is motivated to support, rather than challenge, IT spending.
Customer Satisfaction and Project Return on Investment (PROI)²—For an IT organization to be viewed as a value-added partner to the business, the business wants constant attention to and reduction in the time and cost of delivering business solutions. There is nothing more compelling to the business than a measurement system that continually demonstrates "faster, better and cheaper." Customer satisfaction is very subjective, but it is necessary to ensure the IT organization's reputation. Simply "doing what you say you are going to do," goes a long way toward satisfying this objective.

Balancing IT renewal and effectiveness
Organizations must be structured to accelerate value delivery. To aid in the successful definition and implementation of software reuse, you must consider the following rules of thumb:

Look to the future, but do not forget to understand the present. Few situations in corporations will allow new capabilities to be implemented in a green field, so an understanding of the current capabilities and constraints is needed. It is risky to move from the current state without an understanding of how the current capabilities interoperate and why they exist. Likewise, a model of the desired state must be created. Current business goals and expectations need to be analyzed and designed into the new capabilities. Additionally, the set of imaginable scenarios for usage of the new capabilities needs to be considered. Through the combined view of these two models, an effective engineering plan can be designed. By prioritizing the high-demand and business-valued capabilities, these models can serve as the basis for an incremental change program.
Form follows function. To design an organization capable of delivering effectively under a reuse-driven approach, the functions needed to do the necessary work must be designed. Far too often, organizational design comes before the required service functions are understood. If reuse is a central goal, then it must be placed centrally within the functional model. The resulting ripple effect will help determine the best operational form for the organization. The process for the functions to deliver effectively and efficiently to those customer expectations also needs to be designed. The organizational form is implemented with objective metrics to measure and monitor the economic drivers and contributions to the ongoing solvency of the organization.
Pay people to do a job within a function, making sure to reward exceptional behavior and outstanding achievements. Reward and recognition is a critical success factor for establishing a reuse culture. Creating the incorrect reward and recognition framework can be disastrous. Many people believe that incentive-based reuse rewards, such as paying a creator of a reusable asset for each time the asset is reused or paying project teams to reuse assets, is a good idea. However, this royalty-based model can create a situation under which the "wrong" behaviors are reinforced. Reuse will occur, but for the sake of the rewards and not necessarily because the right assets are being reused. Organizing the solution engineering functions to allow for specialization lets people align to their strengths and desires. Paying them to perform these roles based on traditional practices (skills, seniority and so on) is still appropriate. Additionally, change to the current human resource practices of the adopting organization is minimized. Incentive plans can also be aligned to individual and team achievements, like accelerated time to market or under-budget delivery.
Do not build for reuse on the tactical delivery projects. Many attempts have been made to deliver reusable assets during business solutions delivery projects. Although it is possible to build components and frameworks for reuse while delivering a business solution, it also serves as a temptation to over-engineer a solution. This results in cost/time overruns or, worse, the cancellation of a needed business solution project, which is a significant setback to the approach and its supporting technology. The tactical pressures will always, and rightfully so, re-prioritize the delivery schedules and functionality of the solution. Consideration should therefore be given to a post-delivery project initiated to deliver the more robust functionality required for a component or framework to be reusable. Although this will require additional time and money, it will also serve to make reuse the explicit goal of the investment.
Credibility gaps within organizations must be closed or investments will be futile. For years the value of technology has been professed as a panacea. Client/server, object technology and reuse—now there are components. The stance by many executives is that of skepticism, if not extreme resistance. Along with the many failures of technology-driven solutions, the confidence in internal development organizations to deliver on time and within budget is dismal. On top of the skepticism about technology helping the software delivery dilemma, the organizations themselves are now under fire. The issue has become one of survival. The credibility gap must be addressed through a comprehensive and professional marketing program. There is no value in having a world-class capability if no one knows about it.
Investments in a reuse capability must be properly positioned to ensure usage. Reuse centers and software component libraries are only valuable if they are used. Many corporate visionaries see the value of the investments in the reuse infrastructure elements. However, too often the business solution delivery teams never accept the necessary environment of value-based service delivery from the infrastructure organizations. Viewed as architecture police, enforcers or glass tower academics, technology organizations are often shunned. Many attempt to mandate usage through a "preferred vendor status." This eventually creates failure due to the lack of buy-in and commitment from the project teams or "scapegoats" for failure to deliver because of the additional learning curve and complexity.
The only truly meaningful way to success is to support a project by "rolling up your sleeves and helping get the job done." This means negotiating a partnership agreement and accountability in the structure of the solution delivery project. The validation of the approach and the assets in the library is a real testimonial, and the stigma of "advisors" has changed to "doers." The necessity of this type of approach is not long-term, but it needs to be in place until the knowledge transfer of the requisite skills and competencies to the solutions delivery organization has been achieved.
Project-driven, tactical delivery-oriented organizations usually amplify the previous two behaviors. Organizations will remain project-driven and tactical delivery-oriented, but this is not necessarily a bad thing. Many organizations feel that if there is not sufficient leeway in project priorities and schedules, it is not possible to begin the adoption and use of components. This is simply not true. Focusing on a specific customer's needs and delivering to those expectations is what delivery teams are measured against. The absolute requirement, if the benefits of reuse are to be achieved, is to ensure that a separate, supportive function manages the "life without a project view of a component." The primary risk to this approach is that the delivery teams usually believe that "they have been doing reuse for years; what's different now and why should I care?"
The fact is most organizations and their delivery teams have been doing reuse for some time. Most software engineers work this way on a project. The difficulty arises when multiple projects need the components, and the breadth of capability of those components must span multiple lines of business or organizations. A cross-functional organization view and individualized support is required to respond to the varied priorities of the business. A separate, component-centric organization preserves project focus and can deliver effectively and uniquely. The benefits of software reuse will be the cumulative value of the individual project successes.
A business' success in the new economy depends on a CIO's ability to deliver business solutions in days and at half the cost of today's solutions. To achieve this goal, the IT organization must design, implement and execute an effective software reuse capability. The capability must be accountable for the management, usefulness and evolution of the business solutions delivery infrastructure. A well-designed and -engineered, organizational, change-driven model ensures that the focus on process and economics, not the technology, remains intact. By implementing the functions for reuse asset management and support, project delivery with high use of readily available assets, and a management umbrella for balancing the tactical needs of the organization with the investments for the future, solution delivery organizations can finally become valued business partners.

FOOTNOTES
¹ Reuse-driven Software Engineering (Reuse Business) is a concept presented by Ivar Jacobson, Martin Gris and Patrik Jonsson in their book Software Reuse: Architecture, Process and Organization for Business Success, Addison–Wesley Publishing Co., Reading, Mass., 1997.

² Project ROI (PROI) shows the financial benefit of reusing the software components to the reusing organization. It represents money that did not need to be spent during either the development or maintenance netted out against the additional cost of reusing the software components. PROI is further defined in Jeffrey S. Poulin's book, Measuring Software Reuse: Principles, Practices, and Economic Models, Addison–Wesley Publishing Co., Reading, Mass., 1996.