White Paper November 2015 Technical Comparison of Perspectium Replicator vs Traditional Enterprise Service Buses
Our Evolutionary Approach to Integration With the proliferation of SaaS adoption, a gap has been introduced in terms of data interoperability. Integration methods and software have almost exclusively relied on the legacy ETL based approach of pulling data and are restricted by the limitations that come with it. According to a Gartner, the total addressable market for data integration in 2014 was $2.5 billion with an annual growth over 10% above the average for the enterprise software market. Moreover, Gartner and others have estimated the business analytics market is at about $20B per year, with a 30% growth rate. Based on these numbers, it is clear the need to organize and manage data is growing strongly. Most organizations have followed the path of using point to point integrations followed by scaling those to an ESB framework as the integration count increased. This middleware tier introduces a complicated layer that requires highly complex software implementation and an on going need for maintenance as data schemas change or integrations are added. These limitations are precisely where Perspectium differs, solving the standardization and control issues using native applications and agents. Integration Architecture Comparison In point to point integration, data flows directly from system to system. Point to point integration starts simple, but becomes complicated as it gets larger. With a hub, data flows through a central point. The hub may reformat the data, or make decisions on where to send it next. Hubs can simplify integration because they can connect systems with different data formats and data transfer methods. Hubs introduce complication because they add another place where development must take place and another runtime component. With a bus, all systems follow the same standards and can share in a standard method of transferring data between the systems. Any new system can plug into the bus, as long as it meets the standards. 2
Our approach is to install as a native application paired with a highly scalable Message Broker Service (MBS) that we maintain. By operating at this lower layer, we have the ability to use the native UI and control sharing/subscribing from within the application itself. Data is encrypted before it leaves and pushed in a single stream to multiple endpoints. This allows us to reduce the overhead involved with web services and keep control of what is shared within the application. At this layer, we also dynamically detect changes in data and rather than rely on a batch poll, we only push the data that has changed. This enables the best possible throughput and flexibility with the least impact to the publishing application. As datasets grow, scalability can quickly switch from a non issue to a critical problem. Years of application use will often push data sizes in the TB s and record counts into the 100 million record count+ range. Batch polling using SOAP will start to break down at this point. The additional overhead not only limits transfer time but also can cause significant application performance degradation to the polled application. This is where Perspectium Message Broker Service (MBS) comes in. Our MBS is a highly scalable and distributable cloud based service that we maintain in a high availability fashion. Data can easily be replicated to as many endpoints as desired with no impact or change to the endpoints. Combining the MBS with native applications and function specific agents provide the optimum solution for an unified integration platform. Perspectium Unified Integration Framework 3
Full Functionality Partial Functionality Feature ESB Replicator Notes Delivered as a Service Perspectium Message Bus is hosted in the cloud and provided as a Service. There is no need to dedicate infrastructure to the Message Bus. Few ESBs deliver their message bus as a service, and fewer provide it as a plug and play no maintenance approach that Perspectium provides. Native ServiceNow Application Perspectium Replicator is installed as a simple Update Set within ServiceNow. At the application layer, there is less overhead and many more capabilities available. Enterprise Service Buses rely on generic APIs that do not have any access to the full data schema. The burden is on the user to recreate the data schema in the integration. Limited to Incoming Web Service (SOAP) Perspectium Replicator is not bounded by the limitations of traditional web service interfaces and does not require incoming connections to any data target or source. With ESBs, SOAP has several limitations: max rows per query, batch processing, memory limits, semaphore usage, incoming connections, & user accounts required ServiceNow Auto Schema Update (detect changes and propagate) Perspectium can automatically detect and make changes to the ServiceNow database schema dynamically Native ServiceNow UI Perspectium Replicator uses the standard ServiceNow UI with the normal elements that are familiar to any ServiceNow Administrator. ESBs have their own application and interface to configure replication. Data Encrypted at Source With Perspectium Replicator, data is encrypted at the source and decrypted at the destination endpoint(s). Data is always secure. 4
Dynamic Real Time Replication (Push Based) By installing at the ServiceNow application layer, Perspectium Replicator dynamically detects real time data changes and pushes the individual record into the MBS. ESBs rely on batch processing to pull data (incoming connection) and only detects changes on its polling interval. Bi Directional Perspectium Replicator is fully bi directional from unlimited endpoints. Unlimited Endpoints Perspectium Replicator scales to an unlimited number of endpoints. Because Perspectium maintains the Cloud Service, this scaling is handled automatically for the client. Monitored Replication Perspectium Replicator s Message Broker Service is monitored to ensure messages are flowing from source to target. Perspectium will alert clients if we detect an issue with either a sharer or a subscriber. ESBs require the customer to provide their own monitoring solution to make sure that the integration is working as designed. Connection Limited (Store and Forward) With Perspectium Replicator, messages are stored and parked until subscribers are ready to consume them. Endpoint upgrades/downtime will resume consuming where they left off. ServiceNow to ServiceNow Replication Perspectium Replicator can integrate directly with ServiceNow. Common Database Endpoints (MySQL, MS Both tools support most common database endpoints. 5
SQL, Oracle) SDK Perspectium Replicator has a fully featured SDK to allow integration with any other application. Feature ESB Replicator Notes Highly Scalable/Available Cloud MBS Perspectium Replicator uses a highly scalable and available CloudMessage Broker Service. This allows for high throughput with low impact. In Depth ServiceNow Schema Understanding & Advanced Transformation Capabilities No need for Costly Implementation Services Perspectium Replicator has a deep understanding of hierarchical relationships within ServiceNow. Data can be enriched and transformed in unlimited ways, usually by simply checking a box. Views, transform maps, attachments, journal fields, reference fields, and display values can be quickly and easily configured exactly as desired. ESBs pull data as it exists within ServiceNow. Capabilities are very limited. Related records in additional tables must be pulled separately. For example, the entire attachment table will need to be replicated even if only 1 record has a reference to it. This is a major limitation with the traditional approach to data integration/replication. Perspectium is immediately implemented and only requires configurations by the Application Owners to determine what data to share and what data to consume. 6