StrikeIron Blog

Isn't "More Data" Really at the Heart of Social CRM?

I was at the SugarCRM event a couple of weeks ago where one of the hot topics, including the theme of one of the keynotes, was "Social CRM" and its emergence as one of the new cornerstones of successful CRM approaches, or "SCRM" so to speak. It occurred to me while listening that Social CRM is the latest in a long line of industry terms that everyone is talking about, but no one can quite put a finger on exactly what it is. Or, perhaps better said, it has many customized meanings to serve the purposes of many different people.

For example, a lot of what you will hear will center around the concept of "customers controlling the conversation", but a lot of this sounds like a variation of the personalized marketing and one-to-one conversations with customers that have been discussed for years and years. Yes, fan pages and Tweets give us more customer perspectives and insight than perhaps what we have had in the past, but these could also be considered the evolution of newsgroups and forums, now with a much broader audience, that smart companies have been using for years and years to engage with customers, be a channel for ideas, and better understand what they are thinking.

There are also some new products emerging in the category such as Oracle's "Social CRM" product that enables an organization to "derive business value through contextual conversations". But hopefully to most organizations, engaging conversations with customers is not a new concept. Perhaps this product helps better capture and analyze these conversations, but this still seems to be a small subset of the entire category being referred to as Social CRM.

One of the features touted as part of Salesforce.com's Chatter product, a set of features announced but not yet available, is the ability to provide internal updates to your colleagues (a la Twitter) as to what you are doing at any point in time, such as "talking to an important customer", "in the break room", "at a conference", etc.., and while this is only a small part of what Chatter portends to be, I think these internal status updates will have a hard time catching on. Most of us barely have the time to keep up with the daily barrage of emails we receive, and would be unwelcoming of new information streams, most of which will likely be noise. Kudos however to Salesforce for trying to create some business value from the rise of social networking, and given their track record, they are likely to find an avenue through which Chatter can be effective.

Other CRM products will certainly continue to find ways to pull Twitter, LinkedIn, Facebook, Google Buzz, and other social network data into various CRM platforms, enabling that data to not only be analyzed in a business intelligence sense, but also to be at the disposal of a sales rep prior to an engagement with a customer or a prospective customer. While unsettling to some, it will undoubtedly help some reps to be more effective in their work, depending on the products and services they are pitching.

It could also refer to the mining, trend-seeking, and subsequent quick response to Tweets, Facebook "Likes", and other social network stream data that goes far beyond CRM. However, this can be a difficult exercise as some brands can receive thousands and thousands of Tweets per day, calling the scalability of monitoring and responding to these Tweets into question. Trying to be responsive in real-time to an endless stream of Tweets will likely be a time-consuming and costly exercise, although clearly one can see how there might be benefits from doing so. But this of course isn't for everyone.

There are companies such as Rapleaf providing all kinds of email address-based data around social network activity, number of friends, number of networks, etc. that provide for a variety of use cases. For example, a financial institution might be more likely to extend credit to somebody that has hundreds of "friends" on Facebook if they deem that kind of person is less of a credit risk. I don't know if there is any truth to that, but it certainly seems like a plausible approach if long term credit data proves this out.

And of course a more cynical view might be that the term Social CRM has been conjured as a marketer's buzz phrase enabling the selling of more CRM product by latching on to the social networking craze.

So while Social CRM might be all of these things, some of these things, or none of these things, depending on who you ask, one thing is certainly clear. The rise of social networks has created not only a new paradigm of Web communication, but also represents a vast amount of new data that combined with other data sources and used properly, enables us to have more effective and relevant communication with customers and prospective customers, and that can't be a bad thing.

However, that has been true in the past, is true now, and will always be true in the future, whatever the name-du-jour happens to be.

Using Address Verification to Obtain Latitude and Longitude Coordinates

StrikeIron provides an address verification Web service that utilizes data from the USPS (United States Postal Service) to ensure that addresses are not only standardized correctly, but they do indeed physically exist according to the post office (they can deliver mail to it). We are continually updating this massive data store of USPS data within our data center so our customers don't have to deal with the complexity of ongoing data updating and maintenance to ensure the greatest possible accuracy of address data (as well as the associated software, hardware, and human costs that will be experienced when internally managing address reference data for an organization). 

