|
|
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.
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:
R & R uses a mix of technologies. Over the years various technologies have been used to build R & R's applications and databases. As mentioned, some systems provide an interface to the surrounding world, while others do not. The company is rife with customer relationship management (CRM) systems, and other applications, both standard and proprietary. These applications are often run on different platforms.
New applications at R & R need to extend features provided with legacy systems. The cost of updating the legacy systems is too great to be a serious alternative. Some of the systems are also not possible to change.
New business workflows need to be developed. R & R needs to find ways to develop new workflows for its business processes. Somehow its existing applications need to be incorporated here.
Many of the applications in use have no clear separation between their business logic, user interface, and data access. In a modern n-tier application, designers and developers architect the application to separate these items, as Figure 1-2 shows.
The data transferred between applications is provided in various formats. EDI documents are used as well as text files and XML files. It is therefore difficult to map fields from one data structure to fields in another.
Different component models are used. Some applications use CORBA and others use COM/COM+. This has resulted in tightly coupled applications that do not easily communicate with each other.
R & R's systems are not integrated with the outside world. The issues so far have been within the company. When R & R is about to interact with its customers and partners, most of these issues remain. An additional problem is that R & R has no control over these other systems, as it has over its own. This means the R & R team has to adjust to the ways the outside world communicates.
Most legacy systems run smoothly. Changing a legacy system to provide new features involves the risk of introducing bugs and errors. The question is if it is worth the time and money it takes to do such changes. In order to implement changes, the integration team also needs documentation that often just does not exist anymore. If this documentation is found, it will take quite some time for the developers to go through it so that they can understand the systems.
The integration solution deployed today must also be open so that future infrastructure requirements can be supported. To comply with this, a lot of thought has to go into the design of the solution. R & R will also have to carefully consider the technologies the company is using, so that they are based on standards as much as possible. R & R cannot afford to fall for the latest hype when choosing a technology, at least not if that technology is relatively unknown or unproven.
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.
Compare this to Figure 1-4, which portrays an ordinary n-tier application without integration.
|
|
