09.12.07

In most areas of business software and services today, buyers face a choice between special, purpose-built software, and modules of more generic frameworks.  As a for instance, you want to manage a to-do list, so you can either use Outlook’s Task feature, or get a specific tool (or keep a list in Excel, but that is another blog post….). 

Likewise, when someone is looking to manage inventory, if they are an Oracle or an SAP shop, they can either buy the sister module for their stack … OR … get a “best of breed” piece of software from another vendor.  (As an aside, you should NEVER, NEVER, buy a module of a rival stack — believe me — just don’t do it…..!!!).

In the world of B2B, this problem is even more difficult to solve, as most B2B programs involve integration to internal systems (often via middleware).  Special purpose B2B programs tend to have excellent partner management, solid translation, and good orchestration capabilities…. but ….the business process management, analysis, and extensibility generally cannot hold a candle to the full-fledged platforms offered by webMethods (now SoftwareAG), TIBCO, IBM, BEA, Microsoft, and — increasingly — SAP.

This has led to a couple of approaches from the purpose built side

1. Build on top of a strong horizontal platform.  This is our approach in our partnership with webMethods/SoftwareAG, with our TG Enterprise Gateway offering.  The goal here is to deliver a specialized application for traditional high-scale B2B messaging on top of a flexible powerful framework (essentially having your cake and eating it too)
2. Expand the platform to become a full integration suite, and compete with the existing enterprise infrastructure vendors.  This approach works well for some environments, but creates tension in enterprises where there is a strong bus already in place.  It also has the unintended effect of reducing the effort expended to integrate to “competing” environments, reducing customer choice

On the other “front”, the large infrastructure players are trying to consume the B2B space, but face challenges of their own.  Things to watch out for include:

• solutions that are too “fine-grained”:  EAI is typically large numbers of small messages, requiring very fine control.  B2B on the other hand, tends to be characterized by much larger transactions (documents), but lower volumes.  Using a standard EAI approach is often sub-optimal
• machine to machine orientation:  EAI systems are often very geared to connecting systems, often using adapters.  Many will simply consider partners to be “systems”, and model standard protocols as “adapters”, but this is a problem because it can have the unintended consequence of tying a partner to a protocol, creating issues when a partner changes technologies
• in-line translation:  because they are optimized for high volumes, the focus of data transformation in platforms is operational efficiency.  The issue is that B2B mapping is quite a bit more complicated than EAI mapping, and the folks that do it are often not traditional developers.  Many products require mappers to use Integrated Development Environments (IDEs, like Visual Studio or Eclipse), which are often not the right tool for data transformation

The truth is that designing the correct solution for B2B is still very challenging, and the growing capabilities of the infrastructure platforms make it more challenging still.  For my part, if B2B is a major part of your IT operation, I still believe the base platforms are not there yet, but the gap is narrowing.  There is a lot of merit to the hybrid approach (a B2B product built on a strong general platform), but selecting the right approach still involves extensive evaluation and a strong knowledge of your own — and your vendors — technology strategy.