When it came to wiring applications together, for a long time, Enterprise Application Integration (EAI) was the...
big story. However, with the rise of service-oriented architecture (SOA), EAI often gets ignored. In fact, according to practitioners, it takes both technologies to run a business.
As a prime example, SAP environments have generally seen a shift toward SOA, thanks in part to tools provided by SAP itself. But it isn't a simple either/or choice. Sanjay Chikarmane, senior vice president and general manager, head of technology solutions at SAP, says the difference between now and several years ago is that almost all modern applications have some kind of standard interfaces exposed or exposable – typically based on Web services. However, he notes, EAI is a complementary capability that hasn't gone away just because of the rise of SOA.
In some cases, EAI is critical to functionality. For example, he notes, if you have an application that uses a Web service to expose purchase orders, the Web service may conform to certain standards but the data that is being transported may not have similar standards. "There are always two parts to any of these things -- the standards part and the data part," he says.
The data that is exposed, like a purchase order, may be expressed one way in an SAP application but in a different way in other applications within the enterprise. Therefore, Chikarmane notes, you need something in the middle to translate one application's version of that PO to another application's version of the PO.
"That is where you need EAI, regardless of whether both sides use Web services. There is still a need to make data intelligible to both sides," he says.
Like other major software vendors, as the need for integration emerged, SAP developed its own EAI offering, which eventually grew to embrace SOA, too. Originally called Exchange Integration (XI), the EAI tool, part of the NetWeaver product stack, was renamed NetWeaver Process Integration (PI) and is sometimes just called SAP PI. It now includes SOA capabilities, too. Its most recent version is PI 7.3. It can be used for integrating SAP and SAP applications, SAP and non-SAP applications, and even non-SAP and non-SAP applications.
Manish Agarwal, head of the SAP practice at consulting firm Nagarro, says SAP PI is important for both EAI and SOA. However, he notes, because SAP was relatively late to market, many SAP customers standardized on other tools from third parties like Tibco. Many of them plan to continue to use other middleware for the non-SAP integrations. However, he stresses, SAP PI is a standards-based product, so it is fully interoperable with other non-SAP products. "The benefit to SAP PI is it is an easier integration to SAP compared to other EAI products because it is an SAP product. So, there is some "out of the box" content which allows faster integration into SAP," he says.
Mayur Khera, practice director, NetWeaver Services at KPIT Cummins, says choosing between EAI and SOA needs to be done on a case-by-case basis. "From an architectural standpoint it is better to move more toward SOA as much as possible unless the third-party site or company is not ready to adopt that," he says. As an example, he notes that a banking site might offer the capability to do electronic transfers but some banks charge a premium that not all customers are ready to pay. "It is a customer-driven decision, but from an integrator's standpoint, we encourage adoption of SOA," he adds.
Khera says in implementing one or the other, when there is a SAP-to-SAP requirement; they usually use SAP PI EAI. "When we have requirements where interfaces need to be made to non-SAP applications we leverage the Web services-based capabilities, and we write within PI so we can reuse the interface from one process to another.
"I want to stress, I'm not married to SAP PI. The key is that the SOA principles need to stay strong, and the architects need to understand the principle. Then, any tool can make this a success," he adds.