OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software

+44 1249 815081

 

Business Modelling

Adopting a Process

 

more@oig.co.uk

Business Builder

Component Development

Home

 

Full Life Cycle

Delivering on the J2EE

 

OIG provides help with managing reuse, by addessing issues such as scope, project management, culture, infrastructure and tool support.

We have helped numerous companies establish and manage reuse in many different areas of their business. Reuse is relevant to all companies large and small alike - effective reuse really works ! But the biggest lesson we have learnt and now help others to understand is reuse doesn't happen by accident. Reuse is a business decision ! We can quickly assess your reuse requirements then establish the best path of action for you. Whether it's reuse of models, code or practices you are after we can ensure it happens. We have our own bespoke process for achieving reuse or we can tailor many others such as RUP to deliver. We were there at the start of component-based development and have grown up alongside it. To the extent that the components we use have matured by re-development across industries and are now truly generic.

Would you like to know more about what we do ?

Perhaps you would like to discuss your specific issues with managing reuse - then please phone us on +44 1249 815081 or mail us at more@oig.co.uk

Or discover how a consortium of large scale users - the Object Interest Group - learnt how to manage reuse. The page that follows details this work and although developed sometime ago the guidelines on enabling reuse and setting expectations are still relevant today.

Managing Reuse


Reuse was the hype upon which OT was originally sold but evidence of it actually being achieved was not that apparent. In fact, there was more evidence of OT having been abandoned because it had not immediately delivered the promised levels of reuse. However, it was clear that the claimed productivity gains were still attractive but were only to be gained from effective reuse. We therefore decided to take a closer look at how this might be realistically achieved.

The objective of the ‘Managing Reuse’ project was to address the questions :

  • What reuse level is desirable and practically achievable over the next 3 years ?
  • What should I do to enable it ?
This project addressed the whole life cycle, corporate IT and project management issues, library management and co-existence with legacy systems. It also suggested and provided guidance on a number of routes for achieving effective reuse, and was substantiated by supplier and IT user experiences between ‘92 and ‘93.

The main management issues we gathered from our member companies were concerned with :

  • Whether reuse was essentially a business.
  • Evidence of successful reuse.
  • Scope and type of reuse found in practice.
  • Enabling reuse and the role of the librarian.
  • Project management.
  • Quality.
  • Methods and tools.
  • Sub-contracting and out-sourcing.
  • Legacy code.
  • Costs.
  • Metrics.

Reuse as a business decision

Effective reuse will not be achieved by developers or analysts working in isolation. It requires the cooperation of all those involved in the software development process. Neither will technology alone produce significant reuse. This will only be achieved if the business is involved as well. In reality, a mixture of technology, business, commitment, infrastructure, management, tools and education is required.

Evidence of successful reuse

It is now evident that most OO practitioners are starting to actively address reuse. Members are handling reuse well, but cautiously. They are aware of the barriers, such as the investment required to ensure an adequate infrastructure is in place, but they are not ignoring them. Instead, they are actively addressing the barriers by, for example, starting to try and develop a suitable reuse infrastructure on a small scale, while continuing to build-up their experience of meeting real project demands and thereby increasing the penetration of OO throughout their companies. In this way, they are actually starting to see some of the benefits of reuse, such as reduced maintenance effort (increased robustness), while solving some of the problems, such as determining how to encourage people to reuse. Using this approach, they are not immediately achieving the dramatic reuse figures often publicised by suppliers, but they are also not experiencing disastrous costs !

Scope and type of reuse found in practice

Members and other practitioners are now achieving reuse in applications across projects and business areas, ie they are starting to see corporation-wide reuse. With respect to the type of reuse being achieved, most practitioners classify reusable components into a number of categories. Although these classifications vary to some degree, in general they include low-level technical, middleware and business categories. The evidence from most practitioners is that current success is confined to the technical and middleware categories. Although, we are starting to see the emergence of reuse in the business category, particularly in the telecomms and financial dealing industries, where OO is more established.

Enabling reuse and the role of the librarian

Encouraging reuse involves effective communication and requires an adequate supporting infrastructure for it to be enabled. Both our members and the practitioners we met, have found that library management, component development and tools for communication, browsing and testing are all essential parts of an effective reuse infrastructure.

The key tasks of library management include reviewing projects, encouraging the development of generic requirements, helping to identify potential reuse candidates, testing, version control, raising awareness of library content, and any changes, standards monitoring and inclusion, maintenance of metrics and administration. That is, the people involved in library management are chiefly responsible for promoting and enabling both the development and use of components. For this to be done well, members and other practitioners have found that high-profile roles, where these tasks are their main responsibilities, need to be established. At the start, or on small projects, it may be possible for these roles to be part-time, but as OO penetration increases, they need to become full-time librarian roles. Furthermore, once reuse extends beyond the project level, members have also found they need a corporate librarian to focus on components with corporate benefit, by liaising with the various business areas and project librarians.

Project management

The conventional culture of most IT divisions mitigates against reuse. Project managers are rewarded for delivery, they are not rewarded for reducing colleagues’ costs and timescales. New approaches to organisation, costing and reward systems are needed to change this culture.

The key objective has always been to deliver on time, within budget. With OO, it is necessary to realise firstly that there are now two deliverables - the application itself and the component library - and secondly that there is an additional objective - to make the most of reuse. To do this, the project manager needs to understand the different skills required in using and developing components, as opposed to building applications from scratch. This requires considerable coordination and communication, and while this is relatively easy in small teams, it is much harder in large teams. This is eased by the existence of a project librarian, as long as the project manager clearly establishes the role and coordinates the interaction of the librarian with the rest of the team.

Quality issues

Members have found that the reuse of poor quality components should be avoided at all costs, as it quickly demoralises staff and impedes the shift to a reuse culture. Good quality components take a considerable amount of effort, so being able to buy in good components is seen as very attractive.

Methods and tools

A reuse culture places different requirements on supporting methods and tools. Ultimately, methods and tools are needed which support a ‘construction-by-component’ approach (including component browsing/selection and reward/enforcement systems), iterative development, configuration management and version control. But at the time of the project no methods or tools adequately supported any of these. In fact, there were very few tools specific to reuse and those which were available were still immature. This included any communication tools and reward/enforcement systems, the lack of which emphasised the need for full-time, high-profile librarians, who in many cases had to carry out these tasks unsupported.

Source control systems, such as SCCS or RCS, were used to help with version control, but their use was neither elegant nor simple. A number of browsers were available, but most operated on an inheritance-like basis, which many practitioners found wasn’t the most natural way to search for components. At the time they felt that potentially basing browsers on, for example functions, relationships, categorisation or prospecting might be preferable.

The PARTS Workbench from Digitalk, went some way to providing a visual metaphor for ‘construction-by-component’, but at the time of the project was not suitable for a large number of components.

A significant tool development at the time was Hitachi’s Object Reuse Librarian (ORL) which provided the library developer with integrated version control, version-history browsers, hypertext authoring and guidance for reuse. They had also included some of the different approaches to browsing.

The best choice of tools seemed to be for Unix and the most limited for OS/2. We felt that many of these early tools would not survive but at least they offered an interim solution as long as any investment in them was carefully considered. However, in our opinion many more tools were needed which supported reuse specifically, either from the management perspective or the developer’s perspective.

Sub-contracting and out-sourcing

With sub-contracting and out-sourcing it is even more important to realise that there are two key deliverables - the application itself and the component libraries. These libraries are essential to the continued evolution of the application as well as related applications. They must therefore be built to a standard from which continued component evolution can take place (possibly in-house) at reasonable cost. This issue needs to be handled up-front at the contract negotiation stage, as members have found that realisation and re-negotiation half way through can be very expensive. The issue of ownership of libraries also needs to be clarified. Most of these issues still exist when sub-contracting is not involved, but re-negotiation is not as visible.

Legacy code

In a number of cases, legacy code was being reused by regarding existing systems and databases as large objects. This was enabled by ‘wrappering’, that is by defining object interfaces to the legacy code so it is effectively encapsulated.

Costs

Evidence we collected suggests that reusable components require two to three times the effort to develop as an application-specific solution. However, given that this includes trying them out in at least three applications to ensure their quality, it ought to be possible to defray the cost, across applications and possibly projects. But this again requires a culture change and supporting infrastructure. Members and practitioners’ early evidence, however, suggests that this up-front investment in good reusable components will ultimately save money on development and maintenance.

The librarian roles are also a perceived as additional costs. But the members and practitioners who have established the roles, all found that their existence had in fact proved cost-effective. This was because the librarians had been able to prevent unnecessary class development, while improving the overall standard of code reliability and documentation, ultimately resulting in cost savings.

Metrics

Metrics were not readily available at the time of the project. Practitioners seemed to vary considerably in their opinion about the true value of metrics, but members in general had found a need for them. The key metric at that point was believed to be the percentage of components being reused, so that a continuous check could be made on the cost and worth of library investment.

Concluding remarks

Evidence from our members and visiting practitioners showed that while a company is new to objects it is better to get a few successful projects up and running. Reuse can then be considered in subsequent, preferably related projects, in light of experience gained from the initial work. But at this point it requires serious consideration because for reuse to be effective it needs everybody’s commitment.

Reuse involves good communication and encouragement, and to enable this a proper infrastructure is absolutely essential. This needs to include librarian roles and appropriate tools for browsing, communicating library content and change management.

The benefits of reuse derive from reducing development effort, greater software robustness and less maintenance and enhancement effort. This was supported by both our own members’ and external practitioners’ experiences. But the necessary mixture of technology, business, commitment, infrastructure, management, tools and education to achieve effective reuse does cost ! On the other hand, doing nothing could mean over 200 man-years of OO code that needs re-engineering. Overall, the longer-term potential benefits were considered to exceed the costs.

In conclusion,where reuse is being tackled effectively, a comparatively cautious approach is being taken. Expectations are sensibly constrained while the level of OO experience is raised, organisational management and an adequate infrastructure are developed. On average it is taking around three years for the benefits to outweigh costs, but thereafter the productivity gains are significant.


Created : 30th April 1996

Updated : 11th August 1996

Go to top of page

 

The Object Interest Group
 
History of the Object Interest Group
An Assessment of OO
Starting with Objects
Choosing a method
Feasibility of CBOs
Components and BPR
The Object Interest Group Home Page
Go to OIG Ltd Home Page
© The Object Interest Group

Any comments on these pages to: more@oig.co.uk

© OIG Ltd 2002-2003

Legal