Consider Database Triggers in Your .NET Enterprise Application Design

I remember a time (a time long past) when the idea of tying applications together across functional (and, heaven forbid, departmental) boundaries was not only politically incorrect to the in-house user community, but downright frightening to some—and certainly intimidating to IT (or, as we called it back then, 'data processing'). The problem, from a business process standpoint, sprang largely from the fact that each department felt a strong sense of ownership of its systems—"That's our data, not yours!"—and the efficiencies of sharing it were not immediately clear, because 'data processing' couldn't really integrate processes for a price those departments wanted to pay. 'You want to see our transactions? Sure, fill out a request, we'll send you a printout ...'

Nobody in their right mind would stand in the way of business process integration today, when stripped-down lead times and in-house efficiency are mission-critical. This is especially true in the world of the Web, where the consolidation of information for Internet consumption often makes data-sharing a must. In the early days, this literally meant "messaging"—one process letting another process know that data for that process was available—and to some degree, that mindset still lingers. But, in today's business climate, there's no time in our process integration for digital courtesies. What's needed is messaging that puts data in your face: don't just say what's happening, go ahead and do what comes next! Don't just give me a status, give me the data I need to keep things moving!

The article continues at http://www.developer.com/db/article.php/3550636