Web-Centric Production Acceptance (WCPA)
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You've recruited, hired, trained, and retained the best software engineers, architects, and managers in the industry. You've established a world-class software development organization for these engineers to work in. You've bought the best software development tools money can buy, and each developer has a top-of-the-line workstation and a private office. Your glass-house computer room is filled with high-powered file server, DBMS servers, and the latest networking gear. Your software development team has worked for months to prototype, design, implement, and test a web-centric application, ensuring that every user requirement is met. You've worked with the IT operations staff to put in place a service-level agreement (SLA). Your long-overdue vacation plans are looming on the horizon and your project seems nearly complete.
Surprise! There's still one more task to do before you can claim a successful web-centric software development project—a very big task. We call it the web-centric production acceptance process (WCPA).
The WCPA is our most important process. Implementing a WCPA process often makes the difference between the success and failure of a web-centric software development project. We have worked with many Fortune 500 companies who have attempted to deploy web-based applications, some successfully and others ending in project failure. Many of the failures were due to the absence of a process to deploy, manage, and support distributed, web-centric applications and their supporting infrastructure across the enterprise. The WCPA started life as the Client/Server Production Acceptance (CSPA) process, described in Building the New Enterprise: People, Processes, and Technologies (Prentice Hall PTR, 1999, ISBN 0-13-079671-9). We have modified the CSPA process to specifically address the requirements of developers working on web-centric applications. Like the CSPA, the WCPA is our way of transitioning applications from development to production—that is, deployment. It's also our way of making sure that customers get the same reliability and security for their globally deployed intranet, extranet, and Internet applications as they did with their mainframe or client/server applications. The WCPA is our way of improving and maintaining IT and customer dialogue for systems support and development. Just as web-centric is a revolutionary computing paradigm, the WCPA is our contribution to a new age of IT customer relations enabled by personalized, web-based communications.
The WCPA Questionnaire
The WCPA process starts with a questionnaire that helps the software development team, the IT operations team, and the end user customer to assess the readiness of the complete environment surrounding the deployment of a new application. When used effectively, this questionnaire is filled out during the entire development process, rather than waiting until immediately prior to deployment. The first section of the WCPA covers the operational environment in which the application will be deployed:
- Hardware (CPU, memory, disk, network)
- Operating system
- Disk layout (RAID level, connectivity, etc.)
- Filesystem table
- Database requirements
- Job/batch schedules
- Error messages and handling
The second part of the WCPA questionnaire describes support requirements of the application, including the following:
- Interdependencies of the application on other jobs and systems
- Capacity planning
- Systems availability (online availability, backup windows, etc.)
- Testing plan (alpha, beta, pre-production, stress testing, etc.)
- Training of users and IT support staff
- Documentation for users, help desk staff, operations staff, etc.
- Administration processes
- Support procedures (hardware, OS, network, application, third-party vendors, etc.)
The third part of the WCPA questionnaire deals with exception procedures or any specialized requirements of the application, including the following:
- Security
- System moves/changes
- Critical system messages
- Filesystem backup and archives
- Disaster recovery
Personalized Communications
The WCPA places a special emphasis on communications between the three stakeholders in a successful software development project: the developers, the IT operations staff, and the end users. From the very beginning of the process, the WCPA opens the lines of communication between all three groups. Database administrators, system programmers, production control personnel, and computer operators work closely with applications developers and end users to understand the requirements necessary to implement and support a distributed web-centric application.
The WCPA's approach of personalized communications contrasts starkly with earlier models of software development, such as waterfall software lifecycles. The WCPA is proactive, not reactive. In the past, MIS would get involved with users only when a problem occurred. Someone would call the help desk, the help desk would call data center operations, operations would come to resolve the problem. That was and still is the paradigm in many data centers. But this paradigm doesn't work for today's web-centric applications environments. You need to work closely with your users to solve the business issues of new applications, or they'll never be successful—no matter how skilled your developers become.
The WCPA is responsible for setting everyone's expectations, for communicating roles and responsibilities, and for establishing how groups and individuals—customers and the data center—work together. It's a service-level agreement between different organizations. The WCPA is also the communications vehicle to ameliorate the cultural differences among UNIX, PC, and mainframe personnel; applications development; IT support; users; and the data center as they come together to support web-centric projects. Personalized communications is not just a buzzword. It's a new way of doing business and working together for the benefit of the whole enterprise.
Internal Support Agreement (ISA)
Service-level agreements have long been the mainstay of mainframe production systems and larger UNIX client/server systems. On the web, however, service-level agreements become much harder to define and monitor. No longer are all the components of the application residing in a glass-house data center, or even distributed within a company. Web-based applications may span multiple companies in an extranet or, in the case of the Internet, may span across the world. The WCPA questionnaire, when filled out, helps span the many environments of the web and becomes a template for an internal support agreement between users and IT.
The internal support agreement is aimed at three groups:
Business managers receiving IT services, who need to ensure that the services delivered are in line with their business requirements, at a cost they're prepared to pay.
The system administration staff, who deliver these services and need to fully understand the commitments that customers require, in order to provide quality service.
The new enterprise network services staff, which coordinates the delivery of these services across the web to their respective business units or external customers, to ensure maximum contribution to business effectiveness.
With an internal support agreement (ISA), both internal and external customers can understand the kinds of service they should expect from their computer resources and how those resources are expended. On the other side, an internal support agreement ensures that system administration personnel understand their jobs well—which services they provide, as well as those that they don't provide.