Coding is the easy part of creating almost any enterprise app. The hard part is modeling the business process: Purchase order A goes from point B to point C to be signed by party D so that the approved amount can be deducted from account E. But what if the PO never makes it to point C? What if account E is closed?

The complexity of "simple" business processes yields requirements documents as thick as phone books (or, conversely, explains why some people get sick of pestering IT and write their own rogue applications). The intricacies of business logic also explain why enterprise application companies such as SAP and PeopleSoft continue to prosper.

The application giants are basically vast repositories of business logic , extending deep into vertical industries. The whole ERP proposition promotes that customers buy logic instead of build it. And the high-profile ERP failures have stemmed mainly from monolithic, inflexible collections of business logic that couldn’t possibly fit all circumstances.

The app vendors are doing better at easing customization and crafting meticulous, industry-specific versions. But the ultimate compromise between building from scratch and buying monolithic ERP has been obvious for a while: Break the monoliths into many manageable components that can be modified, mixed and matched. Yet the big enterprise app vendors have been less than enthusiastic. SAP has gone furthest, letting developers modify and recombine R/3 components?but only when the reconstituted apps run on SAP’s own NetWeaver platform.

If the app vendors insist on that kind of control, why not abstract the functionality of their business logic using Web services? After all, the desire to recycle existing, well-crafted business logic is arguably the main driver behind today’s biggest metatrend: service-oriented architecture (SOA). Most big commercial enterprise apps now offer Web services interfaces, usually through a bundled app server.

The problem is that remotely accessing the business logic of (instead of simply extracting data from) a business application means you add to your licensing fee. For example, SAP sells "portlets," mini apps that run on several major portal servers, that export various pieces of R/3 functionality. In fact, the big app vendors see spreading their application functionality around the organization as a highly promising revenue opportunity.

Portlets have a standard licensing structure, but the licensing details on exporting business logic via more organic integration methods remain sketchy. When I asked an SAP marketing director to comment, he wouldn’t speculate on where the lines will be drawn. But Gene Phifer, vice president and distinguished analyst for Gartner, has a good feel for what’s happening. "The vendors are leaning toward a model where they charge for that kind of access as a user license," he says. "And if you license it by the number of users versus the number of CPUs, then they can stick you with a significant bill. Users, on the other hand, are fighting that [plan] tooth and nail."