Will CDP Buyers Consider Private Clouds as On-Premise Deployment?

Most Customer Data Platforms are Software as a Service products, meaning they run on servers managed by the vendor. But some clients prefer to keep their data in-house. So before releasing the CDP Vendor Comparison report – now available here – I added a line for on-premises deployment.

This seemed like a perfect fit: a clear yes/no item that some buyers consider essential. But it turned out to raise several issues:

- on-premises vs on-premise. I originally used “on-premise”, which is how the term is typically rendered. One of the commenters noted this is a common error. A bit of research showed it’s been a topic of discussion but on-premise is now more widely used relating to computer systems.  On-premises actually sounds a bit pedantic to me, but I’m using it to avoid annoying people who care. (Interestingly, no one seems too concerned about whether to use the hyphen. I guess even grammar geeks pick their battles.)

- private clouds. Several vendors argued that on-premises is an old-fashioned concept that’s largely been replaced by private clouds as a solution for companies that want to retain direct control over their systems and data. This resonated: I recalled seeing this survey from 451 Research showing that conventional on-premises [they actually used “on-premise”] deployments now account for just one-quarter of enterprise applications and the share is shrinking.

Percentage of Applications by Venue:
24% Conventional (on-premise, non-cloud)
18% on-premise private cloud
15% hosted private cloud
14% public cloud
13% off-premise non-cloud
Source: 451 Research, Strategy Briefing: Success Factors for Managing Hybrid IT, 2017

My initial interpretation of this was the on-premises private clouds meet the same goals as conventional on-premises deployments, in the sense of giving the company’s IT department complete control. But in discussions with CDP vendors, it turned out that they weren’t necessarily differentiating between on-premises private clouds and off-premise private clouds, which might be running on private servers (think: Rackspace) or as “virtual private servers” on public clouds (think: Amazon Web Services). Clearly there are different degrees of control involved in each of these and companies that want an on-premises solution probably have their limits on how far they’ll go in the private cloud direction.

- public clouds. One vendor speculated that most remaining conventional deployments are old systems that can’t be migrated to the cloud. The implication was that buyers who could run a CDP in the cloud would gladly do this instead of insisting on an on-premises configuration. This survey from Denodo suggested otherwise: while it found that 77% of respondents were using a public cloud and 50% were using a virtual private cloud, it also found that 68% are NOT storing “sensitive data” in the public cloud. Presumably the customer data in a CDP qualifies as sensitive. I don't know whether the respondents would consider a “virtual private cloud” as part of the public cloud.  But I think it’s reasonable to assume that a considerable number of buyers reject external servers of any sort as an option for CDP deployment, and that “on-premises” (including on-premises private clouds) is a reasonable term to describe their preferred configuration.

When to Use a Proof of Concept in Marketing Software Selection -- And When Not

“I used to hate POCs (Proof of Concepts) but now I love them,” a Customer Data Platform vendor told me recently. “We do POCs all the time,” another said when I raised the possibility on behalf of a client.

Two comments could be a coincidence.  (Three make a Trend.)  But, as the first vendor indicated, POCs have traditionally been something vendors really disliked. So even the possibility that they’ve become more tolerable is worth exploring.

We should start by defining the term.  Proof of Concept is a demonstration that something is possible. In technology in general, the POC is usually an experimental system that performs a critical function that had not previously been achieved.  A similar definition applies to software development. In the context of marketing systems, though, a POC is usually not so much an experiment as a partial implementation of an existing product.  What's being proven is the system's ability to execute key functions on the buyer's own data and/or systems. The distinction is subtle but important because it puts the focus on meeting the client's needs.  

Of course, software buyers have always watched system demonstrations.  Savvy buyers have insisted that demonstrations execute scenarios based on their own business processes.  A carefully crafted set of scenarios can give a clear picture of how well a system does what the client wants.  Scenarios are especially instructive if the user can operate the system herself instead of just watching a salesperson.  What scenarios don’t illustrate is loading a buyer’s data into the system or the preparation needed to make that data usable. That’s where the POC comes in.

The cost of loading client data was the reason most vendors disliked POCs. Back in the day, it required detailed analysis of the source data and hand-tuning of the transformation processes to put the data into the vendor’s database.  Today this is much easier because source systems are usually more accessible and marketing systems – at least if they’re Customer Data Platforms – have features that make transformation and mapping much more efficient.

The ultimate example of easier data loads is the one-click connection between many marketing automation and CRM “platforms” and applications that are pre-integrated with those platforms. The simplicity is possible because the platforms and the apps are cloud-based, Software as a Service products.  This means there are no custom implementations or client-run systems to connect. Effortless connections let many vendors to offer free trials, since little or no vendor labor is involved in loading a client’s data. 

In fact, free trials are problematic precisely because so little work goes into setting them up. Some buyers are diligent about testing their free trial system and get real value from the experience. But many set up a free trial and then don't use it, or use it briefly without putting in the effort to learn how the system works.  This means that all but the simplest products don’t get a meaningful test and users often underestimate the value of a system because they haven’t learned what it can do.

POCs are not quite the same as free trials because they require more effort from the vendor to set up.  In return, most vendors will require a corresponding effort from the buyer to test the POC system.  On balance that’s a good thing since it ensures that both parties will learn from the project.

Should a POC be part of every vendor selection process? Not at all.  POCs answer some important questions, including how easily the vendor can load source data and what it’s like to use the system with your own data.  A POC makes sense when those are critical uncertainties.  But it’s also possible to answer some of those questions without a POC, based on reviews of system documentation, demonstrations, and scenarios. If a POC can’t add significant new information, it’s not worth the time and trouble.

Also remember that the POC loads only a subset of the buyer’s data. This means it won't show how the system handles other important tasks including  matching customer identities across systems, resolving conflicts between data from different sources, and aggregating data from multiple systems. Nor will working with sample data resolve questions about scalability, speed, and change management. The POC probably won’t include fine-tuning of data structures such as summary views and derived variables, even though these can greatly impact performance. Nor will it test advanced features related to data access by external systems.

Answering those sorts of questions requires a more extensive implementation.  This can be done with a pilot project or during initial phases of a production installation. Buyers with serious concerns about such requirements should insist on this sort of testing or negotiate contracts with performance guarantees to ensure they’re not stuck with an inadequate solution.

POCs have their downsides as well. They require time and effort from buyers, extend the purchasing process, and may limit how many systems are considered in depth.  They also favor systems that are easy to deploy and learn, even though such systems might lack the sophistication or depth of features that will ultimately be more important for success.

In short, POCs are not right for everyone. But it’s good to know they’re more available than before. Keep them in mind as an option when you have questions that a POC is equipped to answer.

SAS by the Sip: SAS Viya Offers Open APIs to Individual Services in the Cloud

SAS held its annual Global Forum conference this week, which marked the company’s 40th anniversary. One key to its long-lived success was an early decision to sell software by annual subscription, rather than the one-time perpetual license standard in the industry when SAS started. This provided a steady income stream and focused attention on customer satisfaction to ensure renewals.

In recent years, much of the software industry has adopted a subscription model under the label of “Software as a Service” (SaaS).  But the triumph of SAS’s pricing approach has been accompanied by new challenges to SAS’s business. Subscription pricing notwithstanding, SAS has largely sold its software for on-premise operation by its clients and required them to purchase a large stack of core technologies. This demanded a high initial investment but made expansion relatively easy – an approach that made sense when SAS's core analytical applications were pretty much essential to many clients. By contrast, the new SaaS vendors run software on their own servers and allow clients to access it remotely. This greatly reduces implementation effort and allows volume-based pricing, both of which lower entry costs to the client. The new SaaS software has also been relatively easy to integrate with other systems through open APIs and standard scripting languages such as Python. This also makes it easier to sell SaaS applications for narrow tasks rather than as part of a massive suite.

SAS’s growth and financial performance have been just fine despite the new competition, thanks to technical leadership in its core analytical products and pry-it-from-my-cold-dead-hands loyalty of its core customers. But the benefits of the new SaaS systems have made new sales harder, especially in peripheral markets such as marketing applications.

I’ve subjected you to this long-winded exposition because it provides context for SAS’s major announcement at its conference: a true SaaS version called SAS Viya.* This is a cloud-native system** that will reproduce existing SAS functionality and be compatible with the existing SAS 9 products. More exciting than the cloud deployment (which SAS had previously offered for SAS 9), Viya will be accessible through open APIs and scripting languages including Python, Java, and Lua, and – gasp – some components will be offered as on-demand services. In the SAS universe, this is truly revolutionary. It should open the door to new clients who were not likely to invest in a conventional SAS implementation.  Initial Viya apps will be available in third quarter 2016.

For marketers in particular, SAS also announced Customer Intelligence 360, a SaaS version of its primary marketing suite. Like Viya, this is a separate product from the existing Customer Intelligence 6 suite, which will continue to be offered. The initial release is not a function-for-function duplicate of CI 6 but a “digital marketing hub” that delivers real-time messages in digital channels (email, Web, and mobile apps). Key features include customer-level data collection via on-page scripts, and applications for marketing tasks such as sending an email, delivering in-app messages, or building Web a/b tests. These applications combine previously separate SAS functions such as model building, visual analytics, segmentation, and content creation. They include some nifty advanced features such as recommending when to run tests and automatically discovering which customer segments are most responsive to each test version. The initial CI 360 release includes two modules, Discover (mobile and Web reporting) and Engage (digital interactions including testings). They will eventually be followed by marketing resource management. CI 360 works on a very flexible customer data hub, although that’s a separate product owned by SAS’s Master Data Management group.

CI 360 uses much of the same technology as Viya, including REST APIs and HTML5 interface. It will officially run on Viya once Viya is released. Like Viya, it does not require clients to purchase the full SAS stack and will be priced on volume rather than a simple subscription. In the case of CI 360, fees will be based on the number of “customer equivalent records” and marketing messages. A minimum installation might start around $10,000 per month, considerably less than the current CI 6 product and competitive with other mid-market digital marketing solutions. The initial CI 360 modules are available now.

_______________________________________________________________________________________________
* The name is a little odd but it could have been SASaaS, so I guess we can be thankful for small mercies.

** Viya can run on the Amazon Web Services public cloud, SAS’s own cloud, or a company’s own private cloud.