One Foot on the Ground, One in the Cloud

With more mission-critical applications such as CRMs and ERPs moving to the Cloud, the integration landscape is changing.  But what’s the degree of change?  Is it really changing that much or have the mediations (services that connect the internal and external processes) simply changed to support different data packaging, communication protocols and activation methods while continuing to perform the same functionality?  If your  integration toolset can’t adapt to these changes, you’ll have to  rebuild your integrations.

Let’s consider current real-world  use cases: integration using a premise-to-Cloud implementation and integration within the Cloud such as Cloud-to-on-premise or Cloud-to-Cloud.  Even though the endpoints are different and cross system boundaries, the base mediation involved is simple:

  • A request containing data is obtained
  • The data is processed
  • A response containing information is released.

This is a common pattern for processing information.  The data is often bundled into groups of messages (such as EDI from a Value-Added-Network) or larger batch flat-files that contain groups of documents or messages.

The Cloud changes the nature of these interactions because of the near real-time requirement.  An important difference between on-premise processing and Cloud-based processing is that transactions involving the Cloud are typically based on singleton documents that are processed in near real time.  Realizing the full benefits of many Cloud architectures, including Microsoft’s Azure, requires a shift in focus from primarily batch-oriented processing to a transactional, event-driven services model.  Cloud transactions frequently encapsulate small documents such as individual orders, invoices, status updates, or queries.

While the nature of document processing in the Cloud morphs from processing a few large documents to many smaller documents, the general business process model (as implemented in business rules) is unchanged, with the changes generally involving communications protocols and the activation model.  In traditional non-Cloud integrations, data is received and sent via push/pull methods such as FTP, direct file system access or event-driven systems such as AS2.  The Cloud changes this message exchange pattern (MEP) by introducing Web Services that operate over HTTP, offer security via SSL and certificates, and secure data using encryption.

This communication model lends itself well to the quick, lightweight approach of Cloud/Web-based communications.  And it doesn’t always entail transforming payload data to and from XML.  Keep in mind that while Web Services typically transport payload data in XML format, using SOAP enables the use of MIME attachments such as native EDI documents or spreadsheets; this capability allows our original integration data format to be tunneled.

Activation may change how the processes are initiated.  Traditional integrations generally take one of these forms:

  • Event-driven:  Process initiation occurs when changes are detected, e.g., a database insert occurs, or a file is written
  • Scheduled:  Process initiation occurs based on a schedule or time interval
  • Manual:  Process initiation occurs upon human invocation, via a user interface

In the Cloud, process initiation typically occurs at the API level, activated by receipt of external Web Service requests (SOAP or REST) or as part of a sequence of internal Web Service calls for process initiation or data augmentation.

The question you must answer is whether your current integration toolset can adapt to these changes or if you must re-design your processes to accommodate Cloud technologies.  Business process reengineering has a high payback and it’s a solid “Best Practice” to review your processes on a regular basis to look for improvement opportunities.  But being forced to redesign your integrations because the endpoints, communications methods and activations may have changed should raise a warning flag.  Is your toolset flexible enough to deal with changing data formats as well as changing mediation requirements?

Whether you put both feet in the Cloud or just dip your toe, the mindset change required is not as large as it seems to be.  Keep in mind that you are still recognizing that an event has occurred, processing the data from that event, and either publishing that information downstream or updating another system.  The end-points and the communication protocols have changed, but with a flexible toolset in hand, the essence of the business processes and mediations still remain intact.

Leave a Reply

Your email address will not be published. Required fields are marked *


*