Client Server Production Acceptance 1996 An update on how to deploy mission-critical client/server applications

October  1996

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)

Mail this article to a friend

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:

1. Provide flexibility This process should cater to your customers, and it should be flexible in order to meet the needs and requirements of individual end users (i.e., backup times, RDBMS selection, maintenance schedule, hardware selection, and so on).

2. Be cost effective It should provide a high level of service at a competitive rate.

3. Provide high reliability and availability Remember applications running on those old 3270 terminals? They should be just as reliable running on PCs regardless of the backend computer. Regardless of how much mainframe bashing went on in the 80s and still in the 90s, when users came to work their system was always available. They expect nothing less and should receive nothing less.

4. Establish a Service Level Agreement An agreement (not a contract) outlines expectations between customers and IT.

5. Implement a minimum/sufficient set of standards and guidelines To control infrastructure costs you need to deploy technology with standards and guidelines. The key words are minimum and sufficient.

6. Spell out exactly who does what Distributed computing is so much more complex than host-based computing it's critical you define everyone's roles and responsibilities during application deployment (i.e., application developers, user owners, the production support staff, help desk, and so on).

7. Establish a runbook This is old mainframe terminology but is still valid in today's enterprise. A runbook spelled out the operational support requirements for each application (i.e., scheduling dependencies, special backups, print distribution, and so on).

8. Include a deployment checklist A set of questions to answer. (Where will the server be located? The number of users? Where are they located? Where is the data coming from? Where is it going to?)

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

Phase I -- notification

A customer of IT services or an application development person (more so the latter on behalf of the customer) will notify the production support organization that they are designing/developing a new mission critical production application. The notification should be established using an e-mail alias. At this time the CSPA questionnaire is forwarded back to the developer.

CSPA questionnaire determines
Application	Personnel	Requirements	Milestones
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

Phase II -- resource planning/communications

An analyst (who could be the data center operations analyst) assigned to the project reviews the questionnaire and, based on the application's needs, formulates an appropriate CSPA team. The operations analyst works with the technical support staff (consisting of systems programming and production control) to define data center space, equipment, and costs to support the project. The operations analyst also works on the CSPA template with the application's project leader. The project leader orders needed equipment during Phase II.

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.

Phase III -- implementation period

Appropriate system management and data center support tools implemented, the application and all data center support systems are brought on-line and tested on subnets (consisting of rigorous stress testing) for as long as it takes to ensure that the application can run reliably in a production environment. Once the application is considered production, the CSPA is signed-off by the team and then placed on the intranet server for all to use.

Once fully completed, an application's CSPA is maintained by the data center.

• Database administration Maintains and upgrades the database and software, making any needed system changes such as adding dump devices, increasing database sizes, and analyzing and reconciling maintenance errors.

• Production control Manages job scheduling, restarts applications, and makes crontab changes.

• Tech support Maintains the operating system software and hardware, formats and repartitions disks, installs unbundled software, and maintains and configures system security and network services.

Phase IV -- maintenance and support

Each time there is a new release of an application, the production control group assures that the CSPA is adhered to and updated.

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.

Also this month in SunWorld Features: News & Views: Tech Expertise:

Click on our Sponsors to help Support SunWorld

What did you think of this article?

-Very worth reading -Worth reading -Not worth reading

-Too long -Just right -Too short

-Too technical -Just right -Not technical enough

Comments:
Name:
Email:
Company Name:

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-10-1996/swol-10-unix.html
Last modified: