A Pattern Emerges

Before you decide on a data model, you should know your business objective

By Raju Kocharekar

Considerable discussion in computer and information science revolves around building and manipulating "patterns" - those data representations and manipulative constructs or operations that change, mutate, or enhance data elements. In essence, the challenge of mapping the business problem at hand to the appropriate pattern (models or abstractions) is in fact a "pattern matching" problem.

Furthermore, although this pattern matching is a precondition for resolving many business issues, it's just as important to plan in advance the actions you take as a result of the match. Shifting the focus to these business objectives before choosing the appropriate models and usage not only makes pattern matching more effective, but is also a source of competitive advantage.

AN "IS 101" REFRESHER

Over the years, complex and sophisticated patterns have evolved, such as relational data models, Pascal's tree and network structures, Prolog rules, or objects with inheritance. You can compare patterns to see if they match in shape or form. For example, you can compare if one network diagram matches another with the same nodes and links or if rows in two relational tables have equal column values.

The issues then become what actions will enhance or change one or both patterns to bring them even closer to each another. You can convert the pattern created in one form to another that can produce the same result as the original. For example, you can represent relational data as facts in Prolog rules.

Of course, these transformations are not as efficient or elegant as the original patterns, but sometimes these transformations are necessary to exploit the strengths of both patterns. For example, the relational model, due to its pervasive use, remains a dominant pattern for persistent storage, regardless of the model you may need to solve the problem at hand. In other cases, developers often use their favorite pattern form on any problem.

You may say, "I already know this theory. How does it help me in practice?" Sometimes you need to step back and think about the basic nature of a problem. You may be spending too much energy in arguments over the particular pattern usage, while ignoring something that is more fundamental and has a greater effect: your business objective.

THE REAL WORLD

Many business problems involve determining the actions when and after two patterns are matched. One pattern may be a subset of the other or may be allowed to defer with the other within a certain tolerance level. Sound abstract? Let me give you a few examples.

Think about the core issue in CRM today: selling more products or services to customers based on their needs. For that to happen, you first need to match the pattern of your products and services to the pattern of your customers' needs. Everyone knows that focused marketing yields better ROI than broad marketing, provided the costs of the focused approach are low. The Internet and other computing and communication technologies let you automate not only the entire pattern matching process but also additional steps at "the edge" of the pattern matching, such as recommending additional services and products.

For example, Amazon.com's information system automatically suggests other books similar to the one you are purchasing, providing Amazon.com a competitive edge. Market economics says that transactions occur at the margin of what the buyer is willing to pay and the seller is willing to sell. Amazon.com illustrates that not only is finding this margin critical, but also completely or partially automating the sell, reducing its transaction costs. Through pattern matching, you can achieve competitive advantage by bringing the buyer's demand pattern closer to your product-and-services pattern, or the other way around.