Introduction to SaaS Series: SaaS business model

1 Introduction

A lot of money, but can not find the seeds of money, will become a career. As a professional software person, we all seek to use an efficient and economical process to build a working, useful product.

________grady Booch

The fundamental goal of the enterprise is to "lawfully earn as much profit as possible and maximize the overall benefit of the enterprise". All the specific goals and actions of the enterprise (such as research and development, marketing, etc.) are carried out around the fundamental goals and cannot be incompatible with the underlying objectives. The SaaS business model pays more attention to the economic profits created by software as a service to the enterprise.

2 new transformation of SaaS business model

The transformation of the business model will involve the transfer of the "ownership" of the software from the customer to the external supplier, the redistribution of responsibility for technical infrastructure and management, such as hardware and professional services, from the customer to the supplier, the cost of providing software services through specialization and economies of scale, and lower the minimum cost of software sales, Work for the long tail market for small businesses.

L Consider the software as a service

In order to transform from providing on-premise software to software-as-a-service, software vendors should change their thinking in three interrelated fields: one is business model, the other is application architecture, and the other is Operation structure.

　　

Figure 1 SaaS three related domains

• Transforming business Models

Transforming the business model will involve one or more of the following:

² Transfer the "ownership" of the software from the customer to the external supplier;

² Reassign the responsibilities of technical infrastructure and management, such as hardware and professional services, from customers to suppliers;

² Reduce the cost of providing software services through specialization and economies of scale;

² Reduce the minimum cost of software sales and work for the long tail market of small businesses.

In order to realize the advantages of the SaaS concept, both the supplier and the customer should have a mindset transformation, and the supplier should also help the customer to achieve this transformation

L Long Tail Sales strategy

Author Chris Anderson, in his "long tail" article in the October 2004 issue of Wired Magazine 3, describes why online retailers such as Amazon.com are in a good position to fill the gap in demand for traditional retailers who are struggling to deliver services at low cost, thus making " Long tail "This new concept is easy to understand.

　　

Fig. 2 Long Tail theory

The requirements of various commodity categories, such as books and CDs, often conform to the "Power law distribution". In this case, many books, CDs, and DVDs are published each year, but only a handful of them can be a long-term bestseller, and others tend to be mediocre, long-tailed publications: a large number of publications are only interested in a small proportion of people with special interests, with little or no thousands of copies.

Traditional entity-based retailers are committed to selling the most popular publications because it is not possible to inventory millions of books, CDs, DVDs and other publications. But instead of worrying about inventory issues, online retailers can deliver directly to customers from major warehouses around the world, even if the sales of publications are less popular, and their advertising and sales costs are unaffected, as well as popular publications. So the long tail category of low-volume publications can also earn a lot of revenue.

Large physical bookstores can store 130,000 different kinds of publications on their shelves. And Anderson points out that most of Amazon.com's book sales come from 130,000 popular publications, in other words, most of the books sold by Amazon.com are not available in traditional bookstores.

The rationale behind the long Tail theory is that as long as the channels of storage and circulation are large enough, the market share of products that are not booming or poorly sold can rival or even greater the market share of the few hot selling products. That is, many small markets converge into the market energy that can rival the mainstream big market.

　　

Fig. 3 economic model of Long tail theory

From the above can be seen, and the 20/80 law is different from the long tail theory, the role of "tail" can not be ignored, operators should not only focus on the role of the head. Long tail theory has become a new economic model, which has been successfully applied in the field of network economy. Google, for example, effectively leverages the long tail strategy. Google's AdWords ads make it easy for countless small and medium-sized businesses to deliver online advertising, while traditional online advertising is just the area where big businesses can get involved. Its AdSense ads also make a large number of small and medium-sized websites can automatically get advertisers to run ads. As a result, AdWords and AdSense bring together tens of thousands of small and medium-sized businesses and small websites that generate huge value and market power to rival the traditional online advertising market. If Google is just focusing its attention on 20% of big companies (like many web-site advertising strategies for Web portals), it's hard to create the current brilliance. Similarly, online retailing giants Amazon's products are all-encompassing, not just those that can create high profits, and the result is that the Amazon model is successful, and those that ignore the long tail and focus only on a few bestsellers are not doing well.

Complex enterprise software solution providers face similar market conditions.

　　

Fig. 4 The 2/8 law of the long Tail theory

