A Purchase Order is a complex object which represents data stored in multiple, sometimes diverse, loosely coupled tables (sometimes these are even not rectangular today). Such complex graph of objects must be persisted in and out of the data base as a unit (not only speaking transactions, but also composition and association). Developers are tend to be more productive when working with the complete object, using a full or a subset of operations, depending on the abstraction level of the underlying framework. Complex object graphs like sales or purchase orders (having 100+ logical and physical tables) are very common in business applications (looking at sap again, probably). The operations running on them support a compensation model – as today's rich user interfaces often interact with multiple services in a given, predefined conversational fashion. As we all expect, these services may not all be read only –and even could be much more complex than crud. For example, each line item in a complex object graph actually calls a service to allocate inventory. As modification to these complex graphs needs to be still acid, these allocations must be rolled back if the user cancels (see reversible operations), or confirmed and persisted if saved. For this to naturally work, the operations should have built-in support for compensation, e.g service oriented transactions. The fact that these operations are reversible and cancellable (e.g restartable) provide guaranteed "forward only" execution (and server side scalability), the integrity is ensured by restarting execution until completed. Moreover, many batch oriented tasks are simply far too large to write compensation logic at once, yet need multiple service, logical (and usually in the end, database) transactions. Of course, in our multi-tenant world, the actions executed support multiple services in a flexible, pluggable model (see dependency injection and service discovery, but no uddi) – some application logic is regularly changed for every customer of the upcoming application (e.g. taxation, commissions); or multiple algorithms are known ahead of time but are applied based on context. And one of the hype topics – BI. BI is desired when the user is working (information at the fingertip), not just when they are actually analyzing information. IMHO, to be usable for the business, BI model has to derive from the original data model, and not the application entity model – this is a mistake easy to make.