I am currently acting as a second pair of eyes and an additional conscience for a client planning to standardize CRM and sales processes, with SalesForce.com as a hub and core enabling technology. I’ve been helping to think through what the future might look like with several different lines of business (each of which is supported by unique and varied legacy applications today) all unified, from a sales standpoint at least, in SalesForce.

One possible approach would be to embark on a massive customization project, adding all sorts of custom domain objects and features to SalesForce itself, creating a tightly integrated, if monolithic, solution.

A more palatable approach, to me, would be to leave SalesForce as “vanilla” as possible, letting it track customers, contacts and sales leads, and letting it handle the workflow associated with contracts (out for review, signed, approved, etc.). When a signed contract means it’s time to start delivery of goods or provisioning of online resources for customer access, why not leave that detailed and very business-specific work to applications built in standard technology (.NET, Java, Rails, etc.), rather than forcing everything to be built in the far less capable Apex programming environment within SalesForce?

Ah, but to do that, we’d need the ability for many disparate applications to listen for and respond to events issued by SalesForce. That’s hard to do, isn’t it? Frankly, no. And it’s a perfect reason to look at a service-oriented solution.

Mind you, I’m not talking about the full-stack, SOAP-to-nuts SOA that the Big Vendors tried to push for most of this decade. I’m talking about more of an architectural pattern that can be implemented with any of a number of lightweight, inexpensive (or open source) tools and frameworks.

It’s really quite simple – an application implementing some form of state machine / workflow process can send event notifications to an event sink. That sink can inspect data packaged with the event and publish it to an appropriate place (queue, topic, etc. – pick your terminology), where a waiting application can fire up activity that should happen as a result of the event.

All of this can happen using very simple technology – queuing systems, REST-based API’s, etc. Since all the activity is happening inside the four walls of the corporation, heavyweight protocols like SOAP are unnecessary baggage.

All that to say this: the problems that SOA attempted to solve remain in 2013. In fact, they’ve grown in number, with applications on mobile devices entering the fray as both publishers of and subscribers to business events. So SOA as an architecture is valid and relevant. It’s the heaviness and baggage associated with “Big SOA” that I still take issue with. Fortunately, in today’s technical environment, there’s no need to pay for a big commercial enterprise bus, or to feed it messages mummified in layers of SOA data.