1) These abstractions are in our opinion the only option for BPM at this stage, this is most probably due to long time to maturity for BPM as documented at Gartner. Any direct development into BPMS provider API’s will result in tight vendor lock-in. On the down-side I guess the abstraction layer can become another ‘vendor’ that can lock you in…
2) Due to the features added (SLA’s, KPI’s, entitlement, Hold, Escalation, Filters, Searching, or a simple add-comment etc.) features do not need to be modelled or developed in the BP engine. This almost always results in simplified modelling, much reduced development and as a result faster turnaround times.
3) Most workflow engines does not cater for items that reached end-of-process, but in most cases business want to have this view.
4) This leads me to the next point, this solution leads to a much richer experience for the users, these users typically go though tough re-skilling, so you really want them to be enabled and productive as quickly as possible (get them to focus on the business rather than complaining about IT ).
5) Another benefit is that since there is a reliable set of features, it is possible to create procedures and methods, this relates to BA’s starting to know what they have and don’t have (another aspect of the product we have – decent analysis templates).
6) It is imperative that you don’t implement (duplicate) features that are available in the engines, and that you stick to the best-practice integration methods, you should not integrate directly on a DB layer if that is not supported.
7) Your design need to cater for future features in BP and CM engines, features not available today, might be available in the next release.
8) When this integration layer interacts with Enterprise systems (Rules engines, Legacy, Security, IN/Out Channels), make sure you spend the time to ensure these are loosely coupled.
9) Make sure you have a decent pricing model, you are creating a re-usable re-source, you don’t want the first guy to pay for all the infrastructure, and you need to make sure the infrastructure can scale.
10) BAM and Reporting should not be left for last, add it to this abstraction framework ASAP; SLA’s, KPI’s are the bread-and-butter of the users when going BPM.
11) Don’t underestimate the development effort for a decent UI.
12) This abstraction layer tends to get blamed for any down-time. So make sure you have decent monitoring and logging, and as we seen, make sure you support channels are in place to ensure they can get to the real cause of a failure.

These are but a few of the things I’ve learned when using our product, and I’m sure in a year I could add another dozen points.