
for all of the components in a single, browser-based 
application. 
To summarize, the value proposition of EE for 
the user forms through a tightly integrated, 
experience-enhancing, socially engaging, and in part 
unique service bundle for event attendees, providing 
a unified event experience before, during, and after 
the event. For the organizer, the value is created 
through providing a low-weight, mobile interaction 
channel to the users as well as through the benefits 
of mobile ticketing. The final quality of the value 
proposition will depend on the degree of integration 
in the bundled services. Integration to existing social 
networking services is crucial in order to take 
advantage of existing online social communities. 
4.2  Technology Domain 
As per our definition of the mobile cloud paradigm 
presented in Section 1, the whole EE application is 
placed on cloud infrastructure, such as the public-
cloud service Amazon EC2 (Amazon Web Services 
LLC, 2010). Thus, the processing requirements on 
the end-user device are decreased. Moreover, 
services using this approach are not as reliant on the 
capabilities of end-user devices and can be targeted 
to a wider range of mobile phones. Furthermore, if 
no application is required on the handset, adopting 
the service will be easier for the user, and the service 
deployment process becomes much simpler for the 
service provider. Another substantial benefit of 
placing the EE application in the cloud is the 
capability to overcome the fragmentation problem of 
mobile operating systems.  
A prototype version of the EE service was 
developed during September-October 2010, which 
included a subset of the features described in Section 
4.1. The main focus of the prototype implementation 
was to build a proof-of-concept application. For this 
version of the service, we had to implement mock-
up versions of the functionality because some of the 
technical capabilities of GSMA OneAPI standard 
were not available; instead, we utilized the 
proprietary open APIs provided by a single operator. 
We do not see this as an issue as the goal for this 
version was to build a prototype, which is to be used 
to showcase the value proposition. More 
specifically, mock-up functionality was done in 
context of the payment capabilities. 
The prototype project was carried out in 
cooperation with University of Helsinki Department 
of Computer Science as part of the Software Factory 
program (Software Factory, 2010). The prototype 
was developed during a seven-week period at the 
Software Factory. The total development effort 
accounted to about 500 hours. 
The primary features of the prototype included 
preliminary versions of the user and organizer 
applications and integration to the Facebook social-
networking platform (Facebook, 2010). The 
Facebook platform was chosen because it is 
widespread and the de facto event publication site 
and because it connects visitors, friends, and events
. 
In addition, Facebook enables content sharing and 
provides open interfaces for additional applications.   
The usable functionality of the prototype was 
limited to the event-wall feature, SMS/MMS-based 
mobile ticketing and payment mock-ups, as well as 
messaging. The system architecture was based on 
the Model-View-Controller model, which allows 
extending the functionality: new features can be 
added later; for example, based on user or other 
stakeholder feedback for the service prototype. 
The most significant challenges for the 
implementation were created by the actual 
integration to external systems – more specifically, 
the Facebook social-networking platform integration 
proved to be problematic. Thus, even though Open 
APIs are a key enabler for the new cloud-based 
applications, they can also create significant hurdles 
for the external service-developer. One example of 
such hurdles is poor documentation of external 
APIs, which will in effect destroy the low barriers of 
experimentation and entry. Thus, the external APIs 
impose both technical and business restrictions and 
dependencies for the developer. The technical issues 
are already being addressed by the GSMA OneAPI 
standard, which facilitates an experimentation-
friendly environment in the context of OT APIs. 
4.3  Organization Domain 
As the organizational model of OT, this study 
assumes the so-called virtual-broker model, in which 
the operators act as a single access point to the 
common network capabilities of a cross-network 
environment (Raivio, Luukkainen, and Seppälä, 
2011; Suikkola, 2011). A similar multi-operator 
value network exists also in the recently launched 
Finnish mobile certificate service, in which the 
operators have co-operated exceptionally closely 
(Mobiilivarmenne, 2010). 
Figure 1 shows an example of the value network 
for EE. The most central role in the value network is 
naturally dedicated for the service provider who 
manages the service integration and is responsible 
for the operation of the service as a whole. Different 
service components can be implemented by 
CLOSER 2011 - International Conference on Cloud Computing and Services Science
272