- "DLL Hell"
- A Production Cycle Issue
- The End of DLL Hell
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The End of DLL Hell
How can you make this problem disappear forever? It isn't easy, but it's entirely possible. The first part of the solution lies with IT.
More often than not, IT simply won't identify different clienteles within its user population. A complete IT infrastructure must support several different types of users (see Figure 3):
Common users. The most obvious user category.
Trainers. Must have access to extremely versatile environments because their task is to train all user classes on all versions of internal systems.
Help desk. Must have access to all systems to support them.
IT infrastructure group. Particular needs include an infrastructure designed to administer other infrastructures.
Developers. Infrastructure needs depend on the scope of their development projects, short-term or long-term. Long-term development projects must have access not to current infrastructures, but rather to upcoming infrastructures.
)
Figure 3 IT clienteles.
In addition, IT must aim to deliver different infrastructure levels for different clienteles. They are already used to living with at least two basic infrastructure levels: the current level and the new level that's being deployed. Depending on the size of the organization, this infrastructure level coexistence can last several months. The current infrastructure is considered to be "n – 1" and the new infrastructure becomes "n."
But if organizations want to avoid DLL Hell forever, especially the introduction of older system components within their production network, they must introduce a third operational level: "n + 1" (see Figure 4). This new level is designed to provide developers with the future version of the infrastructure. This approach means using the latest versions of infrastructure technologies for longer development projects. This may even mean using beta versions of certain products—versions that are not yet commercially available.
)
Figure 4 Supporting different infrastructure levels for different
needs.
In fact, this approach is based on a staggered release of new infrastructure versions. It ensures that development projects are always at the forefront of the infrastructure upgrade process, often becoming internal testers for new infrastructures. Thus, when applications are ready for release, this release can be synchronized with the general release of a new version of the production infrastructure. The simplest approach is to use a six-month stagger—ensuring that development infrastructures are six months ahead of production infrastructures.
Nothing is more frustrating than discovering that your organization just finished investing in several months of internal development, only to discover that the product you're releasing is based on an obsolete infrastructure. So it's back to the drawing board to remake the system with the tools that are currently deployed. For example, if you develop a product based on Microsoft Office 2000 when Office XP has been out for some time and already boasts a service pack, you'll soon discover that you can't deploy the new version of Office because your own system isn't designed for it. To upgrade Office, you need to redesign your system from top to bottom.
A complete development support infrastructure must include several different aspects. One of these is the design of the development infrastructure itself. In most cases, this complete infrastructure only requires thought and discussion to ensure that every client's requirements are taken into account before the initial design begins.