In our previous posts, we successfully debunked two commonly perpetuated myths about mainframe integration – that writing code is a requirement for sophisticated integrations and that you must run integration software on the mainframe.
Now that we’ve dispelled those two myths, let’s tackle another.
#3 – You don’t need workflow orchestration to build complex integrations
This is the most complex of the myths we’ll discuss. Often, software vendors will tell customers or potential customers they simply need to build a vast array of microservices to orchestrate the calling of those microservices. The microservices paradigm is a great approach for building modern software and designing services that only need to perform one function. But the nature of mainframe integration is such that this paradigm isn’t always ideal.
Many of the critical applications housed on the mainframe were architected decades ago. Trying to match up new technology with a 40- or 50-year-old architecture is not always a fit, and certainly is not the most efficient process. Sophisticated integrations typically hit multiple systems, not just a single application. For simple integrations, users may be able to use this approach with good results, but it is far too time-consuming to be used in complex integrations. To use microservices for a sophisticated integration, users would write code to build the integration and write code to orchestrate the workflows within. Having to write intensive code eats away at resources and uses valuable time systems architects could be directing elsewhere.
Solutions exist that eliminate the need for code and allow users to develop complex, multi-point integrations in a fraction of the time and cost required by traditional coding methods. There is integration software that creates an abstraction later in from the mainframe environment imitating a REST or SOAP interface, making applications unaware they are communicating with a mainframe. This gives you flexibility to change interfaces as business conditions require and allows you to change the underlying business platform – if, for instance, you migrate an application off the mainframe – without breaking other applications remaining on the mainframe.