A Standardized Maturity Model for Designing SaaS Service Guideline

Transcription

1 A Standardized Maturity Model for Designing SaaS Guideline Seungseok Kang 1, Jaeseok Myung 1, Jongheum Yeon 1, Seong-wook Ha 2, Taehyung Cho 2, Ji-man Chung 2, Sang-goo Lee 1 Department of Computer Science and Engineering, Seoul National University, Seoul, Korea 1 Q.N.SOLV Corporation, Seoul, Korea 2 {pyxis81, jsmyung, jonghm, sglee}@europa.snu.ac.kr 1 {suha, thcho, comgen27}@qnsolv.com 2 Abstract In today s dynamic IT environment with increased global competition, enterprises must achieve greater business agility and decrease the TCO (Total Cost of Ownership) of their system for service. As the need for innovative software circulation process emerges, SaaS (Software as a ) is introduced for integrating software service framework. But most of current ASP (Application Provider) Players have difficulties to migrate their systems to SaaS Platform for the lack of maturity model and process. In this paper, we have surveyed several cases of SaaS service, and we identified the common key functions of SaaS service. We contend that the practical maturity model is a key enabler for achieving migration to innovative SaaS service platform. To assist in building our SaaS maturity model, we defined two important axes of maturity model and introduced the detailed components of each phase with the guideline which contains the essential activities according to the common functions of SaaS service. 1. Introduction The economical, social, and technological development in the computing environment triggers big changes in the software business. The emergence of Web and its infrastructure has become an integral part of enterprise computing and continues to give both new opportunities and challenges to the software providing vendors. Intuitively, the development of IT technology and business environment gives a significant influence on software business as well as software itself. Traditional business paradigm on software is evolved due to the rapid change of IT technology, and it also brings the change of the type of service and technology. This paradigm shift in software business is categorized into four key parts of core service component Data, System,, and Business. Figure 1 illustrates the example of technical paradigm shift of four service components. Figure 1. Technical Paradigm Shift in Software Business The emerging of SaaS is one of the results which are derived by paradigm shift. Based on the changes of software business environment, a number of current ASP players have tried to advance to new paradigm with SaaS service component. However, there are still some challenging issues due to the lack of adequate growth strategy and proper guideline for adapting the characteristics of SaaS service in their current service model. In this respect, we believe that a SaaS platform guideline based on a standardized SaaS maturity model is an enabler of a myriad of current ASP players who want to adapt the concept of SaaS service. In this paper, we survey several cases of current SaaS service, and identify the common key functions of SaaS service that is needed to build successful SaaS service from their service model. Second, we define our SaaS maturity model and the detailed components of each phase of our model with two important axes which describe the degree of development level. Finally, we propose the standardized SaaS platform guideline which contains the essential activities according to the common functions of SaaS service.

