Designing Development Support Infrastructures (Part 1 of 5): Meeting Mission-Critical Development Needs
Most organizations today have internal development requirements. Even though the IT market offers a plethora of commercial solutions, especially for the Microsoft Windows environment, most organizations must either customize these solutions or conceive new custom applications because they cannot find the particular tool that supports their mission. In-house development has come to provide a mission-critical service because the tools it generates are specifically designed to support the organization's mission.
Despite this mission-critical need, few organizations have taken the time to design IT infrastructures with the specific purpose of supporting internal development, even though Windows technologies (especially Windows 2000, Windows XP, and the upcoming Windows .NET Server) offer unparalleled capacity for development supportcapacities that are often unknown and unused.
But if the objective of in-house development is to support the organization's mission, the support and implementation of development infrastructures should be part of the IT department's "mission." It's true that at first look, the issue of supporting development environments is not easy to solve, especially when the IT department's foremost mission is the stability and proper operation of the working IT environment for the entire corporate network.
Microsoft Windows has been known for its instability in the past. Its major problem has been the issue known as "DLL Hell." Most Windows users have experienced the famous "blue screen of death." Windows displays this screen when it has encountered a fatal error and cannot continue to operate. Part of the problem lies with constant software installation and removal, which destabilizes the operating system. This situation is unacceptable for corporate PCs that must provide constant uptime.
Microsoft has made significant efforts to resolve this issue. Windows NT was the first system to offer a solution to IT departments. Since NT includes NTFS and supports hard disk locking through access rights definition, common users can no longer install software and components and thus destabilize their machines. But locking the system, especially the "hard lock" that's supported by NT, is not the ideal solution for every type of user. The developer, for example, should have installation rights. The developer's very mission is to create and test software components. To do so, developers must constantly install and register components on their system. In a hard-locked Windows environment, these developers cannot install software and components unless IT has given them administrative rights to the PC. But if developers have administrative rights, IT can no longer guarantee system stability because they no longer have control of the machine. It's a vicious circle. IT needs to control local system rights in order to control system stability, but developers must have the freedom to perform their tasks without limitations. The challenge is to create and support comprehensive development environments that are designed to simplify the developer's tasks while meeting the stability and simplicity required by IT to manage the infrastructure. The solution: Windows 2000 and more.