Loading...
You are here:  Home  >  Data Blogs | Information From Enterprise Leaders  >  Current Article

Specify the Data Model and the Database Design

By   /  September 12, 2014  /  No Comments

by Michael Blaha

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.

About the author

Michael Blaha is a consultant and trainer who specializes in conceiving, architecting, modeling, designing and tuning databases. He has worked with dozens of organizations around the world. Blaha has authored seven U.S. patents, seven books many articles, and two video courses. His most recent publication is the Agile Data Warehouse Design video course from Infinite Skills. He received his doctorate from Washington University in St. Louis, and is an alumnus of GE Global Research in Schenectady, New York. You can find more information with his LinkedIn profile or at superdataguy.com.

You might also like...

To Get Value from Data, Organizations Should Also Focus on Data Flow

Read More →