Unlike simple packaged software, enterprise software needs to be tailored to the needs of different customers, which may include on-site installation, Vendor service team onsite service, and often require specialized server hardware and support personnel to manage. The cost of providing these specialized services will increase the minimum cost of vendor sales software to a certain extent. As a result, this software is often intended for large enterprises, and only large enterprises have the strength to pay for specialized services. However, the number of small and medium-sized businesses with the same needs is much larger than the number of large enterprises that buy enterprise solutions, but they are struggling to afford high costs.

　　

Fig. 5 "Long tail" of long tail theory

SaaS vendors can eliminate maintenance costs and leverage economies of scale to integrate customer hardware and service requirements, providing a much lower cost solution than traditional vendors, which not only reduces financial costs, but dramatically reduces the need for customers to increase IT infrastructure. As a result, SaaS vendors are able to market for a new customer base, which is beyond the reach of traditional solution providers because they simply cannot offer low-priced services to this segment of customers.

Effective market work for small customers requires a mindset transformation of suppliers who are accustomed to marketing through interpersonal communication and traditional manufacturers and customer relationships, and most suppliers have difficulty in providing personalized services to larger customer groups at lower prices in large-scale markets.

For SaaS Marketing, like selling mobile ringtones or music download services, customers should be able to access your Web site, become a paid user of the services you provide, pay by credit card can start to enjoy the service, the whole process without the supplier of human intervention. This is not to say that you do not need to have a wide range of large customer base to do interpersonal work. However, the design, marketing, supply and customization of sales work is automated from start to finish, so we can not only provide automation services, but also simplify the work of your support staff, thus eliminating the need to help customers to complete related tasks.

3 "à la carte" mode

What is a "à la carte" model? We are used to eating in restaurants and ordering before eating. The waiter took out a menu to give us a order, we ordered a dish according to the name. This most familiar way of application in software development will be a great innovation. We refer to each of the smallest user function modules that can be run independently as a "dish." A system is divided into several dishes, several dishes can be arbitrarily assembled into a system.

SaaS provides the customer with a menu when providing a functional service, the customer is ticked on this menu, and the SaaS platform system automatically provides a table of dishes according to the customer's choice. This table dish appears in front of the customer in the form of a portal website. Let users seem to see a system for their own production, in fact, software vendors do not need to invest any other cost. This is done with little or no manual computer to automate. If you have 10 dishes, how many systems can you assemble? What about 20 dishes? This 100 dish is almost all about the software.

3.1 "à la carte" model overview

Definition of "dish"

"Vegetable" means the smallest functional unit which can be independently run (relative platform) according to the functional category of the software to meet the user's needs and be selected by the user. We can intuitively interpret it as a small application system, but it is too small to be divided. The composition of the "dish" mainly includes the user's function page, the implemented Code collection (class, package, component library), data table, related documents and configuration files, etc. (from a development perspective).

In terms of software, "vegetable" is a functional component. A separate functional component is a dish "dish".

According to the idea of the dish to divide the software function, here is to pay attention to what is the food? How to make a "à la carte" mode? With the "dish", we can be "a la carte", "dish", "processing dishes" to meet the needs of users.

"À la carte" is to let users to point, software manufacturers if there is an existing "dish", these "dishes" do not need any modification of the intuitive assembly can meet the needs of users. This is the best way for software vendors.

But not so the user's needs can be satisfied through the "à la carte" to meet, not to come out of the dishes to consider the configuration, through the "dish" way to achieve, users want to eat "egg fried rice" This dish of fast food, you are to re-fry the user a new dish or the early scrambled eggs with the existing rice quickly to the user the so-called "matching vegetable" means the latter.

Dishes do not come out, that only to operate, which needs to be in the original function through the code to modify and supplement to meet the needs of users, this is "processing dishes."

Since everything is based on the idea of "vegetable", then it doesn't matter system, subsystem. In fact, as long as the development of "food", other systems are through the "à la carte", "with vegetables", "processing dishes" to achieve.

Therefore, the "dish" as a minimal system, "vegetable" development includes the entire process of the software life cycle, from the requirements analysis, design, implementation, testing to maintenance and other processes. The emphasis here is that demand analysis is just about a plate of "food" to be analyzed, and so is the design. That is, the requirements of the analysis of the contents of the specification can only analyze a dish, "Architecture Design Manual", "Detailed design instructions" are designed this dish. The relationship between the dish and the dish is realized through the interface. The dishes are independent and the documents are independent. The people who are involved in the development and design of this dish are also relatively independent. This breaks the traditional concept of dividing software by system. Strictly speaking, the so-called "people", "wealth", "things", "things" system all do not exist. There is no so-called ERP, no so-called HR, no so-called OA and so on. To form these systems, the solution is to achieve the solution is also the use of "a la carte", "dish", "processing dishes" to achieve the ultimate goal.

