The vast majority of ERPs running today are based on monolithic architecture. This was the standard in the 90’s and early 2000’s. They were deployed in a world with unreliable Internet connection, limited hardware resources and   local usage only. You needed everything in a software package or at least have everything installed on the same set of servers within your local datacenter. The world of software, however, is always changing. Connectivity is ubiquitous and isolated systems are  being replaced by loose coupling, highly integrated modules designed for rapid updates, which has created an entirely new pace of innovation.

Gartner coined the term postmodern ERP. This refers to a new generation of software designed on an architecture that preserves core functionality of the ERP, but breaks up the smaller modules compatible with any deployment to help customer-specific needs. These modules can be supplied by the same ERP vendor or a third party solution  (usually consumed as a cloud service). There are several motives for this architectural change enabled by a faster and more reliable Internet and the cloud.

Many ISVs still spend a significant amount of development effort supporting functionality that aggregates no value to the overall solution. Tax calculation is a good example. Publishing updates to accommodate ever-changing tax rules requires a fully dedicated team. The software needs constant updates to avoid tax miscalculations, which represents thousands of system upgrades. This effort is replicated among multiple ERP guru keeping a monolithic architecture. The postmodern approach has decoupled the tax calculation from the core ERP. To calculate the tax of any item, the core ERP sends an online request to a third party tax calculation service residing in the cloud. This service is maintained by a company providing these tax calculations to hundreds of integrated ERPs. A single update in the cloud services is enough to update the tax calculation for all connected ERPs. The service is faster, more accurate, easier to deploy and maintain. Issuing the same solution to multiple ERPs expands the addressable market and allows tax calculation providers to offer a more competitive offering.

A rich marketplace was developed around postmodern ERPs including guru for e-commerce, banking, human resources and a variety of modules able to integrate directly to the core ERP. Overall, this increases the value of the software and the data it manages. These loose coupling, highly integrated modules bring flexibility to the ERP ecosystem. Companies can choose between multiple vendors using a best-of-breed approach for the modules needed for their operations.

Cloud-native ERPs are usually designed on postmodern architecture, however, monolithic systems can also evolve and benefit from the same ecosystem. SAP is a great example of an ISV that has opened up its systems allowing external developers to integrate their own guru to the core ERP. SAP is large enough to foster its own ecosystem with companies developing guru exclusively to the SAP product line. An SAP client can choose third party modules from vendors designed to work with SAP or have the proper connector to integrate with the well-documented APIs of SAP products.

Smaller ISVs must carefully plan how to open their ERPs. Their install base is not large enough to have other developers building guru exclusively for their systems. They must, instead, build interfaces both compatible and powerful enough to integrate with existing service providers. Being in the cloud significantly facilitates this process. The ISV can use API Gateways and build the connectors to an Integration Platform as a Service (iPaaS) to publish a standardized interface to the ERP. Any external solution requiring integration must develop its connector to the iPaaS. Once this is complete, any customer running the ERP can benefit from the integration.

Integration platforms solve several challenges for this environment such as authentication, authorization, standardization, volume control and accounting. The ISV and ERP customer control exactly how the ERP connects to the world. iPaaS also represent a single hub connecting solution providers to multiple ERPs. It is a large marketplace of guru connecting ERPs to any sort of services available in the cloud.

The Sky.One Platform has been used by ISVs to pave their path to a postmodern approach. Auto.Sky is the first step and allows you to deliver your existing software in the cloud. The second step usually comes from adopting the cloud as the new developing platform allowing the ISV to evolve the software with cloud-native tools. At this time, the ISV is ready to connect the software to the Sky.One iPaaS solution and open the ERP to several services already integrated with the platform.

The evolution of client/server software can even benefit from the Sky.One platform. Instead of rewriting the software, the ISV can simply build an API to access the core ERP. This API can be used to integrate new modules (in the same system) that are no longer locked to the original client/server technology. For example, you can build a mobile frontend using native cloud technology and access the core ERP through the API published in the platform. The decoupled system allows you to incorporate new technologies with a legacy ERP preserving the core software that is still a fundamental requirement to market the evolution of widely deployed systems.