2 2. Related Work It s a common experience among software companies today with increasing cost pressure, high customer expectation, and global competition all placing new demands on development and delivery processes. SaaS is a software delivery model where instead of purchasing the software and implementing, users can rent the software on a monthly cost-per-user or usage basis and can scale up or down as needed [1]. There are some representative SaaS vendors including Microsoft, Google, Salesforce.com, and Amazon which provide successful service cases. They have different strategies to catch up the paradigm shift toward SaaS respectively. However, nowadays, it seems that software vendors have reached a consensus that SaaS model can be achieved in an incremental way. Several research groups have reported characteristics and maturity model for SaaS service platform. Microsoft characterizes configurability, multi-tenancy, scalability as key criteria of SaaS maturity model [2]. Forrester group also presented 6 levels of maturity model from traditional ASP to SaaS service model [3]. In addition, SaaS has been intensively studied with the academic point of view. A number of academic researchers have analyzed principal aspects of SaaS model, and also, have reported several features and advantages with both customer s and enterprise s perspectives [4-6]. Actually, SaaS is a complex business model which has many role players such as customer, developer, vendors, and so on. Therefore, some researches argued processes and interactions between them [7-8], and also, some researchers introduced lesson learned of implementing SaaS [9-11]. There also have been discussions about the maturity of SaaS model [12]. The rest of this paper is organized as follow. In section 3, we introduce our research methodology to find out key enablers for SaaS service model. According to the research methodology, in section 4, we examine current SaaS service cases and identify common features of SaaS service. In section 5, current SaaS maturity models are introduced and compared with our maturity model. A detail guideline for the maturity model is presented in section 6, and finally we draw our conclusion in section Research Methodology The final purpose of this paper is to present a practical SaaS maturity model for current ASP players and a guideline for building SaaS platform. In detail, we suppose to present the technical and business roadmap by defining the characteristics of SaaS platform in practical way, and introduce the process requirement for providing SaaS service. In this chapter, we describe the research procedure in three steps Deriving SaaS Functions Generally SaaS service consists of core functions which represent the properties of SaaS service. In this phase, we derived some common key functions of SaaS service through the survey of several cases of SaaS vendors. As a part of result, there are two types of functions technical and business functions and we categorized each function area into special parts according to their own characteristics Defining SaaS Maturity Model In the viewpoint of the service function which is derived from section 4.2, we have analyzed the current maturity model for SaaS service such as Microsoft s and Forrester s model. Considering these approaches, we defined the important axis of our maturity model into two categories: service component axis and maturity level axis. We also suggested our maturity model based on these axes according to the incremental development phase of the features in the service component with four levels Establishing SaaS Guideline The last step of our research methodology is establishing SaaS guideline according to our maturity levels and the core functions of SaaS. In order to make practical guideline to build SaaS, we categorized the technical activities which constitute the role of each layer on the maturity levels. SaaS service architecture is also suggested in Section 6 based on a number of technical activities and the layers of the service components with detailed service process model which is needed to provide SaaS service value. 4. An Analysis of SaaS s As we mentioned in previous section, SaaS is one of results in the software paradigm shift. Since definition of SaaS is shown as various meanings according to researchers, we adapted the meaning of SaaS service through the Gartner Group as follows: software that is owned, delivered and managed remotely by one or more providers. The provider delivers an application based on a single set of common code and data definitions, which are consumed in a one-to-many model by all contracted customers, at anytime on a pay-for-use basis, or as a

3 subscription based on usage metrics. [8]. In other words, SaaS is a service-oriented framework with high deployment efficiency and supportable platform where ASP focused on architecture-oriented solutions with low deployment efficiency relatively. An example of comparison between SaaS and ASP is given in table 1. Similarity Difference Table 1. A Comparison of SaaS vs. ASP Characteristics Type Fee Demand Provider Architecture Update / Patch Area SaaS (Software as a ) ASP (Application Provider) Remote service based on Web Subscription fee per application Software developer / Hosting vendors Software provider Multi-tenant architecture Centralized update / No user-level patch External collaborative solutions (CRM, SCM) Single-tenant architecture Centralized or de-centralized update / Userlevel patch Existing on-premise applications (ERP, GW) Despite of these differences and merits of SaaS, many migration efforts into SaaS service have failed because they usually misunderstand the concepts of SaaS service, or they do not seize the primary factors in case of successful SaaS service vendors. In this section, we discuss several cases of current large SaaS vendors which have their own characteristics of functionalities of SaaS service, and derive the essential common functions to build successful SaaS service Case Study: In Case of Current SaaS Vendors Nowadays, the marketplace of SaaS service is mostly lead by international large software vendors (e.g. Microsoft, Google, and Amazon). Also, there is tremendous growth of independent vendors that are related with traditional solution provider for enterprise (e.g. Salesforce.com). We selected these four major vendors as the successful cases of current SaaS service and surveyed the technical and business characteristics based on our conceptual SaaS service characteristics. Table 2 shows a summarized result of present condition of four SaaS service vendors Amazon: Infrastructure. Amazon provides SaaS service in terms of Amazon Web s, which consists of five main service infrastructures and nine solutions. It mainly focus on providing computing resources to users rather than a separated web-based application so that it gives customers various business application on their service infrastructure that is based on cloud computing Table 2. Summarization of SaaS Vendors Vendors Amazon Salesforce Microsoft Google Description Computing Resource Providing Web-based CRM Personal / Office Tools Web Office Tools Business Model Amazon Web s Force.com Microsoft Office Live Google Apps Origin Strategy Infrastructure Platform as a Software + on the Web Web service Web service / CRM Package Software Web- Based service paradigm. The goal of Amazon s SaaS service can be summarized by these terms: Cost-effective, Dependable, Flexible, and Comprehensive. In order to achieve the goals of Amazon Web s, they settled various service types from business infrastructure to Web search and on-demand workforce. A distinct characteristic of Amazon Web is to give the opportunity to ISVs (Independent Software Provider), where the main targeted user of other vendors is end-users themselves who use the applications on the SaaS framework Salesforce.com: Platform as a. The SaaS service of Salesforce.com can be summarized as Force.com platform. It is a multi-tenant on-demand business platform which consists of service component and process. In detail, major service component of Force.com constitute stack service layer from secured infrastructure to application exchange. Apex, for example, is one of the service components where developers use programming language as well as UI developing tools named VisualForce and marketplaces such as AppExchange. The biggest difference of the strategic directions of salesforce.com is to be a solution provider to enterprise with multi-tenant support platform. The whole service process of Force.com service aimed to achieving the next level of current SaaS, which is called PaaS (Platform as a ). It means that PaaS should be able to provide the tools for developing on-demand applications easily on the Web-based infrastructure as well as using and distributing the solutions Microsoft: Software+. The main target users of Microsoft are customers who have used Microsoft s package software such as Windows and Microsoft Office. They try to add the service strategy based on the web to existing software in comparison with the other vendors who provide their service through network by using Web browser. This strategy is called Software+. The strategic directions of Microsoft are categorized into four parts: Unified Experience, Server and Cloud, Tightly Coupled System,