"À la carte" mode The fact is to use the least amount of development to achieve as many user software as possible through quantitative effects to achieve scale. The SaaS model effectively combines the "à la carte" model, which will greatly reduce the cost of software vendors ' development, thus improving software utilization and then generating economies of scale.

For example, we used to buy things in the supermarket. Supermarket is a hypermarket, it provides all kinds of tricks of its entire commodity, the price is relatively reasonable. Why do customers like to buy things in the supermarket? One of the reasons is that there are many varieties to choose from. Customers can choose their own. The SaaS model has developed into a mature stage and also translates into a big software supermarket. A large number of software companies will be mergers and acquisitions, under the Unified coordination of Division of Labor to complete a software supermarket of a job. Theoretically, all systems are assembled by components. Our development is divided into parts of the production and assembly of these two important links.

Components are fully represented in the traditional manufacturing industry. It's easy to understand. But the software industry is completely different, software is not visible to the great flexibility of the intangible high-tech material. And the dish is visible controllable granularity easy to grasp. Let's look at the composition of the "à la carte" mode 1:

　　

Figure 6 Composition of the "à la carte" model

The "à la carte" model is made up of four parts

1) Origin and division of vegetables: According to the source of demand to define a variety of "dishes."

2) The realization of the dish: by the configuration development mode, the modification pattern and the development pattern produces "the dish".

3) Food storage: Put a good "dish" into the component library.

4) Assembly: According to the user's needs, the "dishes" assembled into the product for users to use.

3.2 "à la carte" mode development process

　　

Figure 7 Development process of "à la carte" mode

The "à la carte" model development process is developed as follows: component belief, component analysis, component development, component warehousing, product release, product testing, internal acceptance, product delivery, product maintenance 9 stages, including the following 11 sub-processes:

1) Source of demand: Collect the needs, expectations, constraints and product component requirements of the stakeholders.

2) Demand analysis: Refine customer requirements, develop product and product component requirements.

3) configuration mode: Quickly develop functional components with a custom tool.

4) Modify the mode: Develop the functional component by modifying the source code.

5) Development mode: Development of functional components through software program development methods.

6) Component library: Management and maintenance of functional components.

7) "À la carte" (product assembly): Assemble functional components by project business requirements from the component library.

8) System test: Verify the correctness of the system from the point of view of requirement.

9) Acceptance: The product is confirmed by the customer and delivered to the customer.

10) Maintenance: The management process of the product maintenance stage.

11) Software Problem Management: Document and manage various software problems found during software project development/maintenance.

3.3 Sources and analysis of demand

The process of demand sourcing consists of 8:

　　

Figure 8 Source of demand

L Source of Demand channel

1. Sales, 2. Market, 3. Prospective clients, 4. Contract, 5. Company positioning, 6. Industry agreements

L Demand Collection

Collect a variety of needs, including industry standards, industry solutions, consulting service information.

L Demand Consolidation

The original material of the "dish" formed after the evaluation was determined by screening and summarizing.

The process of demand analysis consists of 9:

　　

Figure 9 Requirements Analysis Process

Functional component definition: According to the requirement source, according to the "vegetable" standard divides and defines the function component.

Feature Components Checklist: Lists the functional components in a template format and names and numbers the functional components. This checklist is the basis for functional component warehousing and system testing and acceptance.

Component Library Lookup: If this feature component is already in the library, it can be used directly, skipping the development route.

Identify development routes: analyze and evaluate the requirements of functional components, identify development methods, select the fastest and most suitable component production line in configuration mode, modification mode, and development mode.

3.5 Component Libraries

　　

Figure 10 Component Library

L Component Library Definition

A component library is a warehouse used to store functional components. A stock store of a logistics company. This warehouse is often implemented by a database. Functional components are stored in the database according to their classification and regularity. According to the user's needs can be assembled into different products packaged to the user.

L Component library Design

A reasonable and practical component library is the key to "ordering". The invisibility of software increases the difficulty of component library design. The merchandise in the supermarket is very fastidious, it is an art knowledge.

The design of component library includes the framework of component library, component, logical structure design, technology realization, physical structure, operation interface, definition of inbound and outbound standard, interface, class relation and so on.

L Component Library Development

Implement the function of the component library, including the establishment of the data model, the Operation interface, the way of warehousing, searching and matching function code writing and unit testing, assembly testing.

3.6 Product Assembly

Product assembly is to extract the functional components from the component library according to the Customer function list and assemble the product to the user through assembly process. At this point the customer may be the company's product department.

Assembly Checklist: Product packages, patch packs, Platform Foundation support components, and more.

　　

