How points can miss the point - thoughts on gamification

​I like games. I like work.

But I'm bothered by "gamification" - the trend of using game design methods to encourage specific behavior in non-game situations, like the work environment. Usually this involves the use of points, badges, levels, and other feedback mechanisms. Often there is an element of competition involved.

Since I enjoy both games and work, one might think I'd be a fan of bringing the two closer together. Actually, I find the idea fundamentally problematic and prone to misuse. If I worked like I play games, or cared about work like I care about games, I would have been fired many times over by now.

What are we missing when we advocate gamification systems focused on points and badges? It might be a misunderstanding of games, or perhaps a narrow focus on a particular type of game or on a specific type of mechanic employed in games. Sure, the collection of points and levels can be enjoyable in games, but points aren't the intrinsic reason people play games. Points, in games and in gamification, are extrinsic motivators that can provide a temporary motivation boost or a  framework for a more intrinsic motivation, but which don't in themselves drive long-term engagement.

For every good game, I can show you something besides points that is the real reason I'm interested in that game. These reasons will be things like beauty, risk, competition, empathy, cooperation, excitement, mastery, surprise, uncertainty, approbation, story, joy, exercise, fear, relaxation, zoning out, maybe even friendship.

Sometimes points will enable one of these intrinsic motivators, but intrinsic motivators more often manifest in other ways and points are either absent or irrelevant. Points can even be counterproductive when deep intrinsic motivators like beauty, joy, mastery, empathy, cooperation, and friendship are in play.

Let's take an example. A game I've never played (it's PS3-only), but which crystalized some of these thoughts for me: Journey.

I've heard Journey spoken of as a unique game that emerged out of a unique development philosophy. In addition to wishing to tell a beautiful and haunting story, Journey attempts to create an anonymous social environment where interactions are overwhelmingly positive. In order to accomplish this, ​modes of interaction are severely curtailed. Players can make a single social gesture: a sort of "song" where the character's avatar hums a player-specific musical note and displays a glowing glyph over its head. Players can't interfere with each other (except to "recharge" each others' jump ability) and cannot communicate using language expect what it is possible to sing using these monosyllabic expressions.
Here is a video of some Journey game-play with a half-silly, half-serious running commentary. Watch a little.​

​I'd like to draw your attention to just before 10:00 in this video, as the avatar is skiing down a slope and the short monologue by the caster after this. Then keep watching for another minute to see him meet up with another player. To paraphrase, this is a game that gets you to want to explore using story, beauty, and curiosity. There are no points. There is only "I wonder if ...", "What happens next?", and "Wow". The only thing approximating leveling is the fact that the character gains an enhanced ability to jump and "sing" as the game goes on, but in the context of this game it appears to be more of a plot device than a leveling system. And yet, the player wants to go on, wants to explore and find out more about the story, and (most surprisingly perhaps) loves to interact with others in the world and considers them to be friends.

Journey uses beauty, story, curiosity, serendipity, cooperation, and friendship to make the game interesting, re-playable, and emotional. And it obviously succeeds. For me it's surprisingly riveting to simply watch someone else play the game. (If you want to know more, the first video in the series is here, and here is a review that mostly relates the experience of watching others play the game including a touching anecdote.) You don't get this kind of experience and meaning using only points.

The best games, like Journey, are games that aspire to be more than games. These games embody stories, art, community, cooperation, competition, opportunities for mastery, or all of these things. Yet, even these exceptional games don't capture our imaginations for all that long.

So what do we take from this? Mostly a lot of questions. Points systems are certainly useful in some situations, especially when used to structure competition. But I wonder if the overwhelming place of points in the gamification discussion belies something fundamental missing from the work environments we are trying to fix using gamification techniques. When we use points, levels, and badges to motivate, does that ​indicate a lack of intrinsic motivation in the environment? Are gamification systems acting as amplifiers of the meaning of our work, or are they attempting to impose an artificial rewards system that is at odds with the meaning of our work? If work is meaningful, wouldn't it be best to directly communicate that meaning to workers rather than filtering it through a metaphor of points and levels? If work isn't meaningful, or if the meaning of our work is negative or morally questionable, then why do we glorify the tools used to trick people into working on these things?

Shouldn't gamification be about the question of how, in our work environments, we communicate the meaning of our work? How do we provide opportunities for mastery, joy, beauty, and positive social interaction in the workplace and in our lives? Those, and other positive intrinsic motivators, are the goals. Points are, at best, a means to these ends.

2nd episode of "BW for BObj Community" podcast

The second episode of the podcast series that Josh Fletcher and I are putting together is now up on the DSLayer site. Head on over to check it out and see us talk about and demo getting the ins and outs of getting the free trial version of BW up and running, connecting BW with Data Services (the old way and the new way), and setting up a quick(ish) and dirty datamart in BW. There is even some crashing and burning at the end, as promised!

In future, hopefully shorter, episodes we are planning to get a BEx query set up with some calculated measures, pull in some additional employee data, and report on the whole thing using BI4 tools. Maybe we'll even take some initial steps away from a data-mart approach and towards a data warehouse approach.

The BW/BObj Rift - We're all just services

Eric Vallo has written a quite wonderful and balanced piece starting to dig into the rift between the BW and BusinessObjects BI communities over on the EVTechnologies blog. As Eric mentions, his blog was the result of quite a bit of back-and-forth between the two of us, the other principals involved in the DS Layer site, and the wider SAP and BusinessObjects communities. Eric was kind enough to kick off the conversation, and I'll continue it here. Hopefully this will evolve into a longer public conversation.

