Client Server Production Acceptance 1996
An update on how to deploy mission-critical client/server applications
We've circled the globe (several times each) speaking about how to implement and manage client/server technology, talking with IT directors about the top two client/server issues everyone faces today. Guess what? They're the same issues we faced three years ago, only worse now. We still wrestle with cultural differences between mainframers and Unix technoids. And we still need to scale the huge walls between IT and its customers. (We covered both in previous articles.)
This month we discuss a process that bridges these two issues and resolves many of the problems facing IT executives as they implement heterogeneous, high-RAS (reliability, availability, and serviceability) infrastructure. (1,300 words)
Not just words, you need a single process that's streamlined and non-bureaucratic -- this process should promote, instill, and maintain IT and customer dialogue as you deploy and harden mission-critical applications. Communicating effectively in these distributed times is more important than ever. The process should also:
Wouldn't it be nice to combine all this into one process? We did!
We recommend you begin with the customer's application. Everything should evolve around their bread and butter. Attend to what's most important to them.
We call our process the Client Server Production Acceptance (CSPA). We've talked about it before, and improved it for 1996. It encompasses each of the eight points above, acting as the bible for implementing and supporting mission critical applications throughout the enterprise. It's 800 pieces of a 1,000-piece jigsaw puzzle that makes up a RAS-disciplined, mission-critical production computing infrastructure. The CSPA is the number one priority. We believe it's the difference between success or failure in the new enterprise.
The CSPA: Here's how it works
|CSPA questionnaire determines|
| application name||team leader||hardware||start date|
|team members||network||alpha and beta tests|
| application description||Help Desk support||database||freeze date|
|special user needs||support||distribution|
|sign-offs required||user locations||data dependencies|| installation date|
|disaster recovery needs|
The CSPA team could consist of a project lead, user/owner, data base administrator, systems programmer, and operations analyst. This is not necessarily a full-time assignment for the analyst (maybe one to two hours a week) but an position designed to promote communication between the organizations. It forces people to work together towards a common goal and instill the highest level of RAS for every mission-critical application.
Also during Phase II, technical support personnel installs the necessary hardware, software, and all supporting utilities on the server. The tape librarian is instructed to create tapes with labels and to install the appropriate Unix backup procedures. The data center's database administration people work with the application's developers to prepare the supporting database (if needed), and then relay disk partition information and database creation scripts for installation and execution by technical support.
Once fully completed, an application's CSPA is maintained by the data center.
Now let's take it one step further -- put it on-line (your Intranet server) for developers, users, operations support, and everyone else involved to use as their new bible for implementing and supporting mission-critical client/server applications.
This may sound like a bunch of bureaucracy brought over with the legacy systems, but stop and read our earlier columns. You cannot trash those time-tested disciplines -- you need to streamline them by eliminating the bureaucracy. We've done just that and called it CSPA.
If you think developing and implementing the CSPA is a huge undertaking, try selling this process to your customers. In a future article we'll discuss the art of negotiating and selling the CSPA.
If you have technical problems with this magazine, contact email@example.com