- What Is Production Control?
- Production Control Versus Applications Development
- Why Bring Back Production Control?
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Production Control Versus Applications Development
In the 1970s, one of the primary functions of the production control group was to accept or decline new systems/applications from applications development into what the infrastructure support staff considered the sacred mission-critical production environment. Their job was to ensure RAS. On the other hand, the application development charter was to design, develop, and deploy a system into production as quickly as possible.
Two Worlds Clash
Nothing would enter the holy temple (data center) until the proper documentation was provided, the appropriate staff was trained, and the application went through a very thorough QA process. The production control staff had as much power to decline a new system being deployed into production, as did the applications development staff for bypassing the normal process to expedite a system into production. There was no bargaining; it was production control's way or the system would end up in the department's broom closet, not supported by the production control group. You can imagine the friction this caused.
This dictatorial type of behavior by the production control staff lasted throughout the 70s and midway through the 80s. The mainframe process was one-sided in favor of the production control group. In the late 80s and throughout the 90s, as most companies transitioned to client/server computing in a decentralized environment, they did away with the production control function, and with it went the production QA function. Along with production QA went RAS. RAS was an afterthought.
Some companies tried to keep this organization intact by changing the function dramatically. The perception was that production control was bureaucratic. As technology was evolving at a torrid pace in the late 80s and through the 90s, this perception became a reality throughout IT. Sometimes it took several weeks to put a system into production. The intent was good, but it really slowed the deployment of new systems, which in turn angered the user community. The bureaucracy was unbearable.
The centralized production control staff wouldn't dare say no to new systems or applications being deployed into a production environment, regardless of whether they followed a process or procedure. Support responsibilities were pretty much contained to mainframe applications. Because of their bureaucratic process and dictatorial behavior, the newer client/server technology was off-limits. A few companies still had a centralized production control staff supporting all applications, but their responsibilities were very limited. If for whatever reason (such as poor operations documentation) they declined to accept the new system into the corporate production environment, the customer/owner of the new system would construct their own systems, even if it meant installing the server in a broom closet. Once the system was declined by production control, the customer had no choice but to install the server wherever possible—because they still had a business to support.
Once a system went into production status, it became certified production-ready, and consequently was located in the corporate data center. The buck stopped with production control. If the system was unstable (unable to maintain 99.9% uptime availability), there was no one to point fingers at but themselves. Production control's failure during this legacy environment and even in today's network world was determined by postponement of communication or lack thereof. Production control waited until the Software Development Life Cycle (SDLC) was complete before they would start communicating with applications development staff regarding their system requirements. There was very little communication between applications development and the entire infrastructure support staff—especially production control.
Production control was never involved in any of the pre-production activities. Systems were literally thrown over the wall into production. Production control was never involved until applications development said their systems were ready. Nine times out of ten, the systems were not (in the eyes of the infrastructure support staff) ready for production.