4 and Multiple Business Model. By adapting these strategies, Microsoft tries to get flexibility and availability on service process from building service with software to software distribution Google: on the Web. Google provide SaaS service as the set of Google application named GoogleApps. The main targeted users of Google are end-users including individuals and small enterprises. GoogleApps provide communicate and connect service through Web browser, and they are interlinked by collaboration process of Google Application such as Google Docs and Google Sites. In order to use their infrastructure and ability to search on the Web, Google tries to organize user s service via Web application development environment named Google Apps Engine. Most of Google SaaS service is supposed in the form of distributed APIs to guarantee effectiveness, flexibility, and easiness of application usage Common Functions of SaaS By surveying representative cases of current SaaS service, the common functions are established which could be used for building standardized SaaS platform. We classified each function into second-level categories, and each category is also included in firstlevel categories according to its characteristics and usages. Table 3 summarized derived function list and our categorization criteria as follows Technical Functions. It means a set of functions which are related to technical issues of SaaS service such as database management, configurable user interface and business workflow, and integration technology. Microsoft s maturity model already defined the incremental phase of the growth of SaaS service with three features: Multi-Tenant Support, Configuration, and Scalability. It shows that an appropriate and detailed function is needed for achieving each goal of maturity level so that we expand the concept of the feature in their maturity level with Standard Support, Integration, and Security. Shared database and service and predefined database extension, for example, are important to support multitenant environment so that users share their contents easily through shared database schema where predefined extension can be used to control the range of query result by each user s intension. The entire set of important technical functions is described in table Business Functions. Business function is another important issue of SaaS service because software vendors should provide proper business model to customers and guarantee the continuity of business activity on their service platform with performance. We divide the business functions into four categories such as Market, Scalability, Development, and Communication area. Each category also contains list of detailed functions, which can support availability of core business competency. For instance, ASP player should apply SLA adaptation and support policy in order to guarantee the quality of service on their open marketplace for migrating into SaaS service. The important business functions set is also described in table SaaS Maturity Model The strategic positioning of current SaaS services are promoted in different ways according to platform openness to partnership and their original service type such as packaged software or Web-based service. We conclude that the SaaS service should deal with the change of customer s requirement considering the range of users. However, there is no proper guideline for evolving the service with customers requirement. Several models show the way to build SaaS service incrementally with their own maturity levels until now. Nevertheless, these models have not been able to present concrete procedures due to ambiguous definition of maturity levels. In this section, we analyze existing SaaS maturity models and present our maturity model much more clearly with two axes Current Maturity Model for SaaS As we mentioned above, SaaS maturity model is brought on the basis of software paradigm shift and the change of system architecture. Microsoft, one of the biggest SaaS service vendors, and Forrester research groups suggest their SaaS maturity model Microsoft s Maturity Model. Microsoft Model is a sort of incremental development model through integration between functional features of SaaS. There are four level of maturity level such as Ad hoc/custom, Configurable, Multi-Tenant, and Scalable. Ad hoc level represents traditional ASP model with customizing to each individual users. At configurable level, users do not need to modify the application in the code level so that they can use the application with configurable options. In the next level, SaaS platform supports multi-tenant architecture in single instance in order to adapt various customers requirements without any interrupt between the other users activities. Final level named Scalable, tenant load balancer processes load balancing in the middle of tenants and applications so that individual users are able to guaran-