Figure 11 Product Assembly flowchart

3.7 System Testing

L Prepare

1. System test Plan: Test scope (content), test method, test environment and related tools, test completion criteria, personnel and task schedule.

2. Design the system test case: The test case should be able to fully validate the defined product requirements guest functionality.

3. Peer review.

4. Prepare the Test tool.

5. Establish a test environment.

L Test

1. Obtain integrated product components for all deliverables, and test the product against the requirements, based on the system test plan and the system test case, by integrating the tested products.

2. Manage the defects/problems found in the test according to the software problem management process;

3. Compare the actual results and expected results, identify the unmet needs of the product, identify test methods, standards and environmental issues;

3.8 Acceptance

　　

Figure 12 Acceptance process

L Acceptance Preparation

1. The developer, the client side and other project related parties, consults together, establishes the product acceptance group, and refers to the acceptance responsible person.

2. The acceptance team formulates the acceptance plan and obtains the approval from both sides.

L Product Confirmation

1. Provide training for members of the acceptance team

2. Product Review

3. Acceptance Test

L Hold Acceptance meeting

1. Confirm that product review and acceptance testing activities have been completed before the meeting;

2. The acceptance Test team provides: Product review records and acceptance test reports and other materials;

3. In accordance with the acceptance meeting arrangements, to convene acceptance meetings;

4. According to the evaluation results and the defined acceptance criteria, the acceptance conclusions are drawn and the acceptance report is formed.

5. If the product requires re-evaluation, the developer should give corrective action, the two sides on the time for re-acceptance

6. Consultations.

L Product Delivery

Release products that have passed acceptance.

3.9 Delivery of products

Deliver the product to the customer in accordance with the delivery method and delivery schedule defined in the acceptance plan.

　　

Figure 13 Product Delivery Process

L Packaging Design

product CD, CD cover, installation instructions and other design.

L Product Packaging

Product packaging, including database structure, database building files, compiled program files, configuration files, auxiliary

Files, page files, user installation manuals, user manuals, patches, platform support files, and other tool files are packaged as installation files.

The packaged files are carved into CDs or placed on the Web for download and installation.

L Product Implementation

Packaged documents for implementation personnel to the customer site installation implementation.

3.10 Maintenance

　　

Figure 14 Maintenance process

L Prepare

After the product through acceptance, the official release, product related parties (such as development Department, sales department, product Department, technical support department, customer side, etc.) should negotiate the establishment of product maintenance team, and designated maintenance responsible person. The composition of a product maintenance group member can be a member of a Product development project group, or it may not be a member of a project group.

l Develop Maintenance Implementation plan

The Maintenance Manager is responsible for the preparation of the maintenance plan.

L Implement Product Maintenance

1. Identification of maintenance requirements

2. Assessment of maintenance requirements

3. Implementation of Maintenance

4. Follow-up work

If you need to deliver the post-maintenance product to the customer, update the affected customer software, the process should strictly follow the configuration management program files, after approval by CCB, change the operating baseline.

3.11 Software Problem Management

　　

Figure 15 Software Problem management process

L Discovery and registration of problems

During the development or maintenance of the software project, the development, integration or testing personnel should immediately fill out the Software Problem Report form and submit the Software Problem report form to the problem manager assigned by the project.

L Analysis and classification

Confirm the type of the problem according to the development stage of the introduction problem;

The project manager is the final decision maker when the assessment is made and if there is a dispute as to whether or not the resources and duration of some issues are modified;

Specify the responsibility group or the person responsible for the problem modification and prioritize the problem resolution.

L Issue Release

According to the results of the analysis, the problem management personnel to distribute and follow up;

Distribute copies of the software problem report to designated responsible departments or personnel;

Follow up the problem, maintain the software problem status registration form, record relevant information,

L Problems and solutions and validation

The responsible department or personnel to further analyze the problem report, solve the problem, fill out the "Software Problem Report form", modify the status of the software problem status registration form.

If the problem cannot be resolved, you can choose not to give a fix in this version, shelve the problem. It must be approved by the project manager.

If the revision of the issue will cause changes to the configuration baseline, the process of the change should follow the configuration change Management sub-procedure in the Configuration Manager file.

After the problem has been resolved, it must be tested to verify that the problem is closed.

4 Enhancing the business value of SaaS through a "à la carte" model

4.1 "à la carte" mode differs from component development approach

In fact, the development of components in the software industry, the idea of component development, there are many companies engaged in this work and achieved good results. But the failure was determined quite a bit. The reasons for its failure are manifold. One of the main components is the granularity of the assembly/component is not well grasped. This can be large and small abstract things with different views of different people to divide there will be a variety of disagree with the result.

But the "à la carte" model is different, and the dishes are visible. It is much less difficult to divide and develop. The food is for the end user to eat, but not the component is for the software practitioners from their own use. The dishes are functional and stand in the user's position to look at the problem. The grain size of the dish is thicker than the component. In fact, the component can be regarded as the raw material of constituent dish more vividly. Defining and developing raw materials is a great challenge.

4.2 Correct use of "à la carte" mode

"À la carte" mode in the traditional software industry also adapt, but software companies in this area of research is not enough, the actual operation of a lot of difficulties, play a role is not obvious. How to solve these problems, here are a few suggestions:

1. Set up a panel of experts to plan, define "dishes" and conduct relevant training, guidance and norms in a holistic and global way.

2. Define and develop the configuration mode, modification mode and development mode.

3. Break the traditional project-oriented development model and set up a "vegetable"-centered group. But it can also be a group of large groups, the large group is only the management and coordination. The group is the most suitable for 3 to 5 people, and the group of 3 to 5 people is easier to communicate and manage, and the development efficiency is very high.

4. Standardize and define the "dish" development model, including the rapid response from demand to design, each dish "dish" supports parametric customization, data model customization and workflow customization.

5. Configure the management to gradually implement the point "dish" mode. Can be automatically and quickly assembled into different application systems through "dishes".

6. Arrange the layout of the SaaS mode, point "dish" mode effectively with the SaaS, realize the civilian software, take the road of Software supermarket, set up the software service operation platform.

7. The original system is divided into stages according to the "vegetable" standard redefined and reconstructed, attaching importance to the interface design.

8. Provide customers on-line rapid ordering components, automatic configuration of the Assembly Customer portal system, the platform provides a unified custom portal entry, and the actual usage of flexible billing.

9. The components under the SaaS are fragmented, and in order to avoid fragmentation of components, they can be used as a mashup of topics such as industry applications.

The large number of components under the SaaS, massive multi-tenant architecture, requires a scalable deployment platform and monitoring mechanism.

11. Components are shared and combined at the data, service, and interface levels, providing infrastructure such as data bus, service bus, and mashup server to provide a scalable industry data model; The SaaS component must be customizable and extensible.

12. Customers should be greatly simplified ordering, use of products, to provide a unified page style and user experience.

13. Research and innovation "vegetable" extensibility, the development of source code, can provide two times.

14. Support on-line testing, deployment of applications, component facilities and enterprise internal IT systems are well connected, customizable Enterprise Portal.

15. The development of component-oriented libraries is completely decoupled from customer-facing development.

4.3 SaaS model facilitates the early arrival of software supermarkets

Commercialized supermarket shopping style has been popular, everyone has the right to enter the supermarket shopping. Business is not necessarily the producer of goods, the business of supermarkets to undertake the procurement and sales of goods responsibility, which is not only a great convenience to provide customers with inexpensive goods, but also let themselves earn a bowl full. The fact that we were in the early 90 or in the small grocery store or department stores pointed to the goods called to us, so that there is no more choice of scope and can not guarantee the quality of goods, prices are difficult to drop down, the appearance of large supermarkets to improve the quality of life, everyone enjoy shopping fun. Software is a commodity, how can the software not go to the big supermarket? If you just sell the software as a disc, it's not a supermarket, no matter how many types of software you have, or how many discs you have. Because that's a whole set of software.

We can completely subdivide the software into modules, modules and modules can be combined, the user just according to their own needs to purchase a system composed of multiple modules, rather than buy financial software and buy OA system. A lot of software facts use less than 20% of the functionality. As a result, we are able to meet the real needs of our users through a la carte model, which we end up providing to our users with a system that covers all the functional needs of the user.

In this way, we open a software supermarket on the Internet, let the user select the function according to the module, and then through the combination control method to form an independent system, really do this will quickly let the software to civilian, popular, everyone can enjoy the software is everyone can enjoy the same food. The SaaS model will quickly drive the early arrival of software supermarkets.

5 Summary

The SaaS business model and the traditional industry business model are all to promote their products, occupy more market share, and ultimately achieve more economic profits.

This chapter describes how the "service-oriented" SaaS model understands software in terms of business thinking and enhances the business value of SaaS through a "à la carte" model. Through the configuration mode to meet the user's custom requirements, from the grasp of more users. Through the establishment of brand and promotion, clear who is their own customers, marketing what products to customers and other strategic heights to market SaaS software, to create better economic benefits.

Introduction to SaaS Series: SaaS business model