Customer Influences on Deployment Architectures

Choosing a deployment architecture that meets your customer's expectations is an important part of a winning solution. Consider the following customer concerns when making this choice.

Control and Integration

Customers vary in their perceived need to control the software system. As a reasonably sophisticated end user of software, I want to control what extensions or changes I make to my system. Thus, I don't want a managed service for my laptop because I want to be able to add or remove software as I see fit. But I don't want to control everything! I just want my high speed internet connection firewall to "work" without spending a lot of time configuring or adjusting it.

Customers of enterprise-class software have similar demands for control, expressed in a number of ways. They may want to control the system's operational infrastructure. Specifically, they may believe that the control afforded by a system operating onsite is absolutely crucial for mission-critical applications ("I know exactly who is going to answer the pager if the system breaks and how long it will take them to fix it"). Conversely, they may be happy to give control to a service provider based on their perception that the service provider can provide high-quality , uninterrupted service.

Another issue associated with control is the long- term retention and management of data. Service providers who approach this topic carefully may be able to argue that they can do a better job than the customer. Alternatively, the customer may already have sophisticated policies, and may simply feel more confident in their own ability to manage data.

It is imperative that the marketect understand the control issues that are most important to the target ASP or MSP customer. Failing to do so will prevent you from creating a winning solution. Conversely, understanding the deeper concerns that your target customer has regarding deployment will enable you to handle them with skill.

As integration needs increase so does the likelihood that the system will be deployed at the customer site. This can range for integration between common desktop applications to linking your CRM system with your inventory management and fulfillment system.

Data Security/Privacy and Peak Loads

The nature of the data manipulated by the system influences customer perceptions of an appropriate deployment architecture. Hospital payroll data, for example, may not be viewed as sensitively as patient records. As a result, the hospital may opt for a managed service solution for payroll processing but license patient record management from a reputable vendor and run it internally. A professional services firm, on the other hand, may have a strong need for privacy with respect to payroll data and require that it be managed inhouse. In the case of my home firewall, there is no data to manage, so there is no need for data security. Nonetheless, I purchased a hardware-based firewall because I didn't want to pay a monthly service fee to my ISP. You need to understand your customer's relationship to the data managed by your application, as developers can easily make poor choices based on faulty assumptions. I will talk more about data later in this chapter.

Depending on the application, it can be more cost-effective to place the application at an ASP/MSP whose equipment and/or communications bandwidth can handle peak loads that are not cost-effective to handle with your own dedicated equipment.

Costs and Vendor Confidence

There are times when an xSP (meaning either an ASP or an MSP) can offer a sophisticated, expensive application at a fraction of what it would cost the customer to license and deploy it onsite. Sometimes this is because the xSP can sublicense an application in way that provides access to smaller businesses. Other times it's because the customer doesn't have to invest in the total infrastructure needed to make the solution work.

How does your customer perceive you? Are you a stereotypical Internet startup with programmers sleeping on cots, or are you an EDS- or IBM-style systems integration firm where formal dress is still common? Put another way, would you trust your company's most sensitive data to an Internet startup that can't properly manage its internal servers' passwords? Answering these questions will help you understand why a customer may be somewhat reluctant to entrust the operation of its mission-critical system to your company's engineers .

Earlier I mentioned that failed ASPs have made customers wary about trusting their data and operations to outside parties. Be aware that your promotional materials may have to move beyond simply touting the benefits of your solution to providing access to detailed financial statements in an effort to demonstrate that you have long-term viability in the marketplace . This is often referred to as a viability test, and unless you can demonstrate that your company will be viable for the next few years , you may not win the deal.

As stated earlier, another aspect of confidence concerns the manner in which you archive and retain your customer's data. As your total solution evolves, you will inevitably change the kind of data you're storing. Reassuring customers that they can always get at old data is important to your complete solution design.

Customer Skills and Experiences and Geographic Distribution

Your application and its deployment architecture will dictate the skills and experience required by your customer's staff. If the application has relatively simple operational requirements, this isn't really a factor. It is when the application exhibits complex operational requirements that the choices become interesting.

The easiest deployment choice, from the perspective of the vendor, is to make your customer responsible for all system operation. They have to care for and feed the applicationmonitoring it, backing it up, administering it, and so forth. All of these are skills that must be learned.

If you elect to offer the application as an xSP or license an xSP to offer the application on your behalf , you or your xSP partner will have to assume the responsibility to meet the needs of your customer. Be careful, as customers often place greater demands on xSPs than on their own MIS staff. One or the other of you will have to hire a staff with enough experience and skills to create the necessary data center. You can subcontract this, and many companies do, but you still need someone with the necessary experience to manage the subcontractor.

It is important to consider the operational culture associated with the deployment architecture. If your company started as a highly dynamic, "let's just get it done" entrepreneurial venture, you may find it hard to switch to the more formal demands of data center operation. In an entrepreneurial company, for example, data center security is often lax; in an xSP, data centers require tight operational control.

It can often be easier for a customer to provide an application to geographically dispersed employees or workgroups when an xSP manages it.

As you consider how customers influence your choices, keep in mind that your target customer will provide you with the strongest requirements for a deployment architecture. Earlier in the book I talked about the dangers of resum -driven design, in which designers make technical choices in order to pad their resum s. I've witnessed the same phenomenon in choosing a deployment architecture. Investor-driven design swept through Silicon Valley in the late 1990s as many startups were capitalizing on the growing popularity of xSPs. Many of these xSPs subsequently failed, for reasons that included an inability to understand their customer's true motivations for a deployment architecture. Unfortunately, some failures were truly catastrophic. Many customers irretrievably lost crucial corporate data when these companies went under. Such losses have made corporations justifiably wary about storing key data at a service provider.

Please Disregard Those Credit Cards

One of my clients running a managed service had a rather embarrassing episode when the director of managed services operations distributed a spreadsheet that detailed the growth in customer transaction revenues . Unfortunately, he forgot to delete the worksheet that contained the complete customer contact information, including credit card numbers ! As you can guess, much more appropriate operational controls were put in place after this incident. As the vendor, you should make certain this kind of mistake never happens. As a potential customer of an ASP or MSP, you have the right to demand a careful review and audit of all operational procedures.

For this reason, and others, it is essential that the marketect choosing a deployment architecture work to understand not just customer requirements but corporate objectives as well.

When the Risk Really Is Too Great

One client of mine had created a traditional, enterprise-class system for manipulating extremely sensitive data that represented hundreds of millions of dollars worth of intellectual property. The initial customer-site deployment model was a success because customers were allowed complete control over its every aspect. Unfortunately, it came with a rather high price tag, and my client felt that they had to offer an ASP model to broaden their market. Unfortunately, they failed to understand that the factors described above are not isolated from each other. Instead, each is considered and weighed against another in the context of a winning solution.

In this specific example, the extreme sensitivity of the data meant that my client would have to build a substantial infrastructure and ensure that the data center was operated under exceptionally stringent conditions. However, they had neither the organizational nor operational maturity to undertake this task. In addition, many of the target customers were global companies who required 24/7 access and support. Preliminary research also indicated that customers didn't want an ASPthey wanted an MSP. Sadly, my client chose not to invest in the additional infrastructure to create an MSP until the new model had proven successful.

I urged my client to avoid offering the ASP and to create a truly winning solution. To my dismay, they went ahead with their plans and introduced the new model. It failed, and the company eventually went bankrupt.