Infosys Microsoft Alliance and Solutions blog

« Dallas – Information as a Service | Main | AppFabric (earlier “Dublin” + “Velocity”) as .Net Application Server »

Can ERP be a “Plug and Play” Replaceable Engine?

Recently, I came across an interesting IT strategy of using the ERP solely as the processing engine keeping it largely independent of the end-user UI needs, the presentation layer and business specific customizations if any. The whole idea was to insulate the end users from any impact of future changes in the IT strategy of the organization in terms of changing the technology platform and/or the ERP vendor.

The strategy basically translates into having a common future proof platform for the end-users leveraging the core ERP functions such as GL/AR/AP etc. and incorporating  business logic level extensions in a client specific “Logic Layer”. The presentation layer is largely independent of the package except where it cannot be totally avoided.

The pros and cons that I could think about this approach  are:


  •  De-coupling the IT road map of the organization with that of the ERP vendor
  •  Minimizing the support needs for the ERP other than the regular hot-fixes.
  •  No end-user training needed (provided the presentation layer is already in place)
  •  Having full control on the Business logic layer that is kept outside of the ERP package
  •  Future Proofing the customization logic


  • Easier said than done!!
  • The core ERP UI would still be needed for key users , so this is not totally plug and play.
  • Developing the business logic outside will be tedious. This might be  feasible only in cases where critical and unique business scenarios are at a bare minimum.
  • Would need multiple development tools beyond the ERP specific ones.
  • Replacing the ERP though theoretically possible will need significant effort to ensure the underlying functionalities work as desired

I did take some time to assimilate this as I have been “tuned” to think of the ERP as the core system. Making that dispensable/secondary was a bit difficult to digest in the first instance. But after giving it a deeper thought this did make sense in specific scenarios. I myself have been part of implementations which obliquely touch upon this concept, but have not come across an implementation which can direclty reflect this strategy.Googling these key-words  returned 106,000 results!

There seems to be lot of thoughts/ideas floating around this. How practical this is and how soon can we see some live examples is still to be seen. Till then, the question in the title of this post still remains largely unanswered for meSmile

It might be a good approach to think of in Greenfield implementations of ERP and having a common presentation layer for all the users. Possibly, the on-boarding of users in such cases can also be staggered with a plain vanilla application deployment to begin with followed by standard UI  and a business logic layer….

If you have come across something on these lines, I would look forward to hearing back from you.


There are places where these kind of requirements exists. But then the cons mentioned in your list are too heavy to take this risk. If anyone would want to use only the back end part of ERP and a custom front end then it will defeat the purpose of buying the packaged product. On top of it you need to know the package internals so well so that while creating the custom front end you do not impact performance. But i will keep the fingers crossed for performance if anyone goes with this approach ....

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter