NEWS AT SEI
This article was originally published in News at SEI on: September 1, 2001
Increasingly, software systems are integrated from commercially available software components, including database management systems, middleware components, and domain-specific application components. The reasons for this are many, but include the need to reduce development costs, the need to reduce time to market, and the lack of technical expertise.
The development of systems from commercial components, however, introduces uncertainty and complexity into the software engineering process. Traditional software engineering methods and processes have proven inadequate and must be modified to face the new challenges imposed by the use of commercial components. In particular, component capabilities and liabilities are a principle source of design constraint in system development.
The SEI has used its experience with customers developing large complex systems from commercial components to develop a collection of methods and techniques that address these new challenges. SEI authors Kurt Wallnau, Scott Hissam, and Robert Seacord document these methods and techniques, as well as an extensive case study drawn from customer engagements, in a new SEI Series book from Addison-Wesley entitled Building Systems from Commercial Components. These methods and techniques are practical applications of software engineering that have been successfully applied and reapplied in the development of large, complex systems," says Seacord.
Contingency, Model Problems, and Evaluation
Building systems from commercial components requires a significantly different development process than custom development because of the uncertainty and risks of using commercial components. These risks often must be mitigated by simultaneously pursuing multiple design contingencies. While one design contingency may be considered the principal contingency (and therefore receive a greater share of development resources) other, alternate design approaches may be simultaneously pursued. The number and characteristics of these design alternatives vary with the characteristics of the project.
For example, a project for which the greatest risk is time to market may select components whose characteristics and interactions are well understood. Another project may choose to use newer components that are not as well understood to incorporate newer technologies.
Within each contingency, it is important to determine the feasibility of component interactions required to achieve the desired capabilities of the system. The authors of Building Systems from Commercial Components suggest the use of model problems—focused experiments that can be used to answer specific design questions. These model problems are intended to lead to a determination of design feasibility.
Systems can be built using any number of commercial components. For example, systems that do not include any commercial components are considered "custom built" and are outside the scope of the book. Systems can also be built around a single commercial component, such as SAP or other large enterprise resource planning (ERP) system.
In these cases, the design of the system often becomes an exercise in customizing the commercial component within the guidelines allowed by the product. The final possibility is that systems are built from an ensemble of components. This last case is the principle focus of Building Systems from Commercial Components.
Even when systems are constructed using multiple components, a typical practice is to evaluate each component in isolation. For example, a project may enumerate a list of components required to implement a system and then assign different teams to evaluate and select a product for each required component. While selecting "best-of-breed" components has obvious attractions, these components often prove incompatible when combined in an ensemble. Also, components have unanticipated interactions when combined in a single system. When building a system consisting of multiple components, component ensembles and not individual components must be evaluated to ensure the feasibility of the design approach.
The feasibility of the design approach can in turn be used to determine the feasibility of a design contingency.
These processes have been applied successfully in the development of a distributed image retrieval system (as documented in the SEI Series book) and in the development of various commercial and government systems since completion of the original case study. For example, the use of model problems in the Air Force logistics domain is documented in the SEI technical report Maintaining Transactional Context: A Model Problem.
Seacord is leading continuing SEI efforts to transition the practices described in Building Systems from Commercial Components into practice. The foremost transition vehicle is the SEI Series book itself, but additional products under development include an undergraduate software engineering course incorporating methods and techniques from the book.
The techniques described in the book are also being applied in the development of the knowledge-based automated component ensemble evaluation (K-BACEE) prototype at the SEI. K-BACEE includes a component repository and knowledge base of component integration rules. System integrators can use the tool by creating a manifest, which defines their systems requirements, the system context, and the architecture for the new system. The system then identifies ensembles of components that can be used to realize the manifest. K-BACEE automatically ranks the ensembles based on component compatibility using the integration rules knowledge base. While techniques from the book are being used in its development, K-BACEE is unique in that it also automates portions of the component search and evaluation processes prescribed by the book.