The concept of customization touches the ASP market in many ways — from the very definition of an ASP, to its economies of scale, to the hosting differences between packaged applications and newer e-commerce applications, to industry-segment specialization, vertical ASPs (VSPs) and portals.
The Difference Between Configuration and Coding
Customization, the adaptation of application software to customer-specific needs, is accomplished in one of two ways:
- By coding, which refers to programming customer-specific code that replaces or complements components of the application.
- By configuration, which refers to rendering the application appropriate to a specific customer by specifying data on which the application operates, like setting an ISP’s phone number when you configure the browser on your PC. Because configuration is captured in data, as opposed to code, it survives software upgrades and other changes. Most importantly for the present context, it has negligible impact on the administration of the application.
What adds confusion to any conversation that surrounds customization is that the term suffers from semantic ambiguity. To many it is synonymous with coding; while for others customization means configuration.
| Duration of Interaction with Customer | |||
| Software Maturity | Upfront, in and out, implementation services, contract, customer-focus | On-going, annuity, glass-house, application-focus | |
| Mature: Customization by configuration (packaged apps) | Enterprise Market: Traditional consulting firms, like the Big 5. Midmarket: VARS |
ASP: QCS, BlueStar Solutions, USi, AppShop, ManagedOps …. | |
| Immature: Customization by code (Web) | Web consultancies: (Razorfish, for example) | Application Management: IIS, Aptegrity, Intira-Deloitte, IBM, Breakaway Solutions | |
| The table above divides the market for application-services into four categories, according to the maturity of the applications delivered and the duration of the interaction with the customer. The table captures the important differences between creating and managing customization — independent of type of the customization (code or configuration) involved.
Customization creation is a (relatively) short-term activity involving much knowledge of, and contact with, the customer. Application management, the central role of ASPs, is, by contrast, long-term and focused more on application technology, administrative procedures and discipline (change control, for example) than on customer business-process specifics. Most importantly, these activities are so different that they are often played by different service providers. Additionally, the table shows that, while the upfront-vs.-ongoing distinction exists in the e-commerce market, the application technology is so different that both roles are played by yet other service providers. This is not to say that ASPs cannot or should not offer professional services for implementation, or even business-process reengineering and/or e-commerce services. Examples exist of successful companies that bundle all subsets of the four service types distinguished by the table. The creation of customization is necessary, even critical, and it continues to dominate deployment time. But, it is not intrinsically or necessarily an ASP service. Customization is often provided by consultants in the enterprise market and VARs in the mid-market. Even in the small-business market, NetLedger is certifying consultants. Sometimes, the customization-creation role is played by the customer. |
|||
Coding is the origin of most deployment delays and cost overruns, and it greatly complicates both supporting and updating the application. Configuration is clearly superior — if it is adequate. Adequate is a subjective notion, but the inability to add database fields, for example, would be regarded by many as inadequate.
Independent software vendors (ISVs) continuously extend the power of configuration and tools facilitating its exploitation. For example, a recent book on SAP customization, Configuring SAP R/3 FI/CO by Quentin Hurst and David Nowak, uses customization and configuration interchangeably, and reveals that the parameters available to configure SAP reside in more than 10,000 tables that are acted on by SAP configuration tools.
Equating customization and code, Oracle’s CEO Ellison is unambiguous on the subject: He says avoid it.
“It’s a major right turn for the systems integrators and the consulting industry — moving from customization to rapid implementation of apps,” Ellison said. “But you should be worried about business processes, not writing code.” Ellison told customers and consultants at February’s AppsWorld conference.
Ellison, however, also acknowledges that Oracle’s own consultants are not entirely on-board with this strategy.
The increasing power of configuration with time makes it a signature property of “mature” applications. Applications, like SAP and Oracle, are mature in this sense, relative to younger e-commerce applications. Unlike mature, packaged applications, such as SAP or Great Plains, e-commerce applications are analogous to building a home-entertainment system from components. The wires are the analogs of customized code. Also, third-party ISVs now provide tools that manage configuration as it applies to the integration of applications from multiple ISVs.
Business Models and Economies of Scale
Customization is often presented as so fundamentally inconsistent with the ASP business model that it is not, and cannot, be offered by ASPs. The idea is that the ASP model critically depends on the complete homogeneity of service offered to its customers — the so-called one-to-many characteristic. Such sentiments are misleading.
First, they apply only to coding not configuration. Second, they confuse “economy of scale” with “increasing rates of return.” Even the “body-shop” business model of a consultancy or medical practice provides economy of scale by allowing customers to share the cost of specialized knowledge, skills and experience. But, the consultancy and the medical practice, are “body shops,” because, in order to double their business volume they must (approximately) double their personnel.
Unlike body shops, ISVs enjoy increasing rates of return, because the incremental cost of a new customer is so small. ASPs are intermediate on this scale The new-customer incremental cost is not small because of the hardware, software and personnel required, and custom code makes it somewhat larger. But, the incremental cost remains smaller than the customer’s insourcing alternative, because of the economy of scale. (The savings has been estimated 30 to 50 percent by the investment banking firm Cherry Tree & Co.) So, ASPs can accommodate an arbitrary amount of customization of the preferred form (configuration). Customization by code is open-ended. More of it can be accommodated by enterprise ASPs, like BlueStar Solutions, than by mid-market ASPs, like ManagedOps. The net of all this is that ASPs encourage configuration, but accommodate custom code when customers demand it.
Configuration Insulates
Software maturity plays an important role in distinguishing between up-front and on-going roles. Configuration tends to insulate the data center from customer specifics, and the implementer from the technical details of the application. This is less true of younger applications for which the configuration option is not yet available. This observation is consistent with the very small number of providers both capable and willing to manage e-commerce applications in an ongoing way. The greater the willingness of the service provider to get inside the application to fix it or improve its performance, the fewer players there are.
Customization and Vertical Market Segments
Should we infer that the ASP function is intrinsically horizontal, and that so-called VSPs are ill-advised? No, that inference confuses customer and industry-segment specificity. If anything, the customer-to-customer variations within a vertical segment are smaller than those from horizontal segment to segment.
The geographic reach of networks makes entire segments, and therefore large numbers of potential customers, accessible to individual ASPs. The wisdom and effectiveness of the VSP concept is more a matter of channel strategy than economies of scale. Note, however, that there are not enough ASPs to go around, at least with the degree of technical focus offered by ASPs like BlueStar Solutions, AppShop, ManagedOps and Transchannel.
Exploiting Customization: Vertical Channels
There are two basic sources of segment specificity:
- The applications themselves
- Implementation experience.
The latter relates directly to the role of separation described by the table above. That is, implementation specialists often possess the vertical knowledge and experience required to provide an effective channel for horizontal ASP services. While a few ASPs, like BlueStar Solutions, QCS and Corio make some use of this channel, those best positioned to exploit it, the large ISVs, have largely squandered this opportunity, preferring to view ASPs as a new channel for their old product, as opposed to regarding hosted delivery as a new product for their old (and often highly developed) channels. The ManagedOps/Great Plains and now Allegrix/Progress partnerships are exceptions to this rule.
The Portal Approach
Segment-focused portals, like TriZetto (healthcare), Serengeti (law) and Portera (professional services) represent an attractive way to exploit segment focus while maintaining a desirable level of application focus.
Portera illustrates several modalities. It offers its own vertical application “ServicePort” and the horizontal applications Oracle and Great Plains by subcontracting their delivery to Avasta and ManagedOps respectively. Even within subcontracting, Portera illustrates two modes. For Oracle, Portera owns the customer relationship (support, for example), while for Great Plains, ManagedOps retains its brand visibility and responsibility for support.
Customization — A Recap
Customization is an easily confused topic. Here are the key points to remember: Customization comes in two flavors and, most importantly, is available from ASPs. Configuration is preferable to generating new code from many points of view, and is continuously enriched by ISVs. Customer-specific code reduces ASP efficiency, but does not eliminate it.
Customization is less an intrinsic component of the ASP concept than a critical complement. It is necessary, even for relatively simple applications, but creating and managing it are very different activities. Customization, because it is customer-focused and predates the ASP concept, represents an important channel for ASPs. With notable exceptions, this channel remains to be exploited by ISVs. Segment-specific portals are an important synthesis of these facts of ASP life.