5 Table 3. The Common Functions List of SaaS First-Level Category Technical Function Second-Level Category Multi Tenant Support Configuration Scalability Standard Support Integration Security Third-Level Function name Shared Database and Predefined Database Extension Distributed Database Schema User Interface Workflow and Business Rule Customizable Data Model Metadata Set Scaling The Application Scaling The Data Standard Business Data Model Business Standard Platform Standard Development API Set Mash-up API Web Connector Multi-Platform Support Authentication Authorization Security Proof Tailored Security Policy First-Level Category Business Function Second-Level Category Market Scalability Development Communication Third-Level Function name (Open) Marketplace for Application Application Selling Business Model SLA Adaptation and Support Billing Policy Guaranteed Performance Monitoring Tools for Availability and Performance Development Toolkit Providing Application Release Process Integrated Development Platform Supporting Community for Users Partnership Policy tee independent instances same as the others. Despite of the well-defined incremental structure, it is still ambiguous within the criteria of each maturity level. For example, ASP player has not been able to measure their current availability because of the lack of detailed concepts of each service component Forrester Group s Maturity Model. It is similar to Microsoft s maturity model, but it contains six degrees of incremental development. At level 0 and 1, it can be mapped into current ASP players who handle their business manually with single or similar application to multi clients. At level 2 and 3, it can be called SaaS service because most of the vendors provide configured solutions with multi-tenant environment via packaged or Web-based distributed application. In comparison with Microsoft s model, level 5 and 6 contains custom extensions and dynamic composition so that service provider can compose userspecific applications with custom extensions in a multi-tenant environment. However, it also does not suggest the detailed incremental process of evaluation which can be applied into each service component Component Axis. The service component is the core features of structuring software business, where each component corresponds to higher or lower layers of components. We divide whole service architecture into four layers as shown in Figure 2. Data layer represents the physical and logical data structure where the data of local storage are distributed to Web-based storage. In the system layer, data and service are interconnected with standardized APIs and protocols. Third layer named service represents the ondemand technology such as Web service via Internet. Business layer consists of concrete and standardized SLA as well as open marketplace and application development guideline in order to guarantee the service quality and easy application distribution The Axis of Maturity Model We decide the axis of maturity model as the core criteria for measuring the degrees of evaluation; service components axis and maturity level axis. By using two axes, ASP players can analyze not only their ability to migrate SaaS service but also how to plan the future direction of business strategy according to their position in the maturity matrix. Figure 2. Component Layer Maturity Level Axis. In the basis of previous researches of SaaS maturity level and the common functions of SaaS service, we define our maturity levels which stand for the current situation of