Using the most recent USPS data is necessary (new housing and business construction creates new reference data to be used every day) when integrating address verification into Web forms, e-commerce processes, managing customer data, or any other place where address data is collected and the accuracy of that data is important. Simply by integrating our Web service, usually with just a single line of PHP, C#, Java, or any language that can invoke a Web service (can be auto-installed with Salesforce.com), inaccurate or non-existent address data becomes a thing of the past.

Not only are our customers saving postage costs on undeliverable addresses (the USPS estimates at least $2 billion USD is spent on postage annually for undeliverable mail), but also the cost of wasted print and marketing materials. And even that doesn't include missed sales and revenue opportunities and poor customer service as a result of mis-shipped products or not-received printed communications, the hard-to-measure costs of which can very well be several times higher than postage and materials.

But with all of that address data goodness the Web service provides, another primary reason customers use our address verification API is because of the latitude and longitude coordinates that can be obtained along with the validation of an address (for a complete list of data elements returned by our US Address Verification product, many of which even some of our current customers don't realize they have access to, click here). There are some obvious use cases for this kind of geocode data such as plotting customers and prospects on a map, but we have a long list of other use cases such as calculating distances between addresses from a certain business, legal uses of address proximity (many law firms use this service), proximity to certain types of equipment, geo-related business intelligence, product distribution maps, satellite-related navigation, nearest store locators, assigning appropriate representatives in call center scenarios, and many more.

One thing to understand before utilizing geocodes, as there are several different ways to obtain them via the Web, is the level of granularity of a given geocode and whether or not it suits your purposes. For example, zip code centroid or block level geocodes might be useful for finding the nearest pizza shop, but at least rooftop coordinates for residential properties are necessary for calculating the distance of a sex offender from a school. And even a finer granularity still is needed to find the exact location of buried underground equipment. Educate yourself in geocode granularity before putting them to work as part of any business process.

The use of latitude, longitude and other geocode data is becoming more and more prevalent, especially with the more sophisticated mapping and navigational technology available these days. When it is so easy and cost-effective to put to use, and in the case of StrikeIron completely platform-independent because of our use of SOAP and REST XML-based API's, any businesses or organizations looking to capitalize on these technologies can now do so with a great deal less complexity than ever before.

Salesforce Acquisition of Jigsaw Shows Continued Importance of Data in CRM and Beyond

The Salesforce.com acquisition of Jigsaw this week underscores the advantage data can provide an application, making it much more useful and the benefits greater. The $142 million dollar deal (and possibly more depending on performance) marks the first time a CRM company has gotten into the on-demand data business.

Jigsaw provides a database of businesses and key contacts that has been compiled using crowd-sourcing, an approach similar to what Wikipedia employees for its encyclopedic content. Users provide contact data they already have in something like a "contact data exchange" in order to get the contact information they would like to have (and of course have the option to buy it outright for $5/contact).

Clearly Salesforce sees this as both a competitive advantage (no other CRM provider has the ability to provide contact and lead data directly into a company record except via third-party add-ins), and also an increasing revenue opportunity going forward given the expanding market for data-as-a-service.

This data-advantage trend is not limited to SAAS CRM applications. For example, one of the reasons Google voice search (available for the iPhone, Android, and as of earlier this month the Blackberry) performs so well is because it utilizes Google's own historical search data to determine what people are likely to look for when words sound similar or are not entirely clear. For example, it is more likely to defer to the name of a restaurant when there are ambiguous results because of Google's own search history data ("pizza" is more likely than "Pisa", except perhaps in central Italy). This data-driven fault-tolerant voice search method is a powerful use of proprietary data and a capability that other vocal search technology doesn't have. Again, it's data that gives them the edge.

At StrikeIron, we have seen hundreds if not thousands of use cases where multiple types of timely data delivered on demand via our platform has greatly increased the value of e-commerce, marketing, or call center applications.

There are many, many categories of data available for on-demand integration into applications, not just business contact data and search term propensity. So as we move forward, I think we will see more and more the importance of data, especially proprietary data, in Web applications (both business and consumer) because of the advantages it can provide. The trick of course will be how to get it.

Can the Cloud Help the iPad (and Other Tablet PCs) Succeed this Time Around?

Tablet and other keyboard-less personal computing devices are nothing new, and for the most part they have been cloaked in failure over the years.

It started back in the 80's with things like Pen Computing. Apple's Newton was one of the first to realize the shortcomings of the then-current state of handwriting recognition as it disappeared into the device heap of history. The original IBM ThinkPad prototypes (the brand is now part of Lenovo) were actually keyboard-less tablets. More variations of the concept have come and gone, and though some Tablet PCs found moderate success, for the most part they have produced nothing but top line yawns.

So with this long line of disappointment, what dynamics could be different that could cause this approach to succeed now?

One indicator is the success of the Amazon Kindle. While Amazon has not officially released sales numbers, CEO Jeff Bezos has said that unit sales are in the millions. That's a pretty quick start, and one of the reasons for this early success is the Amazon online book catalog which clearly has contributed to these sales numbers.

So one thing that is definitely different now versus the past is the presence of a large catalog like Amazon.com, iTunes, or the AppStore to drive unit sales. That of course Apple has. The success of the Kindle and its attractive instant digital distribution model, and also the ecosystem that already exists around iPhone applications today will no doubt help drive iPad sales and success.

Another important driver is globalization. These kinds of computing devices can eliminate the need for country-specific keyboards, so that is attractive to many as well.

But I think that one of the biggest drivers of the iPad will be the Cloud. Going forward, much of the computing processing that will occur will be on Cloud infrastructure rather than the client itself. As a result, the smaller, sleeker "slate" design is not only ideal, it actually makes more functional sense. This will also help keep the unit price lower without sacrificing speed and power (this trade off has plagued tablets in the past), since less physical processing in the unit will be required.

As a Cloud client, the iPad can leverage a broad range of business applications, not just rich media consumer applications, and of course without the frustration of small mobile device screens.There is no reason why a lot of the top SAAS applications like Salesforce, Success Factors, Netsuite, and others won't have iPad clients available with the corresponding richer user experiences, especially ideal for employees on the go.

Business Intelligence applications will be able to have richer charts and graphs in a computing device that is much easier to wield (who else is tired of hauling the laptop around airports and trying to stuff them under airplane seats with no leg room?) Advanced, remote application monitoring for I.T. staff will surely be a big driver of these devices as well, as much more can be shown on an iPad versus mobile devices, and much more can be accomplished quickly if necessary to solve an I.T. crisis.

In other words, the iPad can become a doorway to the emerging Cloud and the massive amounts of computing power and data found within it, and perhaps is even better suited than PCs, laptops and mobile devices for just that purpose.

If this plays out, one thing I won't miss is large rooms abuzz with the sound of clicking keyboards. But I think the Cloud is ultimately a great friend to the iPad, and will be the real reason the iPad succeeds in the long run.

The Future of MySQL Now That it Belongs to Oracle?

O'Reilly's 2010 MySQL event is wrapping up this week. One of the big questions on everybody's mind both before, during, and after the show is now after the acquisition of Sun, where will Oracle take the MySQL technology and its current installed base?

The common perception will be that Oracle has a disincentive to make MySQL available for free when they are selling their own commercial database. After all, post acquisition of Sun, Oracle has all but dismantled Sun's Cloud offerings that would otherwise be now competing with Amazon's EC2 and S3, Rackspace, Microsoft's Azure, and others. I was actually very excited about Sun's emerging Cloud offerings prior to the acquisition, but now it's a victim, like so many promising technologies before it, of software industry M&A strategy. After all, shouldn't we assume Oracle did this deal to make a lot more money? One thing is certain, Oracle will do what is best for Oracle.

For example, they could keep MySQL around and position it as a lightweight (which it's not in my opinion) free version with an upsell path to the Oracle 11g (and beyond) DBMS. This is already starting to happen. This could even result in some crippling of MySQL. Or more likely, they will prevent the inclusion of new features that would have otherwise been a part of MySQL were it charting its own course.

But nothing is likely to happen fast. MySQL is so heavily used by so many Websites and Web applications today. It is a mainstay of the LAMP stack and its variations, and has a tremendous ecosystem built up around it. Facebook for example runs on thousands of MySQL database servers. We use it for some things here at StrikeIron with our subscription-based data-as-a-service collection of Web services APIs. The list of heavy duty commercial Websites that use MySQL is staggering. As a result, it will be difficult to replace for some time to come. This includes both Oracle with its own database market business strategy, and any other emerging open-source (or otherwise) database platform hoping to become the future pervasive grassroots choice. An example of a non-Oracle contender would be Drizzle, a forked version of the MySQL code base that is touted as a slimmer (meaning stripped down), faster version aimed at the emerging Cloud Computing space. It could really have legs.

Oracle's chief corporate architect Edward Screven keynoted the event and discussed how MySQL was an important part of Oracle's technology stack, and that integration and not database engines was still the largest opportunity Oracle had in front of it. As a result he stated that they are going to invest heavily in MySQL as it is an important part of their forward-looking plans. He also suggested that the MySQL platform also provides more of an opportunity for other Oracle database tools, such as performance monitoring tools, to be used in conjunction with it. This is certainly true.

To demonstrate Oracle's commitment, the version 5.5 beta of MySQL was also released this week. One place where Oracle has its signature on the beta release now is with the storage engine. InnoDB, technology acquired by Oracle several years ago, will now become the default storage engine for MySQL, replacing the MyISAM technology. The storage engine is the core underlying software component of a database platform that performs all create, retrieve/select, update, and delete statements with the data tables of a database.

Despite Oracle's encouraging words, I think the question for most will be whether or not this is truly a MySQL-centric long-term plan, or whether it is instead the traditional embrace-then-replace strategy that is often an ugly part (and a key strategy to some) of the software industry that usually serves the big guys. Time will tell.

One thing conspicuously absent from the O'Reilly 2010 MySQL show was promotion for a 2011 MySQL show. Usually, the next year's event is promoted quite heavily to attendees of the current show. What does that tell us?

The good news is, whatever voids are created will provide oceans of opportunity for those who seize upon it. It always does.

Gartner MDM Summit This Week - What Will Be New?

The Gartner Master Data Management Summit is this week in Las Vegas.

If you are not familiar with Master Data Management, typically referred to as MDM, it consists of processes and tools to ensure customer data (or any type of cross-organizational data) is consistent, normalized, and accurate enterprise-wide. These solutions and processes address issues such as multiple versions of the same data operationally present throughout an organization (sometimes referred to as a "single view"). If unaddressed, this can lead to problems such as analytical errors, poor external communication, and other data quality-related issues, all of which can seriously affect the bottom line.

The Summit will certainly showcase some great holistic case studies from industries like Financial Services, Healthcare, Manufacturing, and Government. For attendees there will be access to all of the most comprehensive MDM research available today as collected by Gartner's analysts and clients.

Many of the traditional vendors will be present, such as Oracle, SAP, IBM, etc. But I hope there is also some focus given to some of the exciting possibilities the Cloud provides for the future of MDM. If not already here, I'm sure MDM-as-a-Service (MDMAAS) is right around the corner.

In fact, it is already here to an extent. In addition to all of the large vendor and expensive enterprise software solutions that can take months and sometimes even years to implement, there are also an emerging set of product offerings that allow MDM to be practiced in pay-as-you-go functional scenarios, addressing issues one at a time such as poor address data or outdated email addresses of customers.

Of course, tools and products alone are never enough for an organization to practice solid MDM, but these types of point offerings enable more and more capabilities to be implemented as measurable success is obtained rather than paying heavy price tags before any results are achieved. This helps to eliminate big bets organizations sometimes face when trying to implement good MDM practices, and enable departmental solutions to exist as well to solve immediate problems, rather than waiting for I.T. to roll out complete solutions. Also, MDM is not only important for big companies. High quality, normalized, efficient data can be just as critical for small or startup companies, if not even more important since margins of error tend to be smaller for these kinds of companies.

So I am hoping for some new thinking this year, and though I will be unable to attend this event (I will be at some others), I will follow online as much as possible.

The Three Layers of the Cloud

Our industry remains in continual disagreement about what the "Cloud" actually is as we continue our early progression through the "Era of Cloud Computing". This amorphous term "Cloud" still unfortunately has a great deal of variation in terms of definition. So while there may never be a Supreme Court of the Cloud to rule on its exact definition, a general consensus is likely to emerge over time. Of course, vendors, customers, journalists, and academics will squabble as to its actual meaning, each with their own bias, but sooner or later, the jumble of explanations will ultimately evolve into a general agreement of what the Cloud is, even if it's in the history books of tomorrow rather than the business corridors of today. It's the forward marching course of nature to be as such.

To demonstrate the issue, on one end of the definition spectrum, the term has been expanded by many to include just about everything on the Web, or better yet, a new word to be used in place of "Web", obsoleting the term, but with nothing more to offer than an evolution of functionality. The entire Internet in this case seems to be the Cloud. You will notice in some discussions of the Cloud where the term "Web" or "Internet" is never used. This is simply too broad to be useful.

On the other end, purist types regard only virtualized servers and storage as the Cloud, and that's where the term concludes, consisting only of virtual server images and Web-scale SQL-like mechanisms. Yet I believe that is too narrow of a definition and sells the concept and its benefits far too short.

So currently, and I reserve right to change my mind in the future here in the infancy of Cloud thinking, is that I believe and think of the Cloud as a subset of the Web that can be described in three major layers.

First, at the core or inner layer of the Cloud, is the resource virtualization layer. This is the actual Cloud infrastructure, where servers are rented by the minute and storage is rented by the byte-used-per-day. These resources can be immediately expanded as usage requirements dictate, keeping costs aligned with need. It is still an abstraction from the underlying physical hardware whatever that happens to be, the software that manages that hardware, and the tools and interfaces that allow these virtual resources to be managed. The key point is that in and of itself it is all entirely useless. In other words, it's just some servers and some persistent memory, but in a logical sense rather than physical, and theoretically infinite to suit one's needs. However, applications still have to be built on it and run within it be of value to anyone other than the Cloud infrastructure vendor. Some examples of this would be Amazon's EC2 and S3, Opsource's Cloud, Rackspace, and on and on.

Second is the Cloud component layer. These are actually the building blocks of the Cloud, consisting of the APIs, Web services, data sources, usage tracking, billing components, feeds, files, and any element that can be shared and re-used in multi-tenant environments. This is where StrikeIron lives by the way, the company I work for. These are the individual nodes from which the concept of a hyper-connected universal data highway has been envisioned, where applications operate completely out in Cyberspace using celestial CPU cycles. These components are the actual doorways to the information to which the Cloud begins to become useful. If you think of one who builds on the Cloud as an artist, then this layer would be the palette of colors used to create the masterpiece, with the first infrastructure layer serving as the canvas. It is from this brush and palette of components, all existing and accessible out on the Internet, from which the third layer of the Cloud emerges.

And finally, this third layer is the application layer of the Cloud. This is where it all comes together, or the masterpiece exists so to speak. The colors (second layer components) converge on the canvas to provide meaning and therefore usefulness. These are all of the applications that are emerging that in many situations are much better suited for the Cloud rather than behind the firewall or on the desktop where they have traditionally lived. They include CRM applications like Salesforce.com (and I put Force.com here as well - if you want to know why, send me an email to bob.brauer@strikeiron.com) or Netsuite, HR applications like Success Factors, accounting applications such as IntAcct, and even development environments including Google's AppEngine as well as the applications deployed on the AppEngine. They are both built upon and enhanced by the first two layers of the Cloud, and contain the user interfaces from which a user accesses and gains benefit from the Cloud. Because of the nature of these applications and where the value is realized, upgrades are automatic, maintenance is greatly minimized, failure is dramatically reduced, and cost ultimately is more appropriate considering one's needs. These to date have not typically been new applications, but rather the old ones in a new paradigm that is enabling information technology and its uses to evolve more quickly.

And these are the three layers that constitute, in my humble opinion, the Cloud. This is how I think of it anyway.

Note what I haven't included: email (although email applications can run from the Cloud, such as Google's Gmail), consumer applications such as buying books or plane tickets, news sites, informational Web pages, online company brochures, chatting, instant messaging, and on and on. That's just the good old Web, or Internet to me. These applications of course can be built on the Cloud and and/or use its resources, but they are not the Cloud itself. Keeping this distinction is important because it ensures that the Cloud remains a subset of the Web rather than simply a synonym, and something more tangible to focus on.

That's how I see it today. Who knows what tomorrow will bring.