Do Not Outsource the Data Model and the DB Design

The 360-degree Sydney Harbour control tower of as seen from the Observatory Hill. From the looks of it, it is no longer in operation.

picture by Theen Moy via Flickr

Many organizations today outsource software development. You, the customer, specify your requirements and the vendor is supposed to build software that meets your requirements. But requirements are not sufficient as a specification. With this common scenario, you have no control over the quality of the software being built. Furthermore, you have no visibility into the software’s structure. You can improve this situation by adding a data model and a database design to your specifications.

What is Outsourcing?

Outsourcing is the delegation of internal work to an external party. There are many forms of outsourcing (outsourcing management, outsourcing manufacturing, etc.), but our focus here is on the outsourcing of software development.

There are many advantages to outsourcing software development. It lets you limit the size of your staff and use a vendor to augment your capabilities. Vendors often have the quantity of staff and mix of skills to build applications faster at lower cost. Outsourcing lets you focus on your core competencies and hand off development details.

Problems with Outsourcing

But there are also disadvantages to outsourcing development. One problem is lack of control. Most organizations that I’ve seen specify the requirements and let the vendor determine the rest. In my opinion, that is too much trust and too much latitude. By specifying the data model and database design, a customer can exercise more control over the software being built.

Think about a three-tier architecture. The front end, the user interface, is the least critical part of an application and the easiest to fix if flawed. The application logic is more important in that it supports business process and business rules. The most critical aspect is the data. Data is long lived – errors persist and are difficult to correct. So it only makes sense that you should keep control over the data.

Another problem is the risk of blindly depending on a vendor. The vendor may meet the current requirements but that is not good enough. Any useful application must be maintainable and able to evolve to meet future requirements. If you specify the data model and database design, you’ll better understand the software. You’ll increase the odds that the software will have a long life.

The problems become more acute when software development is not only outsourced, but also offshored. With offshoring there is the additional risk of miscommunication due to distance, foreign culture, and language.

The Solution

The solution is to prepare your own data model. Do not rely on the vendor for this task. The model is the crown jewel of your intellectual thought. The model governs how the application fits in to your business and coordinates with your other applications.

You should also prepare the database design. Some developers, especially programmers, do not know how to design a database, so you want to ensure that it is done right. The database provides the foundation for an application; a bad database design ruins an application. If your staff is skilled, they can quickly design the database by using tools.

By taking ownership of the data model and database design, you will be more likely to be able to understand the software, maintain it, and evolve it for the long term. The data model and the database design take only a fraction of the total development effort.

In contrast, send the details of development out off house. Relinquish the tedious and time-consuming activities of programming and user-interface construction to the vendor.

Suggestions

Make sure that the vendor actually uses your model and database design. If they want to deviate from these specifications, make them go through a formal process where you agree to the revisions.

Ideally, you should involve vendor in the development of the data model and database design. It’s good to hear their point of view. Early involvement helps the vendor better understand the requirements and the modeling rationale.

We tell vendors that we welcome their comments and suggestions. But they cannot unilaterally make changes without our knowledge and consent.

You can enforce the use of the data model and database design with contract language and project reviews.

Conclusion

The data model and database design are not artifacts to be left to the whims of a vendor. Rather they are critical pieces of thought that you should perform and specify to the vendor to increase project control and reduce risk.

Leave a Reply

Your email address will not be published. Required fields are marked *