6 availability for ensuring SaaS service into four levels. Figure 3 shows the general characteristics of each level according to incremental growth from ASP to SaaS. Figure 3. Maturity Level Axis In general, each level represents the fundamental foundation which is needed to evolve to next level in the model. For instance, integration level, which uses shared database and shared schema with single instance and multi tenants, cannot be achieved without support of physical resource management and logical database structure in the standardization level considering configurable option by the requirements of customers. Similarly, the maximization of utilizing distributed computing power in the final level named virtualization is depend on the mass transaction management via practical use of resources in the integration level. By understanding the merits of these incremental building process, service providers can expect some innovations such as service cross-up selling by effective mash-up process with other services as well as the assurance of service quality Maturity Model Combining with two axes we discussed above, we standardize our SaaS maturity model in Figure 4 as a set of keywords that represent the core requirements. In detail, the components on the maturity model have technical activities which consist of the structure of service component. The following levels describe the concrete figures which are mainly discussed as essential component of our SaaS maturity model Ad hoc Level. Ad hoc level is similar to current Ad hoc system with simple ASP business model so that it cannot be called SaaS platform formally and the development step of every service component stays in its initial phase. In this level, most of ASP players are concentrating on dedicated database and schema in data layer and schema in without respect to content sharing and multi-tenant environment. System layer also consist of Ad hoc multi instances which use different applications by users. The service layer has separated system integration on Web interface mainly, where the detailed functions of the services are materialized by various requirements of customers. Finally, the business process such as SLA on Ad hoc level mostly depends on the simple contraction that reflects the necessity of separated users without any concrete policies. Many service providers have failed to find the proper ways to build SaaS service model and still have stayed in this level Standardization Level. Standardization level aims to provide shared service with the discrete instances of user s application and configurable options that are same requirement as Microsoft s maturity model. We define other features of data and business layer as sharing contents and standardized service policy. In this phase, customers use shared and publicized database with dedicated data schema. System layer support configurable single instance and single tenant so that users build their service model within predefined instance that is given by service provider. With respect to customize applications, service layer also has configurable options in service software. In this way, enterprises can realize customized service process with single instance where configurable function reflects the different requirement between users. In addition, the standardized methods, which can guarantee service quality omnidirectionally, are needed in the last business level of our maturity model. One of the examples of this requirements is standardized SLA ( Level Agreement). Despite the conspicuous features which show the typical characteristics of SaaS service, it still does not support Figure 4. SaaS Maturity Model

7 multi-tenant environment, one of the most important issues of SaaS platform Integration Level. The third level of our model is represented with integration. It contains the entire feature of Ad hoc and standardization level while it focuses on actualizing multi-tenant environment. In other words, database schema is shared as well as database itself in the data layer in order to accommodate multi tenant simultaneously. In the system layer, the biggest difference is multi tenant supporting platform with single instance. It means that user s systems should use predefined common instance with simple configurable options where the various user functions are achieved by service combination such as Web service and mash-up. We called this requirement of service layer Web-based software with service connection. Lastly, business layer focuses on realizing measurable SLA adaptation with standardized scheme. In general, most of current SaaS vendors concentrate their ability to build multi tenant service process with service connection as the key factors of successful SaaS service we described above Virtualization Level. We believe that the ideal approach to reach real SaaS service is virtualization. For achieving virtualization on the data layer, entire database and its schema should be constructed upon distributed computing power such as cloud computing. It aims to realize optimized multi-tenant environment through well-defined set of metadata. In the system layer, the system space is transformed into virtual concept with load-balancing system. With the measurement of a quantity of service used, service providers can allocate the computing power dynamically to the users systems on the virtual space. Similar to integration level, a set of function is given by interlinked service combination whereas business process covers the requirements of users instead of customization in code levels. It is generally considered that the service architecture on full-soa can achieve the goals of service layer on virtualization level. Finally, business layer on this level is represented by optimized SLA adaptation. provider can use flexible and dynamic methods for measuring the amount of service used so that they ensure the optimization of SLA policy to their customers. In conclusion, virtualization level mainly focuses on maximization of practical use of resources via service modulation and encapsulation. As we discussed above, we expect that our SaaS maturity model will help individual ASP vendors understanding with respect to their present capability and preparing the service components and foundations for constructing SaaS business model incrementally. We also mapped each function in section 4.2 into our maturity model. 6. SaaS Guideline Considering the gap between the ideal figure of SaaS service and general business model of ASP players, SaaS service guideline is able to help service providers decide the service model and its development process in practical ways. We will present our SaaS service guideline roughly in terms of standardized service process and the major activities of SaaS service Major Activities of Maturity Model Assuming the role of SaaS maturity model, the abstract definition of each level is converted into technical activities with hierarchical structure which constitute the structure of service architecture. As the same ways, second level activities can be described with lower level activities. Table 4 summarizes the major activities on maturity model Guideline & Process Model Based on the service activities described above, we design a standardized SaaS service architecture and its service process model. Our service architecture is a middleware between service users and service vendors, where the SaaS service platform in the architecture consist of three parts such as data, system, and service according to the layers of maturity model. Each part of service platform guarantee the core competencies of SaaS service such as multi-tenancy, configurability, and scalability. Figure 5 describes a big picture of SaaS service architecture with the flow of business process. Figure 5. SaaS Guideline

