Team LiB
Previous Section Next Section

Enterprises Today

Let us take a look at an imaginary company, called R & R Automobile Corporation, that manufactures and sells cars. R & R has been around for quite a number of years now. During this time, hundreds of data and communications systems have grown up in the company, and nobody knows the exact number. These systems reside on different hardware and software platforms; 70 percent of these probably reside on mainframes, while the rest are scattered on client-server and PC systems. Data is transferred between systems at different times. Some systems transfer or receive data in real time, while others transfer or receive data in batches on a daily, or even weekly, basis. A few systems cannot communicate with others at all, and R & R staff has to print information from those systems and manually enter it into other systems.

This chaotic architecture makes it hard for R & R to know all the details about its relationship with its customers (see Figure 1-1). This is obviously a problem for a company, especially if it must be able to respond to changes in the business environment in a timely manner.

Click To expand
Figure 1-1: The chaotic situation at R & R Automobile Corporation

R & R management has discovered the need for a closer interaction with both partners and customers. This means that the supply chain, customer support, and service need to be tuned so R & R can be an effective, modern company, which can be achieved by providing a better integration between the applications. Obstacles have arisen in the way of achieving this, however. All these years that R & R has existed as a company, boundaries have been established between units, geographically dispersed offices, product lines, and so on, that will diminish the ability to share information within the company. As you can understand, it is hard to give value to the customer if the obstacles within the company are this big. Nevertheless, integration across the enterprise probably will provide significant opportunities to show a unified front to the customer. It will also most likely supply more efficient end-to-end processes.

Take a look at some of the problems, or perhaps challenges, that face an R & R integration team:

As you clearly can see from all this, integration will not be an easy task for the team. You can actually think of this as a puzzle. All pieces are scattered around on the floor. The work ahead of the team is to build a complete picture from these pieces. This is the vision to strive for in your own integration attempts. As with all visions, you will probably never get there, but if your aim is high, you may come pretty close. And fortunately some tools and techniques are available that can help get you on your way.

Before starting any development, take a moment (preferably more than a moment, to be honest) and consider a few things. You should first of all know which problem or problems you really need to solve. Then you should consider what will give the most value to the company. After that, you can start identifying what you need to build and what you need to connect.

These points might seem obvious, but in our experience we have found it valuable to get answers to these issues on paper, so we know everybody is working towards the same goal.

When you have answers to your questions, you can start designing your integration solution. One of the things we would like to point out is that there really is no significant difference between designing an integration project compared to designing any other enterprise application. You can still apply the same design patterns.

Figure 1-3 shows an example of an application that integrates new functionality with data from legacy systems. As you can see, the design is still n-tier to provide for maximum flexibility and scalability.

Click To expand
Figure 1-3: An n-tier application model with integration that includes legacy systems

Compare this to Figure 1-4, which portrays an ordinary n-tier application without integration.

Click To expand
Figure 1-4: An ordinary n-tier application model

Team LiB
Previous Section Next Section