Integrating Externally Supplied Software
|
Many canned solutions are available for online stores. It is hardly necessary to reinvent the wheel and design everything, ranging from the customer database to scalable Web farms, from scratch. Many times it is far more efficient to integrate externally supplied components or even complete solutions and customize them to the business's needs. However, our selection of third-party software should not be based on what we find first or is free on the Internet but instead should follow a process that ensures that we choose the software that best fits the application's needs. |
However, to make this chapter more readable and more fun to follow along with, we have greatly simplified many issues related to the online store, and we choose external software based exclusively on the fact that it is freely available to all readers. However, in this section we summarize steps that should be followed when you build applications using third-party software.
We must verify that the third-party software meets the demands of our project and is efficient in terms of technology and cost. We must also ensure that any functionality used in the end product works correctly. Typically, we make this verification by using a validation plan.
12.2.1 Validation of Externally Supplied Software Products
There are several reasons you might consider using third-party software in your product. For example, in Online Photo Shop we need a database for storing and recalling customer data. It would be an enormous task to write a database system. The option of writing our own database is not reasonable for the following reasons. First, we do not have the expertise in database system development, nor do we have the resources to develop such a system. Second, many commercial database systems are available that have been proven to work in various projects.
Thus, it is obviously cost-effective to evaluate, validate, and use an off-the-shelf database. Before using a third-party product, however, we need to make sure that it solves our problem and works as described, and that we have an integration plan. Therefore, we use a validation plan that includes steps described in the following sections.
Technology and Cost Analysis
In the first step, we define our requirements for the third-party product. Based on these requirements, we gather information about the commercially available tools. This is technical informationsuch as features, limitations, references from companies using the software, and the learning curve that is involvedbut also includes the cost of the software. Based on the collected information, we evaluate the technology against the requirements we have defined. The evaluation often includes prototyping of various scenarios to learn more about the features, usage, and limitations of the product.
Another point that needs to be considered is the cost-effectiveness of the product we are evaluating. For example, later in this chapter we describe our use of an Excel-based database instead of a full-blown database system such as Structured Query Language (SQL) Server. This decision was based on the fact that we did not want readers to go through the process of installing and setting up a full-blown database system. In addition, there was certainly the cost factor. Using Excel avoided the cost of a license for a database system such as Microsoft SQL Server.
The decision process should be visible to all team members. The developers should be able to voice concerns about using the technologies in question. At the end of the analysis process, a decision about using a third-party product is made.
Note that in many cases it will be necessary to allow time and budget to train the developers on the third-party product before you start verifying and integrating it.
Validation of External Software Packages
After the decision is made to use a specific third-party product, we need to validate its functionality. This is usually done via acceptance tests, whose goal is to prove that the product works as specified for its intended use.
From our experience, the tests should not include the integration of the third-party product. Rather, they should test only the third-party software, for several reasons. First, we want to validate only the functionality of the third-party product, not the integration into our product. Second, developing the tests separately will allow the developers to learn about the use of the third-party product without having to deal with implementation issues at the same time. Third, these tests will be run on future upgrades of the third-party product to ensure that the behavior does not change.
After the third-party product has been validated, the next step is to start integrating it into our software.
Integration of a Third-Party Product
The integration of the acquired software follows the same process steps we have used in developing our software. The requirements definition and analysis have been done, so the next step is to define the design that specifies the integration of the third-party software into our software.
A good practice is to use an interface layer to separate the third-party implementation from the implementation of the end product. By using an interface layer, we ensure better maintainability. For example, if we later want to use another third-party product or if the third-party product changes its interfaces, we can simply adapt the interface layer without changing the rest of the implementation.
We base the implementation on the defined design. The final step is to write the unit, integration, and system tests for the newly implemented functionality that uses the third-party product.