Skip to Content

The Enterprise Architect’s World – Episode 63

Intro: What’s the big idea?

Organizations typically run hugely clutterred up landscapes with multiple EAI/middleware tools like TIBCO, SeeBeyond, Vitra, Mercator, Fusion, JCAPS etc. In
order to ensure that information is passed through seamlessly across A2A and B2B scenarios. The big question that comes through while deciding on a heterogenous landscape footprint is how to retire/Integrate existing EAI tools together or replace them with a ESB of choice. At the highest level, very simplistically put, the answer lies in the dominance of your footprint of the Application portfolio and take the route. However, the answer is not so simple. Clients tend to make the mistake of taking the simplistic route – if it is an SAP to SAP interface, use PI, if it is an SAP to a non-SAP application, use PI, if it is a non-SAP to non-SAP application, it is a judgement call. The devil is in the details. So, if one one to be having an application that does the
complex math behind a few parameters, help SAP customers the ability to retire the links with an ESB of their choice, provide a Business Case, ROI measurement and the in-build logic/intelligence built-in to help consultants decide the best course of action, this is what it could look like. In this blog, I will explore the key facets of this decision making process. The logical end being a consolidation of the links/interfaces that could go through a series of logical evaluation, that would demonstrate the most practical path to be taken.

Gauge for Comparision
What to look for?

While evaluating the capabilities of the EAI tool, one would be typically looking at the basic function wrt high volume support, message Interface & Realtime Messaging, Connectivity, Open JCA Based Adapters for A2A and B2B, the basic Packaged Application Integration feasibility and the ability to manage the process Orchestration that would underline the true capabilities of Business process/business activity monitoring in terms of delivering the pre-orchestrated and encapsulated enterprise sevice. The otherattributes while evaluating the ESB Capabilities wrt the SAP Application landscape, the Service Repository & UDDI compliance (non-compliance) Service Registry, Process Modeling using BPMN or else, WS Security, Service Interface & Reliable Messaging, Distributed Processing Capability and the ability to monitor through a Centralized Runtime Governance become the most obvious choices. Beyond the technological capabilities, the cost and Operations of running and maintaining such an application, along with the Licence costs wrt value/volume or size of messages passing through and the subsequent Upgrade and running costs associated with the same need to be considered as well. While this becomes an important part of the decision making process, the availability of skillset to manage the installation, the cost of availability of these resources, the product Scalability and the associated performance, reliability to drive the subsequent Interoperability with SOA, would determine the need for such an evaluation to formulate this strategy around links/interfaces/Business scenarios.

Key parameters in terms of rating an ESB tool largely delves on the following key parameters around the EAI/ESB evaluation i.e. the Core EAI Capabilities that would be rated on a statistical model to provide weighted average to the capabilities of the tool would be as follows:

  1. Messaging: Ability of Sync/Async Messaging, Message Persistence, Message Size
  2. Quality of Services: Guaranteed Message Delivery: – EO – EOIO – BE
  3. Routing: Content Based Routing/Context Based Routing/Publish and Subscribe functionality being available
  4. Transformation/Mapping: Open XSLT based Transformation, Java based, ABAP based transformations
  5. Connectivity:Open JCA based Adapter Framework: -Support wide-range of third-party adapters – out-of-box adapters for A2A and B2B adapters e.g CIDX,RNIF, EDI, Development Framework – External Command Execution
    Proxy Framework to connect natively to SAP applications and other SAP NW capabilities
  6. Integration feasibility with SAP ERP and other SAP Process Components
  7. Pre-Delivered Business Content and Extended Business Packages
  8. Cross Component BPM for Serialization, Multicast
  9. High Volume Support: -Local Processing in Adapter Engine -Message Bulking/Package Distributed processing capability
  10. Human interactions and Shared meta data management 