So, let's get started!

Eric did a good job of laying out the different scenarios we tend to see out in the SAP & BusinessObjects customer ecosystem right now. While each of these scenarios is clear, I think there is still a huge amount of confusion within both the BW and BusinessObjects communities about what each set of tools does and what it should be used for. In other words, when do you go for each scenario or tool? In my opinion, this confusion stems from the reality that both toolsets do a lot of things, and there is a lot of overlap. You can build a full datawarehouse and BI reporting solution using only BusinessObjects tools. And you can do the same using only BW tools. Or you can mix-and-match and pull in 3rd-party tools as well. But each toolset certainly has its strengths and weaknesses.

My take on BW's strengths and weaknesses is, perhaps, a bit out of the mainstream. But I think it is justified and, importantly, I think it is in line with SAP's vision for it's data platform. Specifically, I see BW as a set of data warehousing, data management, and systems management services. I admit readily that I've shamelessly stolen this way of describing the concept from others, but it fits so well that I have to use it. So, BW provides a set of services like the following very incomplete list:

  • An abstract, platform-independent data warehouse modeling environment
  • A service for imposing a semantic model on top of the data warehouse modeling environment
  • An analytic engine for executing queries on the data residing under the semantic model
  • Security
  • Data management services like near-line storage (the ability to pretty transparently persist data in a single semantic structure across two data-stores with remarkably different latency, structure, performance, and cost characteristics while still being able to query that data "live") or archiving.
  • Visualization and reporting services

The implementation of this service concept is far from perfect. In fact, today, most of these "services" aren't really recognizable as such because BW is such an integrated intertwined monster. With BW on HANA, we are now starting to see some of these services exposed individually, and the result is rather impressive.

One advantage of seeing BW as a collection of services for the purposes of this discussion is that it becomes much less important whether BW continues to exist. When viewed this way, the whole discussion about whether or not SAP HANA is going to "kill" BW becomes moot. The important question is whether the services continue to exist, either as part of BW, part of the HANA platform, or in another way. It is the services that provide the value, not BW per se.

The same actually holds true for BusinessObjects. Here we have services like the following (again, incomplete):

  • A service for imposing a semantic model on existing data models
  • An analytical engine for executing queries on the data residing under the semantic model
  • Security
  • Services for moving data from one place to another and transforming that data
  • Services for tracking and analyzing data lineage and quality across multiple platforms
  • Visualization and reporting services

BusinessObjects took a much more service-oriented development approach from the beginning, so many of these services are much more obvious as individual BusinessObjects products or product components. You might recognize direct descriptions of Universes, Data Services, or Information Steward, or the host of BusinessObjects reporting and visualization tools whereas in the case of the BW services there is no individual tool we can install to provide the service.

You probably also notice some overlap with the list of services in BW. Hence, the confusion.

The really interesting part of this overlap is that some of these services are provided in pretty similar ways between the two platforms (the semantic layer) while others take a very different approach (visualization and reporting services) or simply don't exist on one platform or another (abstract data warehouse modeling environment, or tracking and analyzing data lineage). It's these different approaches or unique services that differentiate the platforms.

Until SAP matures its data platform strategy and makes some decisions about which overlapping services live, die, or merge on each platform, it's going to be up to customers to do the hard thinking necessary to make the best implementation decisions for them. It is, of course, important to know what services each platform offers, what technique the platform uses to offer those services, and what kind of performance and functional characteristics similar services have on the different platforms. I hope that the podcast series Josh Fletcher and I are working on will help with that discussion across customers. But in addition to these feature considerations, there are also cost, requirements, tooling, and expertise considerations that are going to be unique to each customer.

Personally, I think BW and BusinessObjects tools both have a lot to offer and we shouldn't discount one or the other when we're talking about addressing data warehousing or BI problems. As consultants, we'll have our personal preferences, but we should try not to let that influence our customer advisory roles when addressing early design and tool selection questions.

In the data warehousing space, my strong feeling is that BW's approach (if not BW itself) is a powerful approach to making datawarehousing more accessible. It doesn't solve the basic problems of data modeling and data governance, and it can introduce its own set of problems. But BW does help abstract some really knotty technical and organizational problems that like data consistency, technical governance, platform-specific optimization, and technical change management that must be addressed when building a data warehouse.

Meanwhile, the BusinessObjects approach of a really open, modern, and platform agnostic BI and EIM toolset is a great one. Especially in the ETL and BI space, many of the services that BusinessObjects offers are years, even decades ahead of where BW is with its more integrated and older transformation and reporting engines.

I'm hoping that the two communities can learn a lot from each other by interacting more both technically and socially. In other words, like Eric, I am really looking forward to feedback and teaching through other blogs or Twitter.

And now, back to you, Eric.

"SAP BW for the BusinessObjects Community" video podcast

I'm doing a podcast series with Josh Fletcher from the DS Layer site on the topic of BW for the BObj community. Our first episode is out, so if you're interested in the topic of BW-BusinessObjects integration and what use BusinessObjects shops could possibly find for BW, you may want to take a look.

In this episode we discuss what BW is and what it can offer, and in future episodes we're going to piece together a Data Services extraction, BW-based data mart, and BusinessObjects-based reporting live. Tune in to watch us crash and burn. ;-)