What Makes a Good Marketing Platform? Rules for Platformality

That Scott Brinker is such a devil.

Last month he goaded me into coming up with a framework for relating marketing technology to business strategy, which I'll present at the MarTech conference in August .  Today he wrote blog post about the latest entrants into the marketing platform derby, Abobe and IBM, which prompted a comment from me since I’ve been thinking about the need to define the features of a good platform system. Scott naturally shot back with some concrete suggestions, which has in turn led me to publish some additional thoughts and to begin considering a more detailed exploration of the topic. Now I’m going to feel guilty if I don’t cover the topic more fully – even though there are other, easier topics that I had meant to write about first.

Fine.

Here are my thoughts on this, folks. Lots of vendors have now taken to describing their systems as platforms – Oracle, Salesforce, IBM, Adobe, Marketo, Act-On, HubSpot, InfusionSoft and even CallidusCloud.  The only real requirements seems to be some sort of a marketplace – all loosely modeled on Salesforce.com’s AppExchange, which in turn I see as inspired on Apple’s App Store. But, to my mind, a real marketing platform needs more than just an app store and a published API. In particular, it needs API features that support the fundamental goal of a platform-based architecture, which is to allow third party apps to supplement the core functions of the underlying central platform.

This means something specific.  The role of the platform is to manage a central customer database so that all the apps work from a common core of information.  To do this, the APIs must allow access to that database in terms of reading, writing, and integrating customer data. The central platform facilitates coordination of customer treatments across channels, but things like predictive models and decision rules can be provided by third party apps so long as the results are stored in the database and embedded in recommendations that are accessible to other apps. Ironically, this means a platform doesn’t necessarily have to provide an API to expose other capabilities such as sending messages or building campaign flows, even though these are core functions of a marketing system.

On the other hand, the data management features need to be robust, for example in terms of providing access to full details of customer history and, indeed, in storing detailed history in the first place. Some of the systems that call themselves platforms place severe limits in those areas.  Similarly, the platform should allow easy access to large sets of customer records, not just to one record at a time. Again, this isn’t always available.

A meaningful description of platform requirements – which I’ve decided should be called “platformality” – would almost surely begin with a definition of use cases, from which the actual API requirements would flow. The requirements themselves need to be defined in specific enough terms that someone could actually judge them objectively; just saying “update customer records” is much too vague. There would also be other, non-functional requirements such as the API being published and perhaps extensible, “discoverability” of partners (Scott’s suggestion), an open and objective partner qualification process, and so on.

I’m guessing that vendors who have already spent time integrating with Salesforce.com and other established platforms have a very clear picture of what’s required to make a platform truly useful. Therefore I’d really want their input into the list of platformality requirements. Having that list would be in their interest, and even more in the interest of marketing system buyers who are asked to assess whether the various vendor platforms can really fill the role that a platform is supposed to play. Sadly, there’s no one in the industry with a strong enough vested interest to justify funding such a project. People like Scott and myself can push things along out of public-mindedness and sheer intellectual curiousity, but we all have day jobs that keep us more than busy.

Hence my initial instinct, proposed in comments on Scott’s blog, that we find a way to crowdsource creation of the platformality requirement list – drawing on the collective wisdom of app developers and users who have already felt the pain of trying to build apps on platforms that not fully suited to the task. I still think that’s the best approach although the details of how to make it happen are far from clear. Some sort of self-generating wiki might work.  Or a group effort at a conference might be more efficient and perhaps more fun as well.  Hackathon, anyone?

I’m wide open to suggestions and, better still, offers of concrete assistance. If the future of the industry is really marketing platforms, it’s worth some collective effort to provide a clear definition of a what a good platform looks like.

Addendum: on reflection, the way I would usually tackle a project like this is to interview all the platform vendors to find out what platform features are currently in their systems and then build a list that combines the results and adds whatever I think is needed but missing.  It's a big project but manageable.  Not something I have time for but perfect for a smart and somewhat technical summer intern if anybody has one they don't know what to do with.  Maybe we could present the results at MarTech; I would certainly be happy to publish them in this blog.  If anybody wants to volunteer, let me know.