Selection Model

Successful selection of a product for storing objects is the result of more than a mere hunch. The model shown here has been used successfully by my clients in a variety of industries. I have excerpted information about the model from my book, the Object Database Handbook: How to Select, Implement, and Use Object-Oriented Databases. If you find the model helpful, it is described in greater detail in the book.

This excerpt refers exclusively to object database products (ODBMSs) because, at the time it was written (1996), there was little experience with object-relational,  object-relational mapping products, or XML databases.  The concepts here apply equally to ODBMSs, object-relational mapping products, and XML database products.

Also check out the information on the Object Storage Fact Book.


Be sure to allow enough time for selection. I have spoken with and worked with people from many companies who are using ODBMSs. Evaluation usually takes between four and five months of elapsed time because of the learning curves the teams needed to go through.

Step 1 -- Understanding the Basics Step 2 -- Gaining a Deeper Understanding Step 3 -- Narrowing the Field Object Technology Understanding DBMS Technology Understanding Language Choice Understanding DBMS Features Understanding Feature Interaction Understanding Application Needs Critical Features Creating a Short List of Vendors Benchmarking Selection Selection Model

Selection Model

There are three main steps in the model. Understanding the basics of object and DBMS technology as well as choosing a programming language comprises the first step. The second step focuses on gaining a deeper understanding of ODBMS products and your application needs through the iterative process of studying product features, application needs, and the interaction of features and application needs. The final step involves narrowing the field by identifying a list of critical features to use in selecting a short list of vendors and finally, benchmarking/testing in order to identify the best choice for your application. Each step is described in greater detail below.


Step 1 — Understanding the Basics

The first step in this model, Understanding the Basics, is located at the far left side of the model; movement in the model flows from left to right. In this step, you must gain sufficient background understanding of object and DBMS technology to move knowledgeably into the selection process itself.

Object Technology Understanding

Everyone on the selection team must have a basic understanding of object technology. Because object technology is quite different from technology that preceded it, the understanding must be deeper than that which comes from reading a book or taking a course. This depth of understanding usually comes from experiencing it. Generally speaking, this technology must be used to get a sufficiently deep understanding of the impact it will have on the application.

DBMS Technology Understanding

A basic understanding of DBMS technology is important as well. Part I of the Object Database Handbook can provide such an overview. Understanding the purpose of a DBMS, which is to go beyond persistent languages to allow object data to be shared safely in a multi-user environment, is critical to the selection process.

Language Choice

In many situations, a programming language usually has been chosen early in the process. In fact, sometimes it is the first decision made, even though it shouldn’t be. This happens for a variety of reasons. More often than not, however, the object programming language used is the one the team leader favors. Ideally, the choice of language should be dictated by the application needs and those ODBMS features that will be identified in Step 2 that meet those needs. In reality, however, the language usually is chosen first.

Back to selection model.


Step 2 — Gaining a Deeper Understanding

The core of the selection stage can be found in Step 2, Gaining a Deeper Understanding, which falls in the center of the selection model. The greatest amount of time is spent in this step of the model because it is iterative, rather than linear, in nature. It simply takes time to iteratively line up application needs and ODBMS product features. To line up needs and product features, you can use checklists such as those in Part III of the Object Database Handbook. (Note: updated checklists are available as evaluation worksheets are available for purchase on this website.) Object modeling, prototyping, and starting to contact the ODBMS product vendors can also helpful.

This step is particularly iterative because as you consider how a specific feature may impact your application, you may find that your perception of your application needs may change. The deeper you go into understanding possible features, the more impact this new knowledge will have on how you view your application.

Understanding DBMS Features

All ODBMSs are not alike, not by a long shot. Although it seems as if everyone is constantly looking for the “best” ODBMS, the answer is that there is no one ODBMS that is the best. There is no one product that will work for every application, because each application requires a particular combination of features. In my experience, people are often totally unaware of all the possible features they could use in their application development and they make very uninformed choices. Making choices based on common knowledge or on the latest industry buzz is not informed decision-making. In Part III of the Object Database Handbook, 13 categories of checklists that highlight the broad list of possible features for consideration are included. These checklists provide the level of detail needed for an informed selection. The key to success is matching those possible features to your application needs.

As you will see in the next section, it is also critical to understand your application needs, the product features, and how both application needs and features can interact as well as how various features can interact. You must consider what this could mean to your application. This often creates whole new ways of looking at the business problem you are trying to address. I have seen clients revamp the entire application once developers truly understand how some ODBMS features can address their application.

Understanding Feature Interaction

Your application needs do not exist in a vacuum separate from the DBMS product features. The features will interact with each other in the application in ways that you may or may not be able to anticipate. The task is to fit the application to the product features and the product features to the application in such a way that the features work well together to provide the functionality needed for the application.

Two features taken together in a unique way in your application could spell disaster — or amazing success. Chapter 8 of the Object Database Handbook illustrates how the features of locking granularity, query processing and method execution can interact to give good or potentially abysmal performance. The use of class-level locking is another example of critical feature interaction. Often, class-level locking is very useful for applications that must dynamically change data definition; yet it can result in locking all the object instances of the class while the change is made. That could result in unacceptable delays depending on the application. On the other hand, the amount of programming code eliminated because of this feature could be immense. Thinking about the possible ramifications is essential at this step.

Understanding Application Needs

To start understanding your application needs, there are some basic questions to consider. They include:

  • What is the computing environment?
  • Will the data be distributed?
  • Will the distribution be local or over a larger geographic area?
  • How many users will work concurrently?
  • How will concurrent users access the data?
  • What types of schema changes will be likely?
  • How much data is likely to result from your most common queries?
  • Will you be using methods as part of your queries?
  • Will you be accessing existing data from existing non-object sources such as RDBMSs

Taking the time to research possible features and considering possible application matches will help you come to a much greater depth of understanding about your application and what features will meet those needs. In the next step of the selection process, you will determine which of those features are critical to your application and its success.

Once your feature needs start to stabilize into a useful subset, contact some of the ODBMS vendors. Have them explain in some detail how their system works for some items that are critical to your application. The result is a final set of checklists that is separated into critical and nice-to-have features. Of course, once you know which features are critical, you will need to know what features the products have. Contact the vendors to get each of their individual answers or get a copy of the Object Storage Fact Book, a publication that provides information on which features are provided by the vendors.

Back to selection model.


Step 3 — Narrowing the Field

When you have begun to understand DBMS features and how they interact, along with developing a depth of understanding about your application needs, you are ready to move to the final stage of the selection model where you narrow the field of possible products and prepare to make a choice.

The right side of the model features the final step, Narrowing the Field. After iterating sufficiently between your application needs and the DBMS product features to find all the application needs and the DBMS product features you could care about, you are nearly ready for this step. When you have considered the possible feature interaction among the DBMS product features you are considering, you are ready to determine your critical features.

Critical Features

There are some product features that are absolutely essential to your application — your critical features. If a product is missing even one of these features, you should not consider it. This list of critical features will radically reduce the number of products you are looking at. It’s important to keep in mind that these critical features will apply only to your current application. Future applications may have a completely different set of critical features. Every application is different. In my experience with clients, I have never seen exactly the same list of critical features.

Creating a Short List of Vendors

Once the critical features, those “do or die” features that any product you consider must have, are identified you can create a list of vendors whose products have these features.

If more than four vendors remain on the list, you are in the enviable position of using your next tier or nice-to-have features to identify the vendor products you will study in more depth. Once you have included these nice-to-have features, my experience is that no more than two or three products emerge and one of them is usually a clear favorite. Any product on this list has the features to do an adequate job for you. You might want to bring these finalists in for a final questioning based on the deep feature understanding you now have. And, you may want to ask them some questions about their business strategies, market segment, and financing. The ODBMS industry is a young one, and it is unlikely that all the current vendors will be in business some years from now. You should be comfortable with the company that makes the product on which you are going to depend.

Another way to gain further insights into the products and their use before making a final selection is to attend a vendor training course.

Benchmarking

After narrowing your choices for selection based on your critical features, the final step is benchmarking, which will help you determine if the top one or two products you are considering will meet your application performance requirements. Without it, you are assuming those performance requirements will be met and this can be dangerous. Benchmarking may very well point out areas of design concern that could be addressed by advanced work from the vendor’s consultants.

The companies that do their own detailed benchmarking take two to five person-months to develop and run the benchmark. Public benchmarks do not seem to be commonly considered. This makes sense because most public benchmarks are single user so they are not useful for comparing to nearly all database application. Also, public benchmarks rarely match the requirements of real-world applications.

Selection

Selection is, of course, the final step in the selection stage. If you have done your homework, your choice will be obvious to everyone on the team. There should be no doubts. If you do not have this agreement, you probably took a shortcut somewhere along the line. Now is the time to search for what you may have overlooked, not push a decision.

Choosing a vendor and product is seldom a simple project for most companies. On average, two to four products are considered. In many cases internal benchmarks and testing are used to make a final cut or to verify that the expected performance can be achieved.

Back to selection model.