Tool Set/Development:

  1. Ease of Usage
  2. Architectural Constraints – Hub & Spoke
  3. Architectural Constraints – Bus Architecture
  4. Software Development Tool kits
  5. Design Time Governance
  6. Design Methodologies, Templates
  7. Global Metamodel using : CCTS Compliance and abstraction at the Business Object level to enable multiple Operations in the same WSDL
  8. XML Payload Validation/Schema Validation
  9. Error Handling Framework: Existing Alert Mechanism and CCMS
  10. Life Cycle Management : Transport Management and Versioining capablities
  11. Process Orchestration (BPEL) capabilities
  12. Data Archiving capabilities
  13. Job Scheduling without additional software licenses
  14. Runtime Governance : Centralized Monitoring Capability: Component Monitoring/Message Monitoring/End-to-End Monitoring/Performance Monitoring
  15. Interface Maintenance, Enhancement
  16. Security Framework: Support for security standards like FTPS, sFTP, Https

Product/Vendor Direction:

  • Product Upgrade Path
  • Installation and Deployment
  • Product Scalability and Performance
  • Reliability
  • Interoperability
  • Platforms Supported

Associated Product Costs:

  • Licence and Upgrade Costs
  • Installation Costs
  • Deployment Costs
  • Development & Configuration Costs
  • Availability of Skills
  • Training & Documentation
  • Maintenance and Support

SOA Readiness/Adoption:

  • Open Standards: – XML, WSDL, SOAP, XSDs, – WS Reliable Messaging – WS Security and SAML
  • Global Service Repository: – Enhanced design Capabilities – Service Registry and UDDI Compliant
  • Business Process Modeling (UML, BPMN)
  • Distributed Processing Capability: ESB Transactional Behaviour
  • Extensive B2B Support
  • Event Infrastructure/BAM
  • Flexible Deployment Options: Support of IT footprints from small to enterprise scale
  • Service Enablement- Capability to publish the service
    Middleware Interoperability

Summary: (Dashboard)

  1. EAI Capabilities: The ratings
  2. ESB Capabilities
  3. Cost and Operations

The Business Case Builder:

  • ROI Calculator
  • Integration Platform Requirements
  • Technology & Tool evaluation
  • Decision Tree for Integration Strategy
  • An ESOA based Enterprise Application Integration Roadmap
  • Comparison of the PI based Integration data with that of the current EAI
  • Realize total monetization benefits
  • Generates standard Reports -print friendly format

Key decision making Parameters:

  • Business Demands and Business Scenarios
  • Total Cost of Ownership (TCO)
  • Realize Total Monetization Benefits (TMB)
  • Total Cost of Operations (SLAs)
  • Total Cost of Implementation
  • Total Cost of immediate investment
  • Total Cost of MultiSkilled resource management

Key decision making Parameters:

  • Hardware Costs
  • Software Licensing Costs
  • Infrastructure Set Up Costs
  • Infrastructure Operations Costs
  • Training Costs
  • Travel Costs
  • Implementation Team (#of FTEs) Costs
  • Product Support Cost


Most of the customers today, with whom I have these discussions with, endorse this idea. The age-old principle of driving an enterprise-wide services meta model and being made a reality with interface/link consolidation. SOA is just a byproduct. With this approach as the form foundation, the SOA roadmap becomes a reality with seamless integration. When the links have been identified in broad buckets of A,B and C class ones, there emerges a clear path with the way forward in terms of interface rationalization, lower costs and most certainly, the added benefit of inching toward interoperability. With this aim in mind, the move toward Cloud-based applications becomes a much more real proposition. A Purchase Order has the same structure, the Sales Order thhe same, the ASN, the Supply outlook etc. All this leads to the same XML format being used, and interoperability has a greater chance of success, which has a direct impact on IT spend. What we discussed and building here is an input of the following

1. Integration Requirements
2. Evaluation of EAI Tools
3. TCO Calculation
4. TMB (Total Monetizeable benefit) Realization, which gives us the desired structured approach toward Middleware replacement as follows:

Integration Patterns
Integration Roadmap
ROI – based on a Non-discounted/discounted cash-flow model to calculate the NPV over the next five years ro derive the benefit of this exercise.
Business Case Builder, to bring the CIO/CTO Organization at par with the CFO (Read the loan shark). And hence, the need for this. Visit for more details and the BPX wiki to work on this project. Of course, this application cannot consider the internal political equations that drive such decisions as well. For which no application can do the trick, the best approach to sort that out is to use a coin. Any currency will do.

1 Comment
You must be Logged on to comment or reply to a post.
  • During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.