8 Table 4. Major Activities of SaaS Maturity Model Our business process is categorized into four parts such as service development, service operation, marketing and sales, and service distribution while the direction from service development to service distribution stands for SaaS service value. Each part of business process also has detailed process in terms of the activities on maturity model. 7. Conclusion and Future Work This paper reviewed the SaaS service model and offered a practical SaaS maturity model and the service guideline with core functionalities of SaaS service. From our analysis described in previous sections, we concluded that the challenge issues of migrating current ASP service to SaaS can be solved incrementally by adapting the concept of our maturity model with two important axes. It is essential for enterprises to provide a strong and steady vision of SaaS service. However, existing approaches are still too general to design the detailed business process. We believe that the maturity model should give a concrete way of constructing a strategy to build practical SaaS service. Although there has been a variety of approached on SaaS service, there is no perfect model that perfectly satisfies the ideal of a SaaS service. Based on this research, we will begin organizing the nature of SaaS service and refining our maturity model with core competencies and more detailed requirements considering the current situation of industry as a whole. We also expect that our research will contribute to spreading the concept of SaaS service within the service guideline as well as unique strategies within some practical semantic technology in the near future. 8. References [1] Shivanshu Upadhyay, Software as a (SaaS), Oracle, 2008 [2] F. Chong, G. Carraro, Architecture Strategies for Catching the Long Tail, MSDN Library, Microsoft Corporation, April, 2006 [3] Stefan Ried, John R. Rymer, and Reedwan Iqbal, Forrester s SaaS Maturity Model, Forrester Research, 2008 [4] Dan Ma, "The Business Model of Software-As-A- ", IEEE International Conference on s Computing (SCC 2007), 2007, pp [5] Bret Waters, Software as a service: A look at the customer benefits, Journal of Digital Asset Management, Vol. 1, No. 1, Palgrave Macmillan, 2005, pp (8) [6] Mingdi Xin and Natalia Levina, Software-as-a- Model: Elaborating Client-Side Adoption Factors, in proceedings of 29 th International Conference on Information Systems, Paris, France, 2008 [7] Sääksjärvi M. et al., Evaluating the Software as a Business Model: From CPU Time-Sharing to Online Innovation Sharing, in proceedings of the IADIS International Conference e-society, Qawra, Malta, 2005, pp [8] Vidyanand Choudhary, "Software as a : Implications for Investment in Software Development," in proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07), 2007 [9] David Greschler and Tim Mangan, Networking lessons in delivering Software as a - part I, International Journal of Network Management, Volume 12, Issue 5, John Wiley & Sons, 2002, pp [10] Chang Jie Guo et al., A Framework for Native Multi- Tenancy Application Development and Management, the 9 th IEEE International Conference on E-Commerce Technology and (CEC 2007), Tokyo, Japan, 2007 [11] David C. Chou et al., Analysis of a new information systems outsourcing practice: software-as-a-service business model, International Journal of Information Systems and Change Management, Vol. 2, No. 4, 2007, pp [12] Greg Goth, "Software-as-a-: The Spark That Will Change Software Engineering?" IEEE Distributed Systems Online, vol. 9, no. 7, 2008, art. no o7003.