Effectively Translating Requirements

Let's face it the rhetorical questions we've just posed will rarely be questions you can put directly to your client.

Although you may be confronted from time to time with projects for which the client takes full ownership of systems architecture and simply wants you to build the application (in which case, you can skip to the next chapter), far more likely is that you're expected to make the big decisions based on what the client has told you or the answers to questions you've asked him or her.

Far more likely, therefore, is that you're the one who will have to ask the questions. These questions should be designed to fill a veritable stockpile of information, which you can then use to design your environment. But what questions should you ask?

Hosting, Connectivity, Servers, and Network

The first question is "Do you have an Internet service provider?''

Unfortunately, the answer to this question is almost always yes and is also almost always followed by "And we'd like to use it to host this Web site, because Doug there is always so helpful; why, just last week he helped me get this virus off my laptop.....''

If you then ask, "And who might they be?'' and are told, "BudgetISP just $300 a year for unlimited disk space,'' you could be forgiven for having a slight sinking feeling in your stomach.

You know as a PHP professional that getting budget or even expensive third-party ISPs to host PHP applications is a bit like asking your local mechanic to tune up a Formula One race car. On the other hand, being dismissive at this early stage of the project and trying to push the client toward your preferred ISP could well prove counter-productive.

Our preferred approach is a diplomatic one; "OK, I'll call BudgetISP tomorrow and explain our requirements to them.'' When you return to your client a few days later, you can truthfully say, "Well, I spoke to BudgetISP, and I'm afraid they don't think they're going to be able to host our application.'' Your client will inevitably respond, "What do you recommend?'' At this time, you can launch into your spiel about how good Acme Hosting is, and your client will actually listen to you. Works every time.

In terms of asking questions to determine hosting requirements, the only question that needs to be asked is "What kind of traffic are you expecting, and at what times of day?'' The answer to such a question will allow you to determine not only bandwidth requirements but also the approximate number and configuration of servers you're likely to need.

Should your client not be able to easily provide you with an answer, coax it out of him or her. Ask how big the client's customer base is and how often the client will be using the platform. The figure you are trying to arrive at is the approximate number of simultaneous users likely to be in-session at any given time.

It's also worth finding out whether your client knows whether the users are likely to be on broadband or dialup, and in what rough slices; we discuss why a bit later.

Redundancy and Resilience

Rather than ask your client "Do you need redundancy?'' (which often solicits a stony look and a silent room), you should aim to get to the heart of the matter.

"Let's say the worst happened and a server blew up, taking this site down for a few hours. How bad would that be?''

You'd be amazed by the number of clients who say it wouldn't be a big deal. If this is the case, you don't need to worry too much about redundant power supplies, failover database servers, and so forth. However, you may want to then rephrase the question slightly: "What if when we got the site back up again, some of the database were lost?'' You'll find very quickly that the client's attitude changes and that loss of data would be a big deal. Keep this in mind. Redundancy to handle temporary outages is very different from redundancy of data, as the next section explains.