1.1 The Business Perspective of Integration
By taking advantage of pervasive and ubiquitous computing, enriched information linkages, and the emergence of the Internet of things in today’s digitalized business environment, the right and proper data and information in the right format could be delivered to the right end user (e.g., people, machine, device, software component, etc.) in the right place, at the right time. Ultimately, the use of a right and smart enterprise integration approach in an organization would result in the substantial increase of the degree of business process automation, the level of production productivity, and service quality, surely keeping the organization’s business consistently competitive.
As time goes, an organization tends to introduce new business operations or enhance certain business function supports to assist the employees in serving customers beyond their expectations. Thus, new IT functions to support these new or enhanced business operations are unceasingly introduced and added into the existing enterprise systems. Furthermore, to meet certain new business requirements, new software applications across the organization are deployed from time to time. Because of the ever changing business operational needs, enterprise integration never ends. Enterprise applications are required for continuous reengineering, so is the integration across enterprise applications.
No matter how complex and what size a software application is in an organization, it is usually designed, developed, and/or deployed for a predefined business domain. That is to say, it is typical for an application to focus on meeting the needs of a given business domain while complementing other business domains by playing a supporting role. As discussed in previous chapters, enterprises can maximally capitalize on their investments by fully leveraging all the available IT supports enabled by individual applications through enterprise integration. However, integrating applications across an enterprise is a complex and skillful while endless endeavor. Approaches to integrating distributed applications vary with a variety of factors, technically and financially. Figure 1 illustrates the potential integration interfaces at different hierarchical levels of a typical application.
Figure 1. A typical application integration interface hierarchy
The accessibility of the interfaces at different integration levels in the hierarchy of a software application depends on the privilege provided for the application’s end users. For an in-house developed system, all integration levels are presumably accessible. For a purchased packaged application, frequently the interfaces at higher levels in the hierarchy are allowed to be utilized, which typically limits the supporting roles the application can play in an integrated enterprise system. Technically, depending on integration levels in the hierarchy of an application, the corresponding support roles provided by the application varies from fine-grained data object functions at the bottom to coarse-grained business activity support services at the top. The four boxes on the right in Figure 1 provide some simple examples of services expected from an application when it is integrated.
From a business operational point of view, it would be the best scenario if all applications can have their supported processes coordinated to operate as a whole in order to serve the business needs throughout an organization (Figure 2). However, at a given time, some existing applications might be simply required for sharing data, while other existing applications demand functionality sharing. Technically, an appropriate and implementable integration most likely depends on how all the functionality/supports are implemented and what integration supports are provided/enabled in the applications. Therefore, different levels of integration will be needed and implemented to meet the different types of business objectives, operationally and technically (Figure 2 and Figure 3) (Linthicum, 2000).
Figure 2. Business needs for integrations
Figure 3. A graphical view of integrating methods at different levels between applications
The three distributed applications deployed at Malvern iStore can be used as an example. When different business operational needs were required, the provided interfaces at different levels in these individual applications should be accordingly utilized. Simple examples illustrating different levels of integrations in the hierarchy shown in Figure 4 are as follows:
Figure 4. Business needs vs. integration approaches
- •
Data level: The CRM application control and manage detailed customer profiles, which are frequently needed in the OiA application when customers place orders online. To ensure that the customer profile is up-to-date in the OiA application, a real-time database level synchronization mechanism can be implemented between the CRM and OiA applications.
- •
Method level: As soon as an order is placed online by a customer, the customer can be certainly served better if the CRM application also stores part of the up-to-date order information. Assume the CRM application has an ‘order updates’ software component, once it is invoked locally or remotely it can update the customer order information in the CRM application. To meet this business need, the ‘place order’ software component in the OiA application can thus be enhanced by adding a trigger that can make a remote invocation of the ‘order updates’ method in the CRM application.
- •
API level: Similar to the need of order information in the CRM application, WMS application relies on getting the order information in a timely manner to fulfill the order in time. Different from the CRM application, the WMS application was purchased off-the-shelf. Thus, only a list of APIs is available for integration. As a result, API level integration is applied for realizing this productivity improvement requirement.
- •
Process level: To ensure that a defined business operation across the organization can be completed in a satisfactory manner, different levels of business activities are required to be completed in a logically coordinated way across these three applications. The Returns Management process discussed in Chapter 5 essentially shows how integrations can be done at this level among distributed applications. More detailed discussion on the process-level integration will be provided in Chapter 9.