The fictitious Trumpet Company, which supplies Direct Stream Digital (DSD) sound conversion software to manufactures of music CDs, has hit a road block in their efforts to diversify out into the revenue based software services marketplace. Realizing that a broader market of amateur recording studios exist that could benefit from higher sound quality recordings, Trumpet needs to identify a go to market strategy, pricing models and a delivery medium that would allow Internet access to its software.
Unfortunately, their existing business processes do not easily migrate to the Web. In fact, they need to come up with an entirely new pricing model. They are also uncertain as to how they will address the complexities of hosting their software assets for sale, especially since they do not have the expertise and infrastructure necessary to support such an undertaking.
In my previous column, I described how the critical mass threshold and a common vernacular presented obstacles for adoption (see Resources). In this installment, I will point out some additional inhibitors to making money on the Web through software services.
Assuming that industry vendors have addressed the hurdles associated with a deployment platform for fee-based Web services (to be discussed in more detail in my next entry to this column), a company like Trumpet must then turn their attention to the business of providing or obtaining hosting services. Since Trumpet's main business forte is outside the scope of application hosting, they would most certainly seek out a service provider.
International Data Corporation (IDC) recently published an analysis of the service providers marketplace. In their report, IDC described a broad set of categories for service providers known as xSPs. The "x" in xSP differs according to the fundamental value of the service offering and implies a particular set of competencies that distinguish one type of xSP from another (see Table 1). IDC predicts that the xSP model will grow significantly in the coming years.
Predictions pertaining to the xSP market are relevant to the domain of fee-based Web services for a number of reasons. First, the concept of a service provider (independent or a software asset mall) correlates to at least one of the IDC categories, namely the application service provider (ASP). Next, all xSPs need to deal with the issues of service provisioning, customer acquisition, capacity planning and forecasting. Additionally, xSPs must also be flexible to address a variety of pricing models and billing policies.
While these issues are common to any well-run business, xSPs must make sure that their suppliers of hardware, software, professional services, and other xSP services are up to the task of delivering a complete solution optimized for the xSP world. Here then is another inhibitor of fee-based Web services, namely the ability for an ASP to effectively expose the services that they offer.
| xSP Type | Description | Offering value proposition |
| PEP | Process execution provider | Accepts responsibility for process execution (that is, the PEP makes decisions and/or recommendations and executes on behalf of the customer) |
| PSP | Process support provider | Accepts responsibility for process support but customer retains responsibility for execution |
| CSP | Content service provider | Provides access to content |
| ASP | Application service provider | Provides access to applications automating functions or entire processes |
| DESP | Development environment service provider | Provides access to development environment software that supports software development-related functions or entire processes |
| SISP | Systems infrastructure service provider | Provides access to systems infrastructure and/or management that supports infrastructure-related functions or entire processes |
| NSP | Network service provider | Provides access to communications and network services |
Independent Software Vendors (ISVs) represent a division of IT vendors. As ISVs increasingly become suppliers of fee-based Web services they can become key catalysts for the industry to surpass the critical mass threshold. The emergence of xSP models for service delivery has implications for companies like ISVs who offer all types of software via a conventional right-to-use license with associated annual maintenance contracts. Opportunities are plentiful for ISVs that deliver applications, development tools, or infrastructure software as a hosted service. By definition, the xSP is the company that "owns" the customer relationship. As a result, many ISVs may choose to become the xSP to build and maintain brand equity by establishing direct contact with the end customer as the service provider. In our terminology this would mean that the ISVs becomes the Independent Service Provider (ISP). However, a merchant-centric approach to the design of a software asset mall (SAM) could still provide ISVs with the needed customer ownership while deferring the complexities of the xSP business to the SAM.
As I work with customers, Enterprise and ISVs alike, the adoption of Web Services from a technical perspective is not a complex problem. The real challenge has been on the business side of the adoption effort. Once a company has defined a software service and enabled it for use in a service oriented architecture using the Web services technology stack, the difficult business inhibitors arise like:
- What revenue models will be applicable for the service?
- How does the service provider address pricing?
- Does the service provider host their service or outsource the hosting?
- How is billing handled?
Generally, the migration of software services from reusable loosely coupled application building blocks to externally available fee-based Web services will take time. Asset owners and service providers with need to come up with viable business cases that redefine concepts such as:
- Support structures -- In the past, a software company's support organization worked with its customer's IT help desk. Now, the service provider is the customer's IT help desk. Since the 24x7 support model is the de-facto standard for the Web, asset owners will require service level agreements guaranteeing that their Web service will be up and running or the service provider doesn't get paid.
- Pricing methodologies -- Software companies that are used to the traditional up-front license/ongoing maintenance pricing structure could have difficulty adjusting to an annuity-based service-fee pricing. New compensation models based on growing monthly recurring revenue will need to replace existing up-front commissions currently being paid to sales people.
Additionally, corporate cultures can also serve as an inhibitor. Point and case is the migration to e-sourcing. As the adoption of e-sourcing will lead to new business models for software providers, hardware vendors, services companies and their customers, change to corporate cultures will need to be managed. The e-sourcing benefits of rapid access to new technology and business processes, with less cost, fewer resources and lower risk are enticing, but few companies (if any) can easily flip the switch. Change will take time, but it is usually worth it.
So to recap, I have presented a few inhibitors to the adoption of fee-based Web services. To solve the supply and demand problem developers must reach a critical mass of software services, and the quickest way to do so is to leverage reusable assets from ISVs as well as legacy software within vertical enterprises. To speed up this race to the critical mass threshold you must also settle on a common language for describing the business of software services. Furthermore, business entities must be able to change culturally to define and accept new ways of doing business, such a pricing methodologies and customer support structures. For those businesses that seek to defer the hosting of their software services to service providers, they must manage closely all links to the customer relationship and remain the "owner" of the customer.
In my next column, I will focus some catalysts that are critical in helping kick start the adoption of fee-based Web services.
- Read Part 1 on Fee-based Web services.
- Learn about SOAP, WSDL, and UDDI.
- Read about Metering and accounting Web services.
- Read about other business Web services.
- Check out the tools in the Web Services ToolKit on alphaWorks.
- Read about Dan's description of Dynamic e-business and the models that it supports.
A 13 year veteran of IBM, Dan Gisolfi holds a Masters Degree in Artificial Intelligence from Polytechnic University, and a BA in Computer Science from Manhanttanville College. Prior to 1999, his career was focused on software and product development ranging from Expert Systems, OS/2, and Secure Internet Payment Systems. As a member of the jStart (jump-Start) Emerging Technologies Team, he keeps his hands dirty in both the business and technical aspects of customer engagements. From Business Development Manger and Evangelist to Solution Architect and Contract Negotiator he gets to wear many hats. As jStart Team Lead for Web services, he is helping IBM drive the adoption of this emerging technology through real business solutions. He can be reached at gisolfi@us.ibm.com.
