Kathryn Priest Yglesias

Knowledge Management

IBM Global Services

for WISR 99

Tel: (919) 993-4258, fax: (919) 993-4404

Email: yglesias@us.ibm.com

The progress toward systematic software reuse has not reached the expectations of ten years ago. The WISR community should change its role to proactive by creating a Institutionalizing Software Reuse Consortium with the goal of propelling the software industry forward.

Keywords: systematic software reuse, software engineering, software standards

Workshop goals: determine interest in creating a consortium to facilitate software reuse

As we approach the end of the century, the progress toward systematic software reuse in major global corporations is significantly worse than was expected in the 1980’s when many of the technical barriers were first being overcome. What has led to this disappointing progress? Perhaps the major factor is that the pace of change in technology has been more rapid than expected, or maybe it is that major markets have evolved and consolidated at rates that leave software systems constantly outdated, with the task of catching up seeming less likely as time progresses. There is also the unpredicted proliferation of the internet as a driving force in business and the resultant need for systems to be re-architected to be network centric.

Since there is no reason to believe the pace of change will do anything other than accelerate, what should the software reuse community do to provide a life raft to corporations who continue to lose ground in the race to get their applications deployed? Only by aggressively addressing the need for common structures within software can we make progress. What is required is to take software development from being a "creative invention" activity to be the counterpart to the "nuts and bolts" assembly of hardware.

Some may remember when, more than a decade ago, we renamed our professionals from programmers to software engineers. This was and is an idea that makes sense; however, the change to engineering discipline and structures did not happen by itself and there has never been a serious attempt to organize it. Perhaps engineering discipline has never been seriously wanted. If it is still not wanted, then global corporations will not achieve systematic software reuse in this coming decade either.

If now is the time that companies want to address their application backlogs, despite increasingly critical shortage in skilled software workers, maybe now is the time that these same companies will want to invest in changing the re-invent environment to a reuse-oriented assembly environment. If this software engineering ability is what is wanted then a consolidated effort by major players to attach the problems on a worldwide scale is required.

The type standardization activities, such as Object Management Group (OMG), are a step in the right direction but are so slow and limited in scope that the software industry will only achieve minor headway towards an "engineering" environment in the next twenty years. The difficulty is that the software industry generally shows a lack of interest in standardization other than as a technique to win and capture market share (as permanently as possible). Why should companies in the late twentieth century cooperate? The reason is that each and every one has markets they could be winning, profit they could be making if they could only get their new IT systems and capabilities out the door, but they cannot due to personnel and complexity problems.

The personnel problems stem from the growing shortage of skilled software workers, which in turn leads to increasing turnover, and from the difficulty keeping software developers and analysts trained on the latest technology in the rapidly changing environments. The complexity problems arise from two areas: legacy systems are patched, stretched and "enhanced" to try to meet today’s problems without time being (made) available to do the major re-designs and re-writes needed, and because network centric e-business applications are more difficult to design and test than their predecessor client-server or host-based applications, especially when all three architecture types must coexist efficiently.

What can the WISR do? The corporations and universities involved in the WISR could create a consortium to focus efforts worldwide that would drive the definition of architectural and programming model standards to create an environment for component based and generative software reuse. Once the architectures and models have sufficient backing, there will be no lack of software industry participants willing to create the parts.

Of course, if this was easy it would have already been done. Some of the inherent difficulties of reuse in our current marketplace can only be overcome by cooperation of the major players working together to achieve a set of open standards. (Obviously this must be done in such a way as to avoid collusion or the impression of such.) The intent must be to "ratchet up" the entire software industry by providing the same type productivity benefits achieved by standardizing screw threads and electronic subassemblies.

The role of the WISR is to motivate the participating corporations and universities to fund the formation of the "ISR (Institutionalizing Software Reuse) Consortium" and to recruit other major corporations and software industry players to participate. Without participation of all the major software industry players the efforts will be slower, more difficult and potentially will ultimately lead to failure. Without enough industry players there will be insufficient funding. Without enough universities there will not be enough resources to rapidly address the many architectures and models.

The balance is to have enough players without having so many that "gridlock" results. The key is the agreement to common objectives. This alone could take years without a forcing function. One of the first tasks of the WISR in defining an ISR Consortium would be to identify the "value proposition" for the participants. Leveraging an industry situation, such as the change of European currencies to the EURO and its resultant impact on worldwide software systems, could be an opportunity. Corporations will have just spent millions on fixing their Year 2000 problems and be years behind their planned upgrades, only to have to now upgrade their financial, billing, procurement and other systems. The combination of these system changes, together with the personnel and complexity issues mentioned earlier, may motivate an interest in standardization activities that would not otherwise be considered.

Creating a successful consortium will take a strong business leader with excellent marketing skills. Such a business leader will need to be recruited from the industry since industry knowledge is critical. Equally important is that the person have the impartiality to work through competitive issues between participants. Although the overhead for such an endeavor must be kept small, a sufficient, skilled staff is also required.

A second success factor will be to learn from the lessons of previous efforts. Consortia are regularly set up in today’s IT business -- many are short lived and accomplish little, others continue for years (e.g., MCC for the microelectronics industry) and achieve measures of success. The ISR Consortium, being a reuse based consortium, should excel at leveraging the knowledge gained from previous and existing consortia.

Another key facet of success is to rapidly demonstrate success to stake holders, in this case the investing corporations and universities who are participating. This means that the selection must be carefully made of which architectures, models and standards to work on first. Currently some infrastructure domains and some industry and cross-industry domains are achieving some consensus on approaches through various standards organization activities. Potentially getting more emphasis by participants in driving best of breed work in some of these activities will be a quick return activity. However, it may be determined that those activities lack an overarching set of architectural principles and so will not provide a broad ability for integration and interoperability between domains over time. In this case architectural principles, defined and delivered to market in stages, might be an important initial project.

There will be a need to constantly monitor market and technology trends to identify changes and then decide whether continuing funding is appropriate for ongoing projects. In software reuse today, throwing away is as necessary as creating. Some market trends appear to be significant enough that investment in them provides reasonably low risk, e.g., extension of the Enterprise Resource Management (ERP) application domains into related areas such as customer service. In the ERP domain the market penetration of SAP and a few other vendors is so significant that defining architecture and model extensions is less difficult than in highly segmented markets without clear market leaders.

The Standards Infrastructure

A standards infrastructure is needed for disseminating and getting buy-in on standards created by the ISR Consortium. As many standards organizations should be involved as makes sense (e.g., industry specific) but the International Standards Organization (ISO) should be considered as a primary partner. The ISO organization is preferable due to their strong worldwide presence, their coordination and leadership activities with the European Economic Community (EEC) and their set of software development standards. (The Software Engineering Committee of the IEEE has expressed an intent to discuss with ISO how IEEE P1517 Standard for Information Technology - Software Life Cycle Processes - Reuse Processes can be integrated into the relevant ISO standards.)

In summary, the WISR should consider immediately initiating the study of how to form an ISR Consortium to proactively drive the definition of a set of architectures and models that can be used by the IT industry to build interoperable sets of "building blocks" for use by all software developers, thus creating an engineering environment.

Kathryn Priest Yglesias (yglesias@us.ibm.com) IBM, M/S 676/BHQ, 3039 Cornwallis Rd., RTP, NC 27709

Kathy Yglesias is a consultant in IBM Global Services and works with the Knowledge Management organization to expand their reuse initiative to include software. She has worked on various aspects of software reuse at IBM for eleven years, including designing and managing software repositories, defining and implementing classification schemes, writing guidelines and standards, providing training, and championing management level change. Kathy is a member of the IEEE standards group for software reuse. Previously Kathy worked at NASA's Johnson Space Center on flight design and at Ford on management information systems.