Experience has shown that large grained reuse can provide significant advantages over small grained approaches. This approach relies on shared, well understood domain models, architectures, and components. Customer /1 IP is a large grained asset consisting of the following assets: (1) a set of 14 binders of design documentation outlining both functional information (e.g., billing binder) and technical information (e.g., data model), (2) Installation documentation, (3) CUSTOMER/1 software, (4) utility software (e.g., testing software), (5) test data for installation testing, and (6) a design repository of all of the above plus additional more detailed work objects. The software has a distinct functional architecture facilitating customization. Some modules are parameterized to enable specific classes of customization. When modules are not parameterized appropriately for reuse, customization is done be replacing modules.
There is no official mechanism for improving the above assets. Improvements that are made in the context of an engagement remain with that engagement. Sharing of new and improved assets is done informally between managers. At this point there is almost a standard set of diskettes which are passed along with the repository which contain standard modifications/improvements to the Customer/1 IP baseline. These modifications/improvements are not rolled back into the baseline because there are no resources for integrating them.
In general, one can think of this reuse approach as being exemplar based. Relative to Customer/1 IP, the delivered customer information system for Illinois Power was recognized as being particularly good. It was declared the baseline (or exemplar) from which subsequent utilizers would start. This exemplar plus its immediate derivatives define a generation of solutions. The duration of a ╥generation╙ as well as what solutions become the ``next generation'' are driven by market forces. Within the Utilities Industry, AC is defining two new generations of solutions based on different market forces (i.e., Customer/1 Cooperative addressing client-server based development in Andersen╒s proprietary development environment, and Customer/1 Enterprise addressing client- server based development in an open development environment). The problem/challenge with the market driven approach is that it can result in an unnecessarily large number of asset generations. Discipline needs be exercised.