Sonic ESB: Programmable integration

The pressure to integrate disparate systems across the enterprise is steadily increasing, but establishing connections between systems, even those designed for integration, remains a daunting task.

Traditionally, enterprises connected systems using point-to-point links and custom code. More recently, integration brokers--proprietary software for creating connections among multiple systems--emerged as another solution. However, point-to-point connections are expensive to maintain, and integration brokers have been expensive to buy.

Sonic ESB is one of a new set of products billed as enterprise service buses (ESBs), lightweight integration brokers based on standards such as XML and SOAP designed to work in a distributed environment. [Full story at InfoWorld...]

One of the things that really struck me while I was working on this story is that as these systems become increasingly flexible, configuration stops feeling like configuration and starts feeling like programming--in a really bad language. As I point out in the article, this isn't really Sonic Software's fault. Other tools suffer from the same fate. If any of them came out with a proprietary language at their core, they'd be criticized for not being "standards based." Consequently, you end up writing your "program" in snippets of 2 or 3 languages and stitching it all together with a bunch of GUI-based configuration. Some people think things like XLANG and WSFL are the answer to this problem, but I think they're syntactic arsenic. While I would welcome a standards-based work flow language, I don't believe it has to have angle brackets.

What can make this all work in spite of the difficult configuration is an integration architecture. To make use of these tools, you need to understand the tool and its concepts, but you also need a well thought-out plan for what is being integrated and precisely how that's going to work. You probably don't have an integration architect sitting around, so you're going to have to find the person in your organization who can take on this role and create the plan.

All this shouldn't scare you away, however. I encourage people to dig in and start working with these tools. Begin a small pilot project to find out what you need to do to create the integration architecture. For an organization with disconnected legacy systems trying to move toward being a real-time enterprise, the rewards are sufficient to merit the struggle up the learning curve.

Please leave comments using the sidebar.