Inverted Funnel Model

Inverted Funnel Model

Non Functional Requirements of Integration Projects (EAI and B2B)

• No Data loss in any case. Data should be recoverable in integration layer.
• Recovery should be automatic in majority of the cases in case of integration layer failure.
• Replay of messages must be possible in all case of failure.
• End systems to be integrated, should be decoupled in time, space and semantic.
• Contingency path/scenarios (if deployment fails or integration is need to be rolled back after successful run in production after a while) must be defined and rehearsed.
• There must be clear separation between Integration and Services.
• Underlying integration service failure (like audit, logging, notification, error handling, etc) must not affect integration as well as enterprise services.
• Audit, error notification, error repository should be deployed on separate servers/infrastructure from business services and integration.

SaaS Integration Challenges

1. Security

• Authentication

• Data Encryption

2. Volume of data transfer

• Continual Basis (Real time)
• Traffic Bust
• Batch Mode

3. Error and Exception Handling
4. Contingency
5. Data Migration
6. Turnaround Time
7. Cost proposition
8. Support Organization

Does Enterprise need SOA for Integration?

One of the most overlooked requirement in Enterprise as well Integration Architecture is seamless replacibility of enterprise applications ( custom made, off the shelf, Cloud, Enterprise Information System, etc). For example, enterprise XYZ wish to replace Siebel CRM by Salesforce. To achieve this target, Enterprise IT has to develop customizations on Salesforce and integration harnesses with other EISes.

Certainly, customization of Salesforce need to be developed but can Integration harness development is reduced to minimum. If Integration has followed the SOA in true sprit then YES but if Integration has followed SOA by using just Tools and platform then NOT.

Decision is yours.

EIS and Integration

While talking to various business and technical architects, I realized that most of them have very confusing ideas behind usage of any enterprise class systems, EIS (Enterprise Information System) like ERP, CRM, SCM, HRMS etc. For most of the persons each of EIS is specialized for some business function and some time domain. This view may be satisfying for business folks but must not be sufficient for architects.
Any EIS serves few of the basic functions:

1. Focuses on a specific business function and or domain.
2. Managing Business objects life cycle.

In any enterprise which has many EISes to accomplish business objectives, need integration. To keep the essence of EIS intact and not duplicating the data across EIS Integration and Information architects has to be very careful. The information flow (essentially business objects transfer from one EIS to another EIS) must be controlled and business objects which have achieved a certain state (in life cycle) in source EIS should transferred to target EIS.