Editor’s note: The build versus buy decision is visited often by loyalty program sponsors. Jim Kuschill is the architect of one of the original – and still market leading – platforms in the industry. This is the Second in a several part series about loyalty software and it will be sure to fascinate loyalty junkies whether working for software vendors or internal IT teams.

In the first installment of this series, we saw that it was possible to decompose loyalty software systems into 23 separate major functional areas – 16 modules and 7 shared services.

In this installment we’ll take a look at how shared services impact modules and whether a developmental lineage can reasonably be established across a wide variety of loyalty software systems.

In general terms, modules interact with users while the shared services support the modules and interact with the operating environment (e.g. the database system). As a consequence, the capabilities provided by (and observable in) a system are largely dependent on the modules. But, how (well) those capabilities are provided is often highly dependant on the shared services. In particular, if a shared service does not exist, is poorly implemented, or minimally implemented, then the capabilities, reliability, or some other aspect of the system will be compromised.

Because shared services can affect large portions of a system, some correlation always exists between overall system flexibility and efficiency and the depth/quality of the shared services. However, if there was little correlation between shared services implementations, we’re again in a position where it would be difficult to show how investments would yield more cost-effective systems.

At this point, it was time to revisit each of the loyalty systems and identify whether they implemented a module or shared service, and if so, how. As this work progressed, it was possible to see patterns across systems that once appeared to have very little in common. Not only were there patterns, but there were also common approaches to the implementation of modules and services. Certainly not with 100% correlation, but with fundamentally similar approaches.

Upon a review of the results it also seemed as if there were 23 timelines, each illustrative of the lineage of a separate technology. In essence, each of the 23 timelines contained a version 1, a version 2, and so on. Each of the versions essentially indicated how “mature” the functionality of a module or shared service was.

This seemed a little too good to be true, so further research was done on the history of some of the systems. To do this, I spoke with developers and others who had insight into the modules and services of previous versions with any eye toward whether those versions fit the patterns identified. There was not 100% correlation, but the patterns were unmistakable, with well correlated progressions in every area.

Once the maturity levels were identified, it was then possible to consider the associated operational characteristics to understand the benefits, problems, and most importantly, the costs of operation for being at a specific maturity level. It was also possible to anticipate what more advanced maturity levels would look like, functionally and operationally, even if they had not yet been seen in a deployed system. Finally, it was possible to estimate the cost of enhancing a system from one maturity level to the next, a critical component of any ROI analysis.

Even with all of this, it was not yet possible to evaluate whether a particular loyalty system was inefficient at handling the job it was tasked to do. For that, it was necessary to understand the demands on the system, which requires us to consider such things as the vertical market, membership size, and program complexity.

By observation is was clear that each vertical market had a fairly distinctive pattern of needs and these tended to correlate with membership size and program age. This provided a baseline read but analysis of the following elements was especially useful:

• Reviewing the current software to identify its level of maturity
• Survey the loyalty program’s recent operating history for insight into the functions being performed and the associated costs
• Scan the strategic plan for the loyalty program (ideally a 2 or 3 year vision) to understand what maturity level of software is required to reliably and cost effectively implement the vision

The form of analysis yields a reasonably quantitative illustration of how well a loyalty system aligns with marketing realities and also where any gaps exist relative to the future marketing vision. Comparison of the gaps against the frequency of the needs and the cost of enhancement provides good insight into the areas into which investments should be made.

In Part III of this series, we’ll look at why a loyalty software maturity model is a necessary step and explain why being able to configure 95% of a solution is still not enough.

Stay tuned.

Editor’s note: The build versus buy decision is visited often by loyalty program sponsors.  Formal market studies by COLLOQUY and others have arrived at the conclusion that “internal IT” might be the market share leader among loyalty software providers.  Jim Kuschill is the architect of one of the original – and still market leading – platforms in the industry. He has been asked every question about loyalty software that could be asked and is so well versed that, if you bore him, he’ll go ahead and answer the questions you forgot to ask! This is the first in a several part series about loyalty software and it will be sure to fascinate loyalty junkies whether working for software vendors or internal IT teams.

I’ve spent a lot of time over the years studying loyalty system technology. This includes the consumer touch points such as the web site and IVR, the data touch points that drive accruals and perform fulfillment, and everything between.

At first, second, and third blush, each of the systems looked very different, the only thing in common seeming to be that they all cost too much to operate and never really seemed able to (easily) do what marketing wanted. As a result, I started to wonder if there really weren’t patterns, whether it would be possible to identify and make some sense of them, and if there might not be substantial benefits in teasing them out. In particular, I wanted to see if there might be a way to understand how loyalty systems “grew up,” to be able to predict operating capabilities and costs, and then to leverage this knowledge into more flexible and efficient systems, but most of all, into more cost-effective systems.

An interesting truism relative to loyalty processing software is that they seem alluringly simple to build. After all, tracking points is merely a matter of addition and subtraction and tracking names and addresses is pretty basic functionality as well.  I would go so far as to say that if you sat down with 100 bright software analysts or software engineers that had not previously worked with loyalty systems, fully 90% of them would confirm they could build just what you needed!

While this isn’t a good thing for loyalty software vendors and ultimately it isn’t a good thing for those that operate programs, it turned out to be a really good thing for my analysis. Partly because so many different systems existed and partly because it was easy to see that the vast majority of loyalty software systems started with pretty much the same kernel – typically a little member management, a little points accrual, and a little redemption support.

Then they grew.

And new parts were added.

And they grew some more.

And then parts had to be rewritten.

And those parts started to grow.

This approach to development appears haphazard, but it is actually driven by market forces that influence the needs of the marketer. This in turn drives the software requirements and ultimately the form of the software. Given that market requirements, particularly in the same vertical, will in large part be similar, it’s not unreasonable to assume that the solutions within a vertical will exhibit a good deal of consistency as well. That is, every loyalty system within a vertical should provide similar core functions, albeit perhaps in different ways and to a different degree.

A subsequent comparison between several systems within a number of different verticals confirmed that functionality wasn’t highly variable, but it did not immediately yield insights into the operational cost drivers, much less how such costs might be reduced. This was somewhat of a disappointment, but should not have been unexpected. To some extent I had fallen into the “loyalty systems are simple” trap by trying to categorize at too high a level.

At this point, some functional decomposition was in order and so I took inventory of the major functions performed by loyalty systems. For example, point expiration is a common major function. Similarly, and much more complex, redemption is an obvious “must-have” function. People often refer to these as modules, that is, the points expiration module, the redemption module, and so on.

While modules are readily identifiable, loyalty (and other) systems generally include a large amount of supporting code. In terms of software design, this code is often identified as “shared services” or “service modules”, because the functions are needed (shared) by a number of different modules. For example, handling batch files, logging of data changes, and so on, are typical of shared services.

After a re-review of the systems with an eye towards functional decomposition, 16 major modules and 7 major shared services were identified. Of the 16 modules, 4 were large enough that they could have undergone a similar decomposition process, but rather than complicate the process further, this was simply noted, with an expectation that any findings may not be quite as applicable for these modules.

Now it seemed that some progress was being made as it was possible to break down the formerly monolithic systems into a manageable number of readily identifiable parts. The next interesting question was whether there was a discernable “lineage” associated with the parts. Without a lineage, without correlation, it would be much more difficult to show what type of investments would yield more cost-effective systems.

In our next installment we’ll review each loyalty system against the identified modules and shared services and see if  clear relationships exist between investment in specific sets of modules and more cost-effective loyalty marketing systems.