The marketect must consider more than customer requirements when choosing a deployment architecture. Sustainable winning solutions require the marketect to understand the capabilities, desires, needs, and short- and long- term strategies of the corporation offering the solution. Here are some of the strongest corporate influences on deployment architectures.
The sales cycle refers to the length of time and number of steps it takes a corporation to make a sale. In general, it is correlated to the price and complexity of the software. Consumer software, with low price points, simpler implementation and integration requirements, and very few decision makers (usually one or two) has a relatively short sales cycle. Enterprise-class software, with substantially higher price points, complex implementation and integration requirements, and many decision makers (usually a committee with or without approval authority) usually has a longer one. When a corporation is considering a multimillion dollar purchase, they're going to think about it carefully . I've been involved with sales that took two years or more.
In general, most consumer software is still deployed on a PC (a customer site deployment), so I won't discuss its relationship to the sales cycle further. Business software is a different matter. If you seek a shorter sales cycle, consider deploying your software as an xSP or licensing it to one that is properly qualified. The sales cycle is usually shorter and the implementation cycle should be. This is important, as once customers have made the commitment to your product they're going to want it up and running as quickly as possible. Watch out, though. Choosing this option without understanding customer influences is not going to create a winning solution.
Experience with xSPs indicates an even more complex situation than I've just described. There are times when a customer wants to use an xSP as a quick starter solution and then migrate it to their site (for an on-site deployment). I've also had to manage reverse migrations, in which customer-site deployments were migrated to a service provider primarily because of the service provider's superior infrastructure. While this kind of deployment migration is extremely rare at the moment, I expect that it will become more common in the future.
When an application provider considers offering their solution as an xSP or Web service, they must carefully consider the investment needed to create a long-term, viable offering. Companies with a service-based applications model routinely underestimate the often significant investment that is required to create a reliable infrastructure capable of handling projected demands.
You don't have to create a solid infrastructure, but then you risk poor customer service. Investment calculations must include technical resources (such as hardware and infrastructure) and nontechnical resources ( experienced data center staff, support staff, and so forth). Unless your corporation has the necessary capital and willpower to invest in a solid infrastructure, I recommend against an xSP or Web service.
Like sales cycle and infrastructure investment, cash flow must be carefully modeled . Suppose, for example, that an MSP offers a complex enterprise application to customers on a rental basis, with no minimum contract. If they are paying an annual license (common), they have a single payment due at the beginning of their year of service. If their customers are paying a rental, it may not be enough for the MSP to pay for the next annual license. Ultimately, xSPs must take a careful, sober approach to managing the cash reserves needed for successful long-term operations.
An installed base of customers who use your software on their premises can limit your ability to rapidly innovate and improve it. Customers who have invested time and money in a given release are usually reluctant to modify it. As a result, chances are good that if you go with customer-site deployment you will be supporting several releases in the field simultaneously .
This is one of the most appealing aspects of offering your solution as an xSP or Web service. By maintaining complete control, you gain considerable flexibility in such things as upgrade schedules. In an emerging market, where rapid release cycles are often required for growth, you have the luxury of upgrading as often as necessary. Patches can be quickly obtained and installed by development. Of course, appropriate care must be taken whenever you modify your own operational environment, but installing a new release in an operational environment that you control is usually much easier that coordinating upgrades across dozens, hundreds, or thousands of customers.
If you're trying to sell an application to a global company, they have the right to expect that the deployment will provide them with the necessary support and service. When they choose a customer-site deployment, they can control the level of service provided by their inhouse MIS staff, including such things as the language used to answer the phone. When considering an xSP, they may require that it provide local customer support throughout the world.
A global company may also make unforeseen technical demands on the total solution. If an application is deployed inhouse, the customer is responsible for installing and maintaining it as appropriate, subject to the license terms. If, on the other hand, you're providing the application as an xSP, you may have to install it in multiple locations around the world to guarantee such things as performance and availability. Communications networks are fast and increasing in speed every day, but for the most part locally maintained applications and data are faster.
Service, Not Price
Early xSPs competed on price. Most of them have not survived. Second- and third-generation xSPs have begun to compete on serviceconvenience, reliability, support and so forth. They have a chance to make it in the long run, provided they maintain their service focus.