Siebel Financial Services Enterprise Application Integration Guide > Understanding Financial Services Integration Paradigms >

Design Decisions

Performing the right analysis and making the right decision is important for any software project but this is especially true for integration. Integrating disparate systems is a complex process because most customized applications that are created in an enterprise, and some commercially available applications, do not have a published API (Application Programming Interface). This makes seamless integration difficult, if not impossible. To add to this complexity, there are multiple infrastructures used by companies to "glue" systems together.

You need to carefully analyze the integration effort to understand your business needs and integration requirements. Before deciding to integrate your applications, you should perform a cost benefit analysis, review how you use the applications, and analyze the applications' data structure. Some of the factors to be considered as part of this process include:

• Does the data need to be shared or synchronized?
• Does the data need to be transformed before it can be shared or synchronized?
• Is the requirement for data real-time or batch?

  NOTE:  You will need more resources to build and maintain real-time integration than would be required by batch integration.

• How is the data presented to the user?
• How is the data requested?
• Where does the data come from?
• How is the data updated?
• What are the service-level or performance requirements?
• Is there an existing third-party product that can help?

Siebel Financial Service EAI offers different tool sets for different types of integration requirements. Siebel Financial Services EAI is a technology that allows for data sharing, data replication, and function passing across applications. Siebel Financial Services EAI includes the following technologies:

• Business Integration Manager
• Virtual Business Components
• Enterprise Integration Manager
• Business Services
• Business Object Interfaces
• ActiveX Plugins

There are several approaches to integrating the Siebel application with other applications based on the Business needs. Following are some of approaches which were considered:

Synchronize Siebel data with non-Siebel data. Synchronizing Siebel data with external applications can be achieved either through the Business Integration Manager, any of the Connectors, which Siebel ships as a part of the product, Enterprise Integration Manager (EIM), or any of the Object Interfaces.

Display non-Siebel data in Siebel applets. Displaying non-Siebel data within a Siebel application can be achieved through VBC or ActiveX Plugin.

Display Siebel data in another application. Displaying Siebel data within another application without the Siebel User Interface can be achieved by plugging Siebel data as an Active-X plugin, or through a Data Service of Object interface provided by Siebel applications.

Incorporate the Siebel User Interface (UI) into another application or incorporate non-Siebel UI within Siebel applications. Siebel provides an open interface which can be adapted using COM, Active X Controls, Java Data Beans and CORBA. You can use these technologies if an external application needs to have the look and feel of the Siebel application within its own user interface or if the Siebel application needs to incorporate the user interface of an external application.

Control the Siebel application from another application. You can use Object Interfaces such as COM Servers to have another application control Siebel applications.

Export Siebel data. To export data, you can use EIM or other Object Interfaces.

Table 24 lists the best Siebel solution for your integration problems.

To choose the appropriate and economical solution for your integration issue, you need to perform a step-by-step evaluation process for the following:

Transactions. List the business transactions that are executed within your Siebel implementation. These transactions should contain the information that is required for applications to integrate and work together. For example, if a company has a policy management system as one of its legacy systems but policy information initially is captured in the Siebel application, the transaction would be to add policy details in the policy management legacy system.

Applications. List the other applications you need to query or write to in order to complete the transactions. For example, in the above case 'Policy Management System' would be the other application to integrate with the Siebel application.

Integration Points. Identify the points within the transaction flow at which the integration needs to take place (integration points). For example, populate a data warehouse with a nightly download of data. Consolidate integration points to reduce cost of ownership or verify open stock before showing the customer a product choice on a Web page. Add the transaction into the legacy system in real time as soon as a policy is added. Also identify what form of integration is required, real-time or batch, synchronous or asynchronous, tightly or loosely coupled.

Identify solutions. Identify the best solution for your integration need. There may be more than one solution in solving an integration problem. Consider the solution that is most optimal for your problem. You can use Table 24 to analyze the most optimal solution for each of your integration points. For example, connector, middleware, VBC, or EIM.

Other Considerations. Determine whether you need to transform, share, or replicate your data. If you do not need to have the data in both systems but need to share it in real-time, consider VBC. Data sharing solves many of the problems associated with data replication. However, you need to consider data ownership contention and network traffic. Real-time access always carries a premium related to slow response time and the fact that it is expensive to maintain and build. Data sharing is appropriate for integration points that involve volatile or highly specialized source data such as credit card authorization, tax calculation, and so on. Other instances in which data sharing might be appropriate would be when you need to occasionally access large amounts of used data such as a credit card payment history. For details, see Access Mechanisms.

Figure 7 illustrates available Siebel Financial Services interfaces.

Figure 7. Siebel Siebel Financial Services Interfaces