DBMS, May 1996
During the past 10 years, the industry has been moving toward distributed computing. At first, mission-critical corporate applications stayed primarily on mainframes while fast-turnaround applications made their mark on departmental systems. Lately however, mission-critical, bet-your-business applications are being written and rewritten as distributed applications. While these business applications may continue to connect to mainframe data, they are now designed to work across an organization. But companies are now discovering that these critical applications are more difficult to manage in their distributed form than in their centralized form. Because the transition to distributed computing has not always been well-planned, organizations may begin to regress to centralized computing.
Why are distributed applications presenting so many challenges? Part of the problem is that organizations typically focus on how to design and develop applications. They do not plan for application deployment and management, which are difficult parts of the process but vital to the success of distributed computing. Successful deployment and management of distributed applications depends on a solid strategy that includes the following components: software distribution, performance management, troubleshooting, and code management.
Software Distribution. If an application is to be distributed, an organization must understand how code will physically get to each user or group that needs it. Is there staff that can manage this process? Are systems in place to manage the load? Does software exist that will allow applications to be distributed from a central site? Will the new code conflict with code that is already installed? These issues may seem insignificant when developers are hard at work writing code, but they can kill a project if you don't address them early.
Performance Management. Most complex systems begin as pilot or proof-of-concept projects. While such initial projects may demonstrate or highlight the capabilities of developers to write code, they often do not deal with scalability issues. Distributed systems applications must be architected so that they will perform well as the code base and the number of users grow.
Troubleshooting. I do not mean debugging here. Complex problems can occur after debugging has been completed and an application is deployed. More and more organizations are creating applications that are intended to work in tandem with other applications. This involves using a messaging or remote procedure call mechanism to move information among applications -- not a simple task. And, as the importance of the Internet in creating interoperability among applications grows, this problem will become more complex. How can you track what is happening when one part of an application interacts with another? My guess is that most development organizations have no plan in place to deal with the inevitable problems that can and probably will arise in such an environment.
Code Management. As development organizations begin to use component libraries to extend the life of systems and expand functionality, problems will surely arise. Developers will have to be able to trace dependencies among libraries. They will also have to understand the performance implications of these changes, which is especially important if code is distributed across several different systems. Issues such as the synchronization of code across multiple systems will also be a challenge.
If organizations aren't cognizant of these issues, deployment and management will become more complex and more likely to hamper expansion. There are several ways to address these issues. One possibility is that vendors will begin to package their distributed software development environments with sophisticated systems and application management facilities in order to prepare IT organizations for the deployment and management of applications. However, if the problems I outlined in the software distribution, performance management, troubleshooting, and code management categories go unresolved, there is a good chance that IT organizations will follow the path of least resistance and return to centralization. They may decide that supporting distributed environments is too complex. This realization may also coincide with the emergence of powerful, parallel processing hardware that could help recentralize computing resources at a fraction of the cost of mainframe computers. Companies would then be in a position to bring software back to their IT organizations and give users a new generation of powerful terminals to access their applications. With the recentralization of applications, system and application management becomes centralized, too.
I believe that some recentralization is probably a good thing, because, from a consolidated point of view, certain management issues are easier to handle. However, organizations should recentralize their computing environments only when it makes sense. For example, if a corporation's repository, key business rules, and data do not have to be moved frequently, they can all be centralized on a mainframe. Distributed computing, on the other hand, should be applied to processes and applications that are closer to an organization's actual business users. This might include copies of key data and business rules to which users need frequent access, complex graphics, and anything having to do with ease of use and the user interface.
Recentralization might be inevitable. Plus, if it's applied appropriately, it just might be a good thing. But there's a risk if organizations move too far toward centralization. To be effective, organizations need a good balance between centralization and distribution.