Transaction support: Most enterprise data and application integration tasks are transaction-oriented. You don't want some pieces of an update to go through and the rest not to. More and more in the EAI world, those transactions are multitarget (for example, System 1 and System 2 must update, or the entire transaction rolls back). An EAI app should support single-target, multi-instruction and multitarget transactions.
Development: To reap cost savings in EAI, a useful development tool is necessary. You must be able to generate a minimally working system in a mostly drag-and-drop method. If every connection you define requires coding, you are not going to save much time over coding directly in the application.
Management console: Your systems and network administrators are going to be working with this system much longer than your developers will be working to get it running. The management console must be simple and make it easy to take in system status at a glance.
Transport: The system must support some form of store-and-forward or message queuing system. Examples are JMS (Java Messaging Services) and IBM MQ. It should also support targeted messaging, so that time-critical transactions are completed in a timely manner. MQ is more time-sensitive than it has been in the past, but this requirement still exists.
Redundancy/load balancing: You must have options if your system goes down or is overloaded. Support for failover and load balancing are more than you should ask of an EAI product, but look at pricing for putting it behind a hardware load balancer; some vendors charge you the same for your hot backup as for your production server, while others work with F5 Networks' iControl API for its Big-IP to enable dynamic load balancing. If you're an F5 customer, ask your vendor if it supports iControl.