Content uploaded by Philipp Herzig
Author content
All content in this area was uploaded by Philipp Herzig on Jul 08, 2015
Content may be subject to copyright.
A Generic Platform for Enterprise Gamification
Philipp Herzig, Michael Ameling
SAP Research
Chemnitzer Straße 48
Dresden, Germany
Email: philipp.herzig@sap.com
Alexander Schill
TU Dresden
N¨
othnitzer Straße 46
Dresden, Germany
Email: alexander.schill@tu-dresden.de
Abstract—Currently, gamification is a new trend under which
all activities are subsumed that try to introduce game mechanics
into non-gaming applications in order to increase user engage-
ment, motivation, and participation. This approach is especially
promising in the enterprise domain since enterprise information
systems (EIS) mainly focus on efficiency aspects rather than
individual long-term motivation and enjoyment. Prior research
has shown that these latter variables lead to higher positive
organizational outcomes, e.g., job performance. Additionally, first
vendors have successfully implemented platforms for gamifi-
cation. However, these platforms are designed for business-to-
consumer (B2C) purposes, require high integration effort and
lead to silo-based applications. Requirements for EIS strongly
differ from consumer web or desktop applications. Hence, we
present a generic platform for enterprise gamification. We derive
an architecture for gamification systematically from service-
oriented and event-driven principles and best practices. Based
on this architecture, we identify important research challenges
for subsequent work. Ultimately, we validate the architecture’s
feasibility in a prototypical implementation.
Keywords-Gamification; Enterprise; Architecture; Integration
I. INTRODUCTION
Gamification has emerged as a new IS trend and is defined
as the “use of game design elements in non-game contexts”
[1]. In business-to-consumer (B2C) contexts, the intention of
businesses is to increase customer engagement, i.e., higher
association and loyalty with the company. More recently, this
approach also sparked interest in the enterprise domain with
the intention to introduce game mechanics on the job which
results in higher levels of employee engagement in order to
drive positive organizational outcomes, such as organizational
commitment or job performance. Enterprise information sys-
tems (EIS), such as ERP, CRM, or SCM, are acting easily as
mediator to introduce game techniques like scoreboards or fast
feedback (e.g., [2], [3]) on top of the actual business processes.
In fact, recent research has shown that gamification yields the
desired improvements from a psychological perspective, e.g.,
[4], [5], [6].
Gartner predicts that 70% of global 2000 organizations will
have at least one gamified application by 2014 [7]. Moreover,
Deutsche Bank predicts the market size of gamification to
$4.2-5.3 billion within the enterprise space only [8].
These market predictions have led to proprietary vendors
and open source projects offering generic platforms for gami-
fication. Such platforms can be used to place, e.g., incentives,
leaderboards, or social media into a web site. However, as
argued in the next section, these solutions have major draw-
backs for the usage within large enterprise systems or even
business-to-business (B2B) integration scenarios.
In this paper we present an architecture for gamification
within enterprise systems. For this purpose, we reuse prior
research on system architectures, e.g., service-oriented or
event-driven architectures. For feasibility purposes we have
implemented the proposed architecture in a prototype. Based
on this prototype, we have identified six major research
challenges that should be addressed by subsequent research.
II. RELATED WORK
Due to its timeliness, currently no cumulative research
regarding a generic platform for gamification exists. Nonethe-
less, there are first pragmatic approaches driven by practition-
ers.
In [9] two open-source (Mozilla OpenBadges, Userin-
fuser) and multiple commercial platforms (e.g., Bunchball,
Badgeville, BigDoor Media) are outlined. In the former case
the platforms are designed to introduce simple game mechan-
ics such as badges or points into a website programmatically.
Thus, they don’t fulfill enterprise requirements, such as de-
coupling or service abstraction, as argued in the next section.
In the latter case, providers offer rich gamification platforms
for large customers, such as Hasbro or Warner Bros. Again,
these vendors are strongly website and B2C market focused. In
contrast to the open-source solutions, platform providers such
as Badgeville or Bunchball are offering additional APIs as
web services, analytics for gamification data, etc.. This results
in large integration projects where the existing application
has to be modified intensively. Additionally, those integration
efforts lead to silo-based applications which, preferably, need
to be avoided in an EIS. Moreover, these platforms are
only available in a subscription based model (SaaS), i.e., the
provider owns the gamification data which is highly critical in
some countries as shown later on.
Bigdoor Media takes a slightly different approach with
their platform where they offer a customizable javascript
sidebar for websites. Although this approach reduces frontend
integration efforts, the integration of custom user input is not
foreseen. Thus, the game mechanics are very limited (e.g.,
points for content sharing or website visits) and appropriate
backend or middleware integration is beyond the scope of this
2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture
978-0-7695-4827-2/12 $26.00 © 2012 IEEE
DOI 10.1109/WICSA-ECSA.212.33
219
platform. Ultimately, all platforms are unusable for theoretical
considerations and evaluation in the field of gamification due
to their proprietary nature.
III. REQUIREMENTS
The non-functional requirements of EIS highly differ from
desktop or web applications due to their tight coupling with
business processes, organizational structure, or the business
model they support [10]. Thus, an enterprise architecture
must be designed for high flexibility and agility in order
to react fast on changing business demands with the overall
goal to improve the alignment between business and IT. For
example, simplicity, reusability, or decoupling of functionality
are primary design goals [10], [11].
In this context, concepts of service-oriented (SOA) and
event-driven architectures (EDA) provide commonly accepted
best practices and patterns for reaching the aforementioned
design goals [12], [13].
Within a service oriented architecture, autonomous and
interoperable services that offer reusable business function-
ality via standardized interfaces are aimed. These services
should be loosely-coupled and provide, in turn, orchestration
of business processes by business users. However, SOA is
usually built using synchronous request-response patterns.
Moreover, service locations and interfaces need to be known
in advance [14]. Within an EDA mindset, all participants are
communicating via events over a message broker. Instances
of the enterprise system act either as event publisher (event
sources) or event listener (event sinks). The message broker
dispatches published events to all interested subscribers. Ad-
ditionally, business rules can be externalized via decentralized
rule engines or complex event processors (CEP). In contrast to
SOA, participants are completely decoupled from each other
which results in increased flexibility and agility of the entire
architecture (e.g., [15]).
However, EDA suffers from the clear definition of how com-
ponents, interfaces, or data contracts are structured. Therefore,
SOA principles may help in EDA contexts to successfully
structure all system instances as services. Therefore, we are
reusing this approach to propose the integration of our gami-
fication platform.
Based on literature review, we have identified further re-
quirements that are specific to the domain of gamification.
First, a gamified system has to provide immediate feedback,
goals/challenges and rules to its users [3]. While the latter ones
are related to functional requirements authored by business
users in conjunction with the business processes, the first
one is non-functional and is also a primary design goal of
EDAs. Second, the platform should provide ranks/levels, time
pressure, team building, virtual goods, gifts, marketplaces,
and competitions between participants [16]. Additional game
mechanics are described in [17], [18] such as points (e.g.,
experience points, redeemable points, karma points), leader-
boards, badges, social components, or frontend customization.
It is important to denote, that these mechanics are describing
mainly the contentual body of the platform which may be used,
for example, by a gamification designer or business user.
Based on these requirements we derive the architecture
deductively in the following section.
IV. ARCHITECTURE
We derive the architecture in three steps.
First, our proposed gamification platform without surround-
ing context is depicted in Figure 1. We assume that everything
that is relevant to gamification can be represented by events.
For example, if user usuccessfully finishes step xin process
p,aneventEexists that signifies and describes all parameters
E=(u, x, p). The business rule engine stores ngame rules
R=(r1, ..., rn). In fact, the business rule engine must have
complex event processing capabilities, e.g., temporal operators
such as after or before. The game rules are authored and
managed via a business rule management system (BRMS).
Each game rule riis an if-then condition P⇒Cwhere
consequence Cis executed immediately once premise P
evaluates true. The engine evaluates each event according to
its predefined game rules. For example, if there is a rule that
rewards user ufive points for finishing step xin process p,
the rule engine distributes a reward event for this user over the
message broker. This reward event is, in turn, processed by the
game repository and stored in its database. The schema of the
database reflects the requirements from above with regards
to content. Finally, an analytical component may be used to
analyze player behavior in order to improve game rules and
optimize long-term engagement.
Fig. 1. Gamification Platform
All services of the gamification platform are exposed via
a service fac¸ade pattern [11, p. 333] in order to provide a
decoupled data contract between all communication partners.
The game data constitutes the state repository [11, p. 242]
in order to allow stateless services. The rule engine is in
conjunction with the rules centralization pattern [11, p. 216].
The enterprise service bus allows for the realization of data
model transformation,data format transformation, and proto-
col bridging patterns [11, p. 671–693].
Second, we present the surrounding context for the platform.
We presume that the existing systems belong to one of the
following architectural types or, more likely, combinations
thereof (Figure 2): (a) a SOA where services are orchestrated
by a business process management (BPM) solution and are
represented by their frontends; (b) a legacy system which
is a monolithic block of arbitrarily complex functionality;
220
(c) an event-driven architecture where a CEP controls the
choreography between services and/or frontends (Figure 2).
In this example, we utilize an inquiry and quotation service
which are constituting a simple sales process which is either
composed by a BPM tool within SOAs or triggered by a CEP
within EDAs.
!
"
Fig. 2. Architectural Assumptions
Third, in Figure 3 we put our platform into the abstract
context of the EIS. With the assumptions from above, in-
tegration point is the message broker or enterprise service
bus (ESB). Moreover, legacy systems can be integrated with
a legacy wrapper [11]. In addition, arbitrary external events
can be captured by the ESB. As specialized form of these
external events, we explicitly present the frontends of the
respective EIS. These frontends can be either web, desktop, or
mobile clients populating, e.g., user interface events into the
target platform. Besides being publishers, these frontends also
subscribe for relevant reward events generated by the game
engine, for example, to display a notification that the user has
reached a new level. Additionally, we integrate the enterprise’s
BPM with the BRMS of the platform in order to provide high
flexibility and agility for a business user. In conjunction with
the requirements, game rules will change often and have to be
changeable by a business user.
All the events are published into an enterprise service bus
which takes care of routing, service mediation, or security.
The ESB is not only useful for integration with one target
platform, but especially when processes should be gamified
across multiple businesses. For example, a developer can
define which events are communicated between enterprise
boundaries, which events are relevant for the gamification
design, or how security is handled.
A. Research Challenges
Based on the architecture, we have identified the following
questions for subsequent research.
1) Frontend Integration: Our architecture focuses on the
seamless, reusable and decoupled integration of gamification
in existing enterprise applications. However, this applies only
to the middleware and backend side. Hence, the representation
of game dynamics, e.g., the user’s status, in existing frontends
requires still huge integration effort. As described above, the
platform has to deal with a wide variety of heterogeneous
frontend devices and technologies, e.g., web, rich-clients, or
mobile technologies. Future research should address this issue
by proposing dynamic and platform-independent generation
!"#!#$
%
&'
(
)**
+,* -
.
+,*
-
* %
Fig. 3. Gamification Platform - Architecture
of libraries that enable a developer to quickly introduce
gamification on the client side. For example, we envision
modules or libraries displaying a side-bar on webpages, extra
tabs on a mobile phone, or even a generic head-up display
which provides all relevant gamification data to the user. Of
course, the shown content has to change dynamically when
the data model or the rules change in the backend in order
to meet the high agility of gamification in enterprises. Hence,
no additional development effort may be necessary after the
deployment phase.
2) Mobile Gamification: Besides traditional web or desktop
frontends, mobile devices should be supported by the platform
since mobile computing and gamification provide huge syner-
gies [19]. However, the usage context of such devices differs
strongly from traditional devices. More precisely, devices can
be in three states: connected where the speed of connection
is usually low; decoupled where no connection to a backend
exists; resynchronizing where interim data is synchronized
with the backend. We argue, that in all cases the usage
of a centralized rule engine might be inappropriate since
it violates the requirement for instant feedback. Thus, we
propose to investigate an approach of mobile rule engine where
a particular selection SR of all rules SR ⊆Rfrom the
backend is executed on the mobile device immediately and
consequences Care synchronized asynchronously with the
backend later on. In addition, this approach should also bear
in mind that computing power for rules is limited on such
devices and only possible for rules that can be evaluated on
the device locally.
3) Rule Design and BPM Integration: In order to achieve
good business/IT alignment, the rules need to be creatable and
changeable for business users without technical background.
This is an important requirement since game rules will change
often in order to improve the motivational design of the
application. Therefore, a domain specific language needs to
exist which is easily understandable and extensible to specific
business scenarios. However, in the literature there is no
universal taxonomy or ontology of game mechanics available
which leads to ambiguously defined terms. Hence, in order to
describe such a language, a prior step is to define the actual
game mechanics and their semantics in a formal way.
221
Furthermore, game rules should be applied in the context
of the business process modeling step itself. Therefore an
integration of game rules within BPM is aimed. However,
already [20] notices that an integration of BRM in general
with BPM can decrease agility unnecessarily since business
processes are unlikely to change very often in contrast to
business rules. Therefore, the authors propose to externalize
business rules within a business rule service which is invoked
by the BPM engine when desired. In turn, [21, p. 137] propose
to externalize business rules with a service because they
noticed that including business rules within a business process
leads to badly readable processes.
4) Analytics: So far, we have identified requirements and
challenges for the planning and implementation phase of a
gamification project only. However, we believe it is necessary
to constantly measure the engagement level in order to im-
prove the gamification concept ultimately. An analytical tool
should be able to measure simple features, e.g. participation
rate or revisits, as well as higher-order constructs, such as
engagement of the users. Moreover, the platform should help
business users to understand why people’s participation has
decreased or why people even left the system. However, future
research has to derive such metrics from prior literature and
apply the game data in conjunction with the game rules to
provide the desired insight.
Currently, our platform has not implemented any kind of
analytical component on top of the atomic gamification data.
5) Privacy: Contrarily, privacy is a key concern when it
comes to gamification due to the high levels of transparency. In
the most sophisticated scenario, each user action in the system
is tracked and can be potentially reconstructed. Although
this might be of interest to the top-management, in many
countries the collection of such fine-grained employee data is
forbidden. For example, in German enterprises, work councils
are allowed to reject the introduction of systems that elevate
too many employee data. Thus, within the platform a security
mechanism has to exist that allows access to fine-grained
employee data to its creator only. In addition, others may only
access anonymized or aggregated data.
On the other side, in most gamification cases people should
collaborate or compete in a gamified solution. Hence, there
must be some kind of visibility between users. In our solution,
users have three opportunities to secure their privacy. First,
they may select an avatar reflecting their virtual identity which
is used when showing the users’ gamification data to others. Of
course, internally this virtual identity is still correlated with the
user’s real world identity. Second, they may turn gamification
off, i.e., no more gamification relevant data is collected. Third,
on the arrival of the first gamification event for each user, the
platform generates a message to the frontends triggering an
invitation that informs the user about the collection of data.
If the user declines this invitation, the gamification platforms
turns data collection off as well.
6) Multi-tenancy: In order to reduce total cost of own-
ership, the gamification platform should be also integrable
to cloud environments. However, this raises the question
how multi-tenancy is handled. This applies especially to the
evaluation of game rules in the rule engine since the fact base
is always stateful. This problem even increases if the rules
contain time behavior (e.g., delay rules). In this domain, hardly
no research exists that evaluates on-demand approaches for
business rule management that meet the agility requirements
of SOA (e.g., stateless services). In fact, our architecture still
suffers from the statefulness of the business rule service, for
example, if rule conditions are evaluated after a substantial
time period. Subsequent research should try to adopt the
principles of multi-tenancy in databases in order to describe
solution approaches.
In our current use case, multiple tenants (actually different
businesses) simply run in one single rule engine since all
tenants collaborate with each other under the same rules.
However, each tenant may define its own set of rules apart
from another common set of rules which applies for all tenants.
In this case, conflicts have to be resolved in collaborative or
competitive scenarios. Moreover, multiple instances of rule
engines may exist in order to improve performance.
V. E VALUATION
We have implemented the aforementioned architecture in
a prototype and, thus, validated its feasibility with regards
to requirements and assumptions. Additionally, the prototype
is used as testbed for subsequent research. Our prototype
consists of four individually deployable packages. First, the
rule package consisting of the game rules and a changeset
descriptor. Second, the rule engine consisting of Drools Fusion
as complex event processor. Third, the game data component
that stores the users’ progress events. Fourth, a legacy wrapper
that pulls data out of a database from a legacy system. In
addition, we use Apache ActiveMQ in publish/subscribe mode
for event routing and service mediation.
In the first step, the legacy wrapper may generate some
new user events since in our case we handle user management
explicitly by rules (Listing 1). As alternative, user management
may be done implicitly on the arrival of arbitrary events.
1rule ”newUser ”
2when
3$evt : EventObject ( type==”new user” ) from
entry−point eventstream
4then
5GamificationEvent ge = new GamificationEvent () ;
6ge. setType ( ” createPlayer ”) ;
7ge. setP layerid ( $evt. getPlayerId () ) ;
8ge . put (” logonname” , $ evt . get ( ”logonname” ) ) ;
9bus. publish ( ge) ;
10 retract ($evt);
11 end
Listing 1. Example rule for user management
After users have been created, subsequent user actions are
sent from the legacy wrapper to the rule engine. Herein, we
provide an example where a user simply gets one experience
point when opening a severe ticket within 10 seconds after
first login. For this purpose, the atomic event new login which
activates rule newLogin is transformed into a complex event
222
delayed login by adding a duration of 10,000 milliseconds.
This event, in turn, activates the rule loginAfterDurationEx-
pired which deletes the delayed login event from the working
memory after its duration. However, if an open ticket event
occurs and the delayed login event is still available, the rule
generates the respective gamification event (Listing 2).
1rule ”newLogin ”
2when
3Player ( $playerid : userid )
4$evt : EventObject ( type ==’ new login’ , playerid==
$p lay er id , e ven tD ura ti on ==0) from
entry−point eventstream
5then
6EventObject obj = new EventObject () ;
7obj . setType ( ” delay ed login” ) ;
8obj . setEventDuration (10∗1000) ;
9obj. setPla yerid ( $playerid ) ;
10 obj . setDateTime ( new Date ( System .
currentTimeMillis () ) ) ;
11 obj. put(” sessionid ” , $evt . get(” sessionid” )) ;
12 retract ($evt);
13 entryPoints[”eventstream”]. insert ( obj);
14 end
15
16
17 rule ”loginAfterDurationExpired ”
18 timer ( expr: $duration ; )
19 when
20 $p : Player( $playerid : userid )
21 $dl : EventObject ( type ==’ delay ed login ’ ,
$duration : eventDuration , playerid==
$playerid ) from entry −point eventstream
22 then
23 retract ($dl);
24 end
25
26
27 rule ”openTicketAfterLogin ”
28 when
29 $p : Player( $playerid : userid )
30 $dl : EventObject ( type ==’ delay ed login ’ ,
playerid==$playerid) from entry −point
eventstream
31 $ot : EventObject( type==’ open ticket’ , level==’
severe’ , playerid==$playerid , data[ ’
sessionid ’]== $dl. data[ ’ sessionid ’ ]) from
entry−point eventstream
32 then
33 GamificationEvent ge = new GamificationEvent () ;
34 ge. setType (” gi vePo ints ” ) ;
35 ge. setP layerid ( $evt. getPlayerId () ) ;
36 ge . put ( ”pointname ” , ”XP”) . put ( ”amount” , 1) ;
37 bus . publish ( ge) ;
38 retract ($dl);
39 end
Listing 2. Example rules for rewarding one user behavior
It is important to note that all events are published to the
message broker (called bus herein) which dispatches the events
to the game data repository based on type. Moreover, rules
may need the users’ prior achievements. Currently, we delete
the user from the rule engine’s working memory, retrieve their
data from the game repository and insert them again into the
working memory on the arrival of new events. This leaves
room for optimization in future work.
VI. CONCLUSIONS &OUTLOOK
The gamification of enterprise systems offers a wide range
of relevant topics for researchers and practitioners. These
topics were derived systematically out of prior art in enterprise
architectures and the requirements for gamification. Moreover,
a generic architecture for gamification and its integration into
EIS has been proposed. For future research we especially try
to investigate the mobile domain as well as generic frontend
integration scenarios. In addition, we validate the architecture
more precisely in the context of relevant use cases presenting
data models, rules, and business processes.
REFERENCES
[1] Gamification: Using Game Design Elements in Non-Gaming Contexts,
CHI. Vancouver, BC, Canada: ACM Press, May 2011.
[2] D. Flatla, C. Gutwin, L. Nacke, S. Bateman, and R. Mandryk, “Calibra-
tion Games: Making Calibration Taks Enjoyable by Adding Motivating
Game Elements,” in UIST, 2011.
[3] J. McGonigal, Reality is Broken: Why Games Make Us Better and How
They Can Change The World. New York: The Penguin Press, 2011.
[4] P. Herzig, S. Strahringer, and M. Ameling, “Gamification of ERP Sys-
tems - Exploring Gamification Effects on User Acceptance Constructs,”
in Multikonferenz Wirtschaftsinformatik. GITO, 2012, pp. 793–804.
[5] J. Thom, D. R. Millen, and J. DiMicco, “Removing Gamification from
an Enterprise,” in Proceedings CSCW, 2012, pp. 1067–1070.
[6] J. Yang, M. S. Ackerman, and L. A. Adamic, “Virtual Gifts and
Guanxi: Supporting Social Exchange in a Chinese Online Community,”
in Proceedings CSCW, 2011, pp. 45–54.
[7] C. Petty and H. Stevens. Over 70 Percent of Global 2000 Organisations
Will Have at Least One Gamified Application by 2014. Gartner, Inc.
[Online]. Available: http://www.gartner.com/it/page.jsp?id=1844115
[8] M. Geall, “Enterprise IT - Workers of the World Consume and Unite,”
Global Markets Research, pp. 1–84, 2011.
[9] Y. Xu, “Literature Review on Web Application Gamification
and Analytics,” August 2011, available on http://csdl-
techreports.googlecode.com/svn/trunk/techreports/11-05/11-05.pdf
(retrieved on 23.01.2012).
[10] D. Krafzig, K. Banke, and D. Slama, Enterprise SOA - Service-oriented
Architecture Best Practices. Prentice Hall International, 2005.
[11] T. Erl, SOA Design Patterns. Prentice-Hall, 2009.
[12] E. J. Sinz, “SOA und die bew¨
ahrten methodischen Grundlagen der
Entwicklung betrieblicher IT-Systeme,” WIRTSCHAFTSINFORMATIK,
vol. 1, pp. 70–72, 2008.
[13] O. Levina and V. Stantchev, “Realizing Event-Driven SOA,” in Int. Conf.
on Internet and Web Applications and Services. Venice/Mestre: IEEE,
2009, pp. 37–42.
[14] J. Boubeta-Puig, G. Ortiz, and I. Medina-Bulo, “An Approach of
Early Disease Detection using CEP and SOA,” in Third International
Conferences on Advanced Service Computing, 2011, pp. 143–148.
[15] T. Buckel, “Zum Potential von Event-Driven Architecture f¨
ur kom-
plexe Unternehmensnetzwerke,” in Multikonferenz Wirtschaftsinfor-
matik. GITO, 2012, pp. 83–95.
[16] B. Reeves and J. L. Read, Total Engagement: Using Games and Virtual
Worlds to Change the Way People Work and Businesses Compete.
Boston, MA: Harvard Business Press, 2009.
[17] G. Zichermann and C. Cunningham, Gamification by Design: Imple-
menting Game Mechanics in Web and Mobile Apps. O’Reilly Media,
2011.
[18] C. W. Scheiner, M. Witt, K.-I. Voigt, and S. Robra-Bissantz, “Ein-
satz von Spielemechaniken in Ideenwettbewerben,” in Multikonferenz
Wirtschaftsinformatik. GITO, 2012, pp. 781–792.
[19] M. Breuer, “Die reine Freude am Spiel: Spielerische Konzepte f¨
ur die
Kundenbindung,” mobile Developer, vol. 3, pp. 124–131, 2012.
[20] M. E. Kharbili and T. Keil, “Bringing Agility to Business Process
Management: Rules Deployment in an SOA,” in Emerging Web Services
Technology - Volume III. Berlin: Birkh ¨
auser Verlag, 2010, pp. 157–170.
[21] J. Hohwiller, D. Schlegel, G. Grieser, and Yvette, “Integration of BPM
and BRM,” in Business Process Modeling and Notation, R. Dijkam,
J. Hofstetter, and J. Koehler, Eds. Berlin, Heidelberg: Springer, 2011,
pp. 136–141.
223
