The Wired World of Enterprise Computing
- Enterprise Networking: Today's Challenges
- Enterprise Networking: Tomorrow's Challenges
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The world of enterprise computing is vast, complex, and networked. From being simple, self-contained, isolated systems to becoming fully distributed, n-tier architectures, enterprise information systems have come a long way. And in recent years, the evolution of Web-related technologies and electronic commerce has induced sweeping changes in their essential characteristics and behavior.
The landscape is still evolving, with newer technologies such as peer-to-peer networking and service-oriented architectures coming into place.
Prior to the introduction of e-commerce, an enterprise's IT capabilities were safely housed in its own secure premises—not being exposed to the outside world. Enterprises had the luxury of time—to embrace contemporary technologies such as object-oriented design, component methodologies, and distributed computing.
But now, with the competitors in business heavily exploiting the opportunities available with the Internet by investing in latest technologies, one would be left out if they don't match the IT capabilities of their competitors.
Hence there is the tremendous pressure for enterprises to deliver cutting-edge, distributed applications that will expose their core business features and facilities to the Web. These applications need to be accessed remotely—not only by means of a browser, but even through palmtops, mobile phones, PDAs...and what next?
All these issues have forced IT managers to rethink, redefine, and revamp their core system architecture and the way applications have been built and deployed. Going forward, he or she will be faced with a number of challenges, imposed by the existing needs of today and an evolving tomorrow.
Enterprise Networking: Today's Challenges
1. Coping with a Variety of Hardware and Operating Systems
Enterprise systems have evolved over a period of time to be isolated systems, independent of each other. Some are out-of the box applications, deployed under vendor-recommended hardware; whereas others might be customized and tailor-made solutions, developed in-house or by third-party vendors.
These applications serve different needs—they were conceived to be fairly independent of each other, with no effort to adopt a common policy and environment. This has resulted in a mushroom growth of systems, from mainframes and AS400 on one end to Sun Solaris, HP Unix, and NT servers on the other end. The end users' systems have mainly been dominated by desktop windows applications.
As a typical example, consider a banking information systems scenario. The risk management group might be using a leading edge AS400 application for its day-to-day operations; the enterprise data warehouse might be developing customized c programs that run on a Solaris server; the core banking applications might well be sitting on a group of IBM mainframes.
With such a diversified computing environment, it becomes difficult to consolidate development efforts and integrate various applications. Also, maintenance and support costs soar to new heights.
2. Lack of Serious Object-Oriented Design and Component Architecture
As indicated earlier, enterprises have been rather slow in adopting object-oriented methodologies and component-based architectures—simply because there was no dire need. The emphasis has always been "getting things done more quickly" instead of "getting things done the right way." In many cases, it's been an individual's drive rather than an enterprise level IT policy that has resulted in a truly object-oriented enterprise system and design.
Also, newer applications had to be built on top of existing systems to accommodate growing requirements. These systems might well have been developed using different languages and environments{md]for example, COBOL, C, RPG, FoxPro, or Clipper. Obviously, such old-generation languages can neither guarantee truly object-oriented system designs nor produce reusable application components.
An industrial survey pointed out that less than 30% of code is being reused when developing newer applications. With increasing pressures to reduce IT overhead and development costs, it will be difficult for companies to manage their systems in the future without code reuse, component methodologies, and service-based architectures.
3. Rigidity and Inflexibility
Traditional enterprise systems are rigid and inflexible, and they lack interoperability and portability. They are neither easily extensible nor can their functionality be exposed to other systems and applications without considerable plumbing work.
Newer features have to be built on top of existing codes and libraries. This makes the existing system even more complex, and the entire IT backbone of the enterprise can become a white elephant (extremely difficult to handle and maintain). This is very easily substantiated by the fact that enterprises often spend more money in maintaining legacy systems than in investing in newer systems.
4. Problems with Exchanging and Integrating Data
Exchange of data across various enterprise systems and applications is mandatory to complete the business flow. Given the current enterprise infrastructure, the seamless exchange of data is almost impossible.
In many cases, developers write their own codes or depend on the database capabilities to import necessary data from other systems into their environments. This results in complicated and interdependent day-end and month-end batch processing (see Figure 1).
){kind=link}
Figure 1 Data interchange across several enterprise systems.
A lack of standards results in proprietary forms of data interchange through heterogeneous communication protocols. With disparate systems that cannot talk to each other (even within the same organizational boundaries), how can companies expect to exchange data in real time with entities such as electronic payment gateways or enterprise Web portals?
5. Back-end Legacy Systems Integration
Almost all institutions have invested heavily in legacy systems such as mainframes and ERP implementations, in which day-to-day back office applications and processes are still running. It is difficult to connect these legacy systems to other systems and applications. Developers often end up with their own adapters and APIs, or make use of their party system integrators to achieve this connectivity.
Introducing such adapters induces additional cost, complexity, and performance bottlenecks into the existing system. And when such systems need to be thrown open to real-time, online transactions, integration issues assume newer and challenging dimensions.