The RevX Integration Pattern

Over the last 30 years, integrations have become a centerpiece of buying and selling technology. They’re no longer viewed as nice-to-have, they’re critical to the success of almost any sustainable go to market strategy.

Many start-up organizations begin their journey with human capital (fondly called swivel chair operations) and at some point, they're faced with the reality of human error, scale restrictions, and costs.

Thankfully, the product community has evolved and nearly every popular platform in the cloud has an API of some kind.

RevX remains committed to a services-based architecture with an additional API façade we call our xPI.  These two RevX technologies (our API and xPI) create an integration experience that overcomes many of the common short comings of today’s cloud-based API’s.

Popular cloud products still cling to an old paradigm in which the API is an afterthought - sitting off to the side with limited capabilities. In these designs, the underlying product isn't using its own API to deliver its core functionality ... instead, the API takes on an independent product life cycle and must be maintained in parallel to the product ... which isn't always executed very well!

Even in a perfect setting, there’s no “one-size fits all”  solution.

Modern development environments using SOA, ESB, micro-services, and other messaging centric development patterns isn’t without challenge. Service centric platforms can result in mega API’s which create a steep learning curve for developers tasked with integration due to the vast collection of services they must learn. As a result, the service granularity principle often gets abused. Endpoints with 20, 30, or 50 service methods often exist because the internal development practices make it difficult or impossible for a developer to properly control the scope of a given public service – it must live somewhere, right?!

These are some of the things we contemplate at RevX.

We believe that by using the API ourselves, it helps keep us grounded and that if we don’t like our pattern, how can we ask our customer to embrace it?!

A platform built to perfection by measure of the service granularity principle and SOA will result in a collection of well-organized services, but due to the fine-grained nature of their scope it can result in what we call a “chatty” integration … the need to make numerous service calls to complete a given workflow. This can be cumbersome and tiring for the integrating developers!

RevX has added an additional layer of technology we call our xPI which manages the orchestration of executing discrete services that make-up a workflow behind a single xPI request. This eliminates the burden on the part of a developer to make the 10 or so individual service calls to accomplish their task. Instead, the xPI implements the desired multi-step workflow behind the facade.

This RevX development pattern has enabled us to remain committed to services and messaging patterns while also simplifying integrations for our customers. Since our entire platform is developed in a services pattern, there is no functionality that our core system has access to that an API/xPI integrated customer doesn’t.