As we go further with this Integration Engine Alternatives series it is important to establish what your short term goals and long term goals are for the engine. Implementation of a different integration package that meets newly discovered requirements, or even implementation of a new version of the same package can be costly and time-consuming.
Because of this, it is in your best interests to do some real analysis of future needs that could be fulfilled by the integration engine. Ensure that all of the features, that are needed now and in the foreseeable future, will be supported by the engine that you select. You definitively do not want to have to change integration platforms a year or two after initial implementation.
This “forward thinking features” approach only applies to features that the selected package can support, it does not apply to processing capacity. Most modern integration engines provide the capability to increase processing capacity (number of transactions processed per second) with minimal , difficultyso only buy the processing capacity you need when you need it.
Questions to ask to help define your Goals:
- What is the programming language(s) that are used to create integrations?
- What operating system does the integration engine run on?
- What database is used to operate the integration engine?
- What integration points have pre-built support (adapters) for native interfaces with the integration engine? (This is particularly important for major business systems at your enterprise, like ERPs, EMRs, and HR systems, and major databases in use in your enterprise)
- Is there integration support for any business line specific applications that are critical to your business operations? (If you are running a non-mainstream application that is business critical. . . figure out how an interface to that system is going to work, at this step.)
- Is there support for common messaging standards like JSON and XML?
- Is there support for common transportation protocols like HTTP, HTTPS, FTP, POP, etc. .?
- Is there pre-made schema support for EDI (X12, Edifact, AS2) message protocols?
- Is there pre-made schema support for HIPAA message protocols?
- Is there pre-made schema support for SWIFT message protocols?
- Is there pre-made schema support for HL7 message protocols?
- Does the engine provide support for SOA / ESB ?
- Does the engine include a monitoring / management feature/application?
- Does the engine provide support for automation of human interaction, or long-running Business Processes?
- Can the integration engine be deployed on-premises and in the cloud? What about a hybrid of the two?
- What are the inherent security features of the integration engine?
Come back next week for Step 3: “Technology stack / Vendor alternatives”
As always we love hearing from you. so go ahead and share your thoughts and ideas with the group through our comments section below.