Functional Integration – the logical extension of data integration – is where the applications integrate at the business logic layer by allowing the business function in one application (the source) to be accessed by other applications (the target).
Functional Integration is possible when:
- The function needed is available as part of source application’s business logic.
- The Application Programming Interfaces (APIs) is provided
For the APIs to be most effective, they should have been designed to be accessed remotely (Wrappers and Adapters can be developed if the function is available but not meet the API / remote access.).
If the applications only expose their business functions as a local API – and are also dependent on the programming language, then an adapter or middleware interface has to be developed to make it remotely accessible.
Development of adapter(s), if any, should be taken as an opportunity to provide seamless integration between applications – and even non-functional requirements can be addressed at this level (e.g., usage of local copy / cache – providing better performance). These adapters can handle data transformation (inbound as well as outbound) and can be made generic enough to support a variety of functions to be made available externally.
Functional Integration is a very versatile approach and can be used for simple add/modify/delete of data owned by other application or for function-shipping like validate credit card, receive payments etc.
Note that Functional Integration – at its simplest – results in tight coupling as one application sends a command directly to another application and hence needs to know the location of the application that provides the function.
Factors to be considered while using Functional Integration:
- Local or Remote Access – A remote implementation of the interface is subject to network latency, network failure, and distributed system failures. A significant amount of error detection and correction logic must be written to anticipate the impacts of using remote object interfaces.
- Level(s) of Coupling – Functional integration means “Shared functionality” and implies certain level of coupling between consumer and producer of functions. A synchronous call that waits for the request to be processed is more tightly coupled than an asynchronous call.
- Unless the applications share a common schema, the consuming applications have to be aware of the source schema (or) have to route the request through adapters (or middleware) that takes care of data transformation.
Recommendations related to Functional Integration:
- Use Functional Integration ONLY if the required function is available in the source application and APIs are provided.
- Use Adapters – if readily available (e.g., SAP Adapter)
- Develop Adapters (or middleware), if required, to make the APIs generic and remotely accessible
- Use Adapters (or middleware) to provide the security context, say user-id and credentials.Take into consideration, the extent of compatibility of the key data to be shared across applications. The extent of compatibility between data could result in issues being raised during implementation. Data types and Data lengths of common data stored / processed applications definitely needs to be taken into account upfront – to avoid implementation hitches (For example, if the customer field is of type numeric and size 6 in one application and alpha and size 10 in other, the actual value to be used for customer field is only size 6 and of type numeric. While padding additional spaces or zeros is easier and saving numeric data in alphanumeric field is easier, same cannot be said for the other way around). Though this seems to be a technical point, it can have business implications – and even require “data field expansions” in certain applications – especially so when the existing data has to be uploaded to the new system in bulk.
- Do not use online functional integration for bulk processing as it would be very inefficient (Data Integration – File Transfer could be a better option).
- Using Functional Integration for extending functions could be unproductive (Developing the new function externally could be easier and also less risky. In such cases, existing function reuse could be limited to copying parts of the source code. Alternatively, the new function can use the available APIs.).
- Note that Functional Integration due to its nature of shared functionality and coupling results in reduced interoperability