Enterprise packaged apps integration

Jean-Jacques Rousseau wrote, man is born free and is everywhere in chains. So too Enterprise app deployments are conceived as self contained yet everywhere are integrated with legacy and complementary apps.

My colleague Ken Vollmer and I are looking at packaged apps integration best practices and how these might change as some apps move to the cloud. We are asking:

What kind of middleware do you use?

How do you help process owners to assemble (composite) processes that have transactional integrity?

What do you do about the conflicting data models of apps from different stables – for example yours and those of a third party or perhaps in –house?

How far can so called “canonical” data models and meta data help to overcome such problems?

If you have experience and an opinion about what constitute the top three best practices in such packaged apps integration, or if you can warn about the three most egregious pitfalls to avoid we would love to talk with you.

I’m looking forward to hearing from you at glawrie@forrester.com


re: Enterprise packaged apps integration

George, you are asking a key question here. and the typical answer is EAI/BPM/SOA and the like. I am not a typical customer but a vendor. I am also a user however of my own software solution inhouse where we consolidate CRM, BPM and ECM and even some BI by wiring them to our back end ERP.

Best practices?

1) Middleware today is mostly supported programming. I believe that a middleware must in itself be an application platform that abstracts all the information from the various backends into a coherent user and customer experience. The best practice is to use a platform that does away with programming.

2) The key question is about how to enable/empower the process owners (PO)? BPM and development does NOT do that because of the bureaucracy needed to get anything working. Get a platform that consolidates and does not increase or freeze existing fragmentation.

3) If you want to empower the PO you need a common metadata model that is mapped to a backend (SOA if you must) but from there on through process, rules, GUI, content and monitoring you work with a consolidated metadata base across the board.

Three Pitfalls?

1) Wasting time and money on EAI/BPM/SOA and the like. Canonical data models as used in SOA are a dirty quickfix and create as many problems as they supposedly solve. Keeping track of all the data mappings is a nightmare in itself and making all the mapping work is a performance issue especially with XML.

2) Invest in something because it is 'a standard' or from 'a major player' without a thorough proof of concept.

3) Waiting for 'The Cloud'. There is such a lot of hype and the benefits are still questionable with the current technology. It is the ultimate form of outsourcing and leaves the users utterly at the mercy of how the various cloud vendors cooperate.