Not too many years ago, developers gave little thought to whether one application could share data with another. After all, most transactions and data input occurred on-site. If the location was a subsidiary, information on sales and expenses was transferred at period intervals. Once received at headquarters, the data often had to be keyed by hand into a completely different system. Clearly some advances needed to be made.
The next evolution was to establish one platform for all branches. Data from remote locations could then be transferred by modem directly into the corporate mainframe. This helped some, but in most cases it was still just a one-way transfer. Changes or adjustments made at the corporate level had to be entered by hand at each remote location. New customers had to be “mastered up” at every location that might ship, bill, or accept returns from that customer. Production had to be recorded at both the plant and corporate level, and usually more than once at each. Inventory would have to be increased, raw materials decreased, and an entry to calculate the cost of goods sold would have to be made.
This arrangement was never very satisfactory, but companies made it work to one degree or another— until it was time to join the Internet community. The World Wide Web made it easier, in some respects, to share information between departments or branches, but in other ways it simply added a whole new level of hassle. For example, customers needed to be able to access data or enter orders, but that access had to be restricted to just the files necessary to accomplish the task. In many businesses, this resulted in yet another application that would communicate with certain files required for the online task to be completed.
As the need to integrate more and more applications became obvious, new methodologies were developed. Scrapping the legacy applications was seldom a viable option, but creating programs to allow them to “talk” to each other was difficult as well. To solve the problem, software companies developed products that could receive input from the various applications and allow others to access it in a usable form.
Enterprise application integration is the term used to describe the use of software and architecture to establish a middleware, thus allowing different programs to communicate with each other. The applications may be in different languages or even different operating systems. By enabling them to share information, the need to update data in several different applications reduces the time spent to alter redundant data.
Redundant systems create redundant work. Just ask COLT Telecom. COLT, one of Europe’s major business communications providers, operates in 13 countries and 32 cities. Twelve data centers stored information independently, which resulted in more than 10 instances for every application, with each having a “silo” of data that was cut off from the others. No overall view of customers was available companywide, since the information was entered into several different systems. In short, it was a mess.
By integrating their enterprise applications, COLT Telecom’s systems were finally linked and could be centralized in one location, requiring only a single instance of every application. The company can now analyze its sales base more effectively and respond to issues in a more timely manner.
While it is now possible for programmers to develop a system that is already integrated, as new applications are developed these, too, run the risk of becoming isolated. For example, five years ago, programmers would not have built in an application to accept input from Twitter or Facebook, because neither one of them existed. Middleware will always be useful as technology evolves. Who knows what the next generation of applications will bring?
Not too many years ago, developers gave little thought to whether one application could share data with another. After all, most transactions and data input occurred onsite. If the location was a subsidiary, information on sales and expenses was transferred at period intervals. Once received at headquarters, the data often had to be keyed by hand into a completely different system.
The next evolution was to establish one platform for all branches. Data from remote locations could then be transferred by modem directly into the corporate mainframe. This helped some, but in most cases it was still just a one-way transfer. Changes or adjustments made at the corporate level had to be entered by hand at each remote location. New customers had to be “mastered up” at every location that might ship, bill, or accept returns from that customer. Production had to be recorded at both the plant and corporate level, and usually more than once at each. Inventory would have to be increased, raw materials decreased, and an entry to calculate the cost of goods sold would have to be made.
This arrangement was never very satisfactory, but companies made it work to one degree or another— until it was time to join the Internet community. The World Wide Web made it easier, in some respects, to share information between departments or branches, but in other ways it simply added a whole new level of hassle. For example, customers needed to be able to access data or enter orders, but that access had to be restricted to just the files necessary to accomplish the task. In many businesses, this resulted in yet another application that would communicate with certain files required for the online task to be completed.
As the need to integrate more and more applications became obvious, new methodologies were developed. Scrapping the legacy applications was seldom a viable option, but creating programs to allow them to “talk” to each other was difficult as well. To solve the problem, software companies developed products that could receive input from the various applications and allow others to access it in a usable form.
Enterprise application integration is the term used to describe the use of software and architecture to establish a middleware, thus allowing different programs to communicate with each other. The applications may be in different languages or even different operating systems. By enabling them to share information, the need to update data in several different applications reduces the time spent to alter redundant data.
Redundant systems create redundant work. Just ask COLT Telecom. COLT, one of Europe’s major business communications providers, operates in 13 countries and 32 cities. Twelve data centers stored information independently, which resulted in more than 10 instances for every application, with each having a “silo” of data that was cut off from the others. No overall view of customers was available companywide, since the information was entered into several different systems. In short, it was a mess.
By using Enterprise Application Integration, COLT Telecom’s systems were finally linked and could be centralized in one location, requiring only a single instance of every application. The company can now analyze its sales base more effectively and respond to issues in a more timely manner.
While it is now possible for programmers to develop a system that is already integrated, as new applications are developed these, too, run the risk of becoming isolated. For example, five years ago, programmers would not have built in an application to accept input from Twitter or Facebook, because neither one of them existed. Middleware will always be useful as technology evolves. Who knows what the next generation of applications will bring?
