Enterprise Applications Integration is one of the most critical areas for organizations involving large number of heterogeneous systems and applications spread across the network. In this post, I am going to talk about some of the key considerations to be kept on topmost priority while deciding EAI architecture in any organization.
Ensuring that integrated applications perform in an efficient manner by transfer of data in a business acceptable time duration should be the prime focus. To achieve the goals of high throughput, It is important to decide cleverly on choices of transport mechanisms, routing and transformation techniques and network configurations.
For example; decision between opting for synchronous communication versus asynchronous communication of data between a set of applications should be taken keeping in mind both data criticality and time criticality for a specific business scenario. For Banking and other financial domains, data criticality should be places at a higher priority over time criticality. Despite that; no businesses can afford large queues of customer orders or requests piled up just because of a choked or inefficiently developed/designed middleware.
When looking into performance aspects, deployment and runtime configurations also greatly matter. Deploying EAI solutions in high availability Load balanced and Fault Tolerant environments with smart choices for memory, CPU and other resources is pivotal in this regard.
When it comes to TIBCO specific EAI solutions; utilizing in-memory caching features (through Tibco Activespaces), Properly configuring deployed solutions (Parameters like Max Jobs, Flow Limit, Heap Size etc.), ensuring non-redundant and fine-tuned code design, ensuring an efficient database design in the background and actively monitoring the deployed solutions (using TIBCO HAWK) are some of the main considerations to be kept in mind.
Data is the real wealth in any business and securing the data must be always among the primary goals in any organization where heterogeneous applications and systems over the local intra-net or internet are going to talk to each other.
When using TIBCO for Integrating the applications and systems in an organization; it is not only necessary to ensure information security at the designed solutions level but also at the network level. An organization’s internal services shouldn’t be exposed nakedly over the internet. A logical sub-network (DMZ) and firewall are the two commonly known strategies to add security layer between a company’s local network and internet.
Security at TIBCO application’s level is achieved by incorporating security features at different interfaces being exposed. SSL based communication when interacting with EMS Servers or HTTP Servers ensure secure communication with these servers. Web Services developed in TIBCO should also be secured by utilizing SSL’s features.
Data security at database level is also a key consideration. In an ideal implementation; no database table should be exposed directly rather API’s based implementation should be preferred. Wrapper services or stored procedures can be written or database views can be exposed instead of actual tables to ensure that no unwanted intrusion is taking place inside the database tables.
In typical EAI scenarios; a large number of pieces can be re-used from one solution into another solution if generic nature was retained while building those solutions. While integrating applications in an organization; try not to re-invent the wheel rather try to discover how you can glue the same wheel in another car to make it run.
Certain functionalities are always a mandatory part for designing solutions to integrate any applications. Logging, exception handling and auditing are the most widely narrated examples when it comes to re-usability. However; reusability considerations shouldn’t end here. In every organization; when designing the solutions for integration of applications; on every bit and byte you must once shake your head to think of a possibility of a future re-use of what you are doing. For example; If you are designing a process for your project ABC to fetch price information from another system; don’t make it tightly coupled with your solution. Rather try to design it in such a way that in future if same pricing information fetching is required for another project XYZ, the same solution may be utilized.
The list of key considerations while deciding to build EAI solutions doesn’t end here. However, to keep the post to this much length; I stop here. In some future post, I will shed further light on it with deeper angles.