The American Heritage® Dictionary of the English Language, Fourth Edition
Copyright © 2006 by Houghton Mifflin Company.
Published by Houghton Mifflin Company. All rights reserved.

Often during my consulting activities I ask people about what their “nirvana state” would be. That is, given today’s realities, what would be the ideal manifestation of something. The word nirvana is just unusual enough to get people to start thinking, and I know people do because it has entered the lexicon of people I work with.

I personally equate best practices with the nirvana state—they’re the best we could envision something being right now. The neat part about identifying the nirvana state is that you don’t have to (and don’t want to) think about where you’re at now, just what would be best.

For each major functional area in and around loyalty processing I identified what I thought the nirvana state was. As was noted earlier, this includes things like bonusing and partner interfacing, but also batch processing, system utilization, relationship management, and a number of other areas. Each generation represents increasing maturity and with increasing maturity comes increasing capabilities and generally reduced operating costs. Increasing maturity tends also to cost more to implement, so it is not always the case that you want/need to be at the highest maturity level for each functional area. Also, some functional areas are not valuable (or as valuable) in some verticals.

Based on my review and understanding of a large number loyalty systems, I was able also to identify common designs, or lack of designs, in all the areas. Given the common designs, it was fairly easy to identify which design was more mature. That is, to order the designs in terms of maturity. The maturity is not based on the technology used to implement a design (although certain technologies make it easier), but rather on the flexibility and/or capability provided by the design. For example, lets consider the generations of relationship management. That is, the maturity around being able to relate various entities within a program:

Level 1 — The relationship is implicit in the data record. For example, in a financial services program, the credit card number and the member’s loyalty earning account are “hard coded” in the same data record. A credit card represents a member and vice versa—no additional relationship is possible. This level makes it very difficult to implement, for example, a full-relationship banking program.

Level 2 — The relationship is explicit in the database. For example, in a financial services program, the credit card exists as a distinct entity, the member’s loyalty earning account exists as a distinct entity, and these are tied together by a relationship table. This allows multiple credit cards (or other unique identifiers) to be associated with a member’s loyalty earning account.

Level 3 — Various components of the modeled entities are decomposed, For example, an individual may now have multiple loyalty earning accounts, multiple addresses, multiple telephone numbers, and so on, which will be configured into the system upon deployment.

And so it goes, up to the nirvana state.

Not every implementation of every function is completely represented by the description of each level of maturity and not every implementation aligns precisely, but the model provides an excellent overall representations of the “maturity” of a loyalty system and with implication, how well or poorly it may perform and how costly or inexpensively it may be to operate.

The list of the initial reference architectures is up and over the next year or so we’ll flesh out the detail of each. If an area you would like covered is not on the list or you have a burning need to understand more about a particular area sooner rather than later, let me know and I’ll see what I can do.