But when you’re doing business activities like B2B integration, e-commerce or Cloud computing, understanding context is important – lest you get distracted by technology (“Web 2.0 — wow, cool”) and your day-to-day tasks (“please send me that file!”) and you lose sight of the whole point of why you’re doing such things.

Which brings me to my take-away observations from the Gartner BPM Summit here in Orlando that’s just winding down. I gave two presentations on the role of BPM technology in B2B / Ecommerce projects. Here’s a few bits of wisdom from conversations with our attendees:

Consume B2B in the form of processes!

Whatever you think you’re doing – “B2B integration”, “e-commerce”, “Cloud computing” – remember that you’re implementing PROCESS. Thus, if you’re implementing the procure-to-pay process for a supply chain look for solutions that are process-aware, e.g., pre-configured with the right B2B documents, maps for translation, process visibility rules and dashboards. One way of consuming B2B processes directly is in the form of “business process networks” (BPNs) – in his own blog David McCoy briefly mentions BPNs and here’s our formal definition of BPN’s for Gartner clients (login required). Though not available for all projects, BPNs are a direct way to implement B2B processes, increasingly available for e-procurement, financial services, logistics, etc.

Selectively model B2B processes!

Janelle Hill and I had a great conversation with some nice folks of an international B2B / Ecommerce services provider that attended my session and wanted to explore options for their increasing need of BPMS technology (including process modeling and a rules engine) specifically so they could deploy configurable ecommerce projects with scale for their customers. We agreed that for complex, high-value and fast-changing processes that can be leveraged across multiple B2B communities, BPMS technology would be a great addition. But that for more static, less-complex processes that traditional application development is still fine. Its important to apply BPMS technology judiciously — I’ve blogged before on the issue of when — and when not — to use BPMS technology.

Instrument the process!

Once you’ve automated a B2B process across your community don’t miss out on the opportunity to “mine” that flow of messages and transactions to expose key performance indicators and drive process improvement. I had great discussions with a few clients about its benefits – such as sharing multienterprise process insight amongst your B2B peers – and challenges – such as plugging a potentially CPU-intensive BPM rules engine on top of your high-throughput B2B traffic! But regardless, nearly everyone agrees that one way or another IT users are long overdue to benefit from the decade-long oft-failed promised of “mining” B2B / ecommerce (and now Cloud) traffic! I have recently spoken to a few reference customers that specifically cited the valuable impact that process visibility has on their B2B projects.

I welcome your thoughts on all this!

As I post this I’m preparing to head back from the BPM Summit. The event has come to a close, but its impact will endure. Look to me for more on the role of BPM technology and discipline in the domain of B2B, e-commerce and Cloud computing!

… but indeed the fires of bacteria were raging such that the first time I thrust my hand deep into the core it nearly burned. (Yeah, my wife thought that was a dumb thing to do too – but you know, I simply didn’t count on my first bacteria party being such a big hit!)

So last week I spent some time on the phone with folks at Google (I know, harsh transition – indulge me) getting an update on the Google App Engine (GAE) and in particular adoption patterns for its new Secure Data Connector (SDC), which I recently referenced on a blog post regarding Cloud and EDI – The Ultimate Mashup. Precious few public details so far from Google on enterprise adoption of GAE and SDC, but they claim there’s viable quiet early adopters and I’m willing to give the folks at Google the benefit of doubt and a bit more time to make good on future public examples.

Also seeking to more easily link Cloud-based services to on-premise enterprise Apps, Amazon recently announced the Amazon Virtual Private Cloud to help drive adoption of Amazon Elastic Compute Cloud (EC2). It has partnered with Cast Iron to provide for Cloud-enabling integration as a service (IaaS) capabilities to help accelerate adoption of Amazon EC2. Here again adoption of IaaS to solve Cloud computing / SaaS integration problems is still light, but given the potential for Amazon to get real traction on EC2 I’m willing to give this new market time to mature.

So back to our steaming compost heap … of traditional B2B.  EDI tenaciously persists; as well do the providers of supply chain-enabling IaaS that carry huge chunks of EDI-based B2B traffic such as GXS, EasyLink, Inovis, and Sterling Commerce. While Cloud computing providers steal IT headlines and forge relationships with Boomi, Cast Iron, Informatica, Pervasive and other emerging purveyors of Cloud-enabling IaaS, the large providers of supply chain-enabling IaaS are quietly modernizing their networks and laying business intelligence across billions of transactions. (Follow the money)

Cloud-enabling IaaS. Supply chain-enabling IaaS. A delicate new sprout. The compost heap that nurtures its growth. Cloud. EDI. The point I made in my Cloud and EDI – The Ultimate Mashup post was that the Cloud and EDI world will soon be IT’s biggest Mashup ever. Expect some cross-pollination. But who ultimately will be the IaaS winners? Native members of the new Cloud eco-system? Incumbent carriers of most supply chain traffic today? Or yet others, jostling now to govern Cloud interactions? In the end, will the steaming compost heap of B2B nurture the Cloud?

• Boomi (a Cloud computing / SaaS integration provider) announces EDI support
• Google announces Secure Data Connector so GAE functionality better integrates with on-prem applications (login required: Google App Engine Comes Closer to Enterprise Adoption)
• GXS (the world’s largest EDI vendor) is quietly piloting encrypted EDI document archival via RAID 1 striping across Cloud-based storage sites Amazon S3 and Nirvanix.

Answer: They herald the ultimate IT / business Mashup: Cloud and Ecommerce, including EDI.

So … Cloud providers are adding EDI support; EDI providers are adding Cloud support. No, really.

Ok, but just don’t expect Cloud providers to voluntarily bring up EDI – it ain’t “cool”, you know.

One take-away from all these discussions is that despite cautious spending in this economny companies across all industries are still investing in B2B modernization projects. Investments include simplifying and improving the way they do B2B integration — for example, using community management and visibility to drive B2B process improvements (to reduce costs and drive growth).

On Friday I was chatting with Greg Faubert – CEO of Messageway Solutions – about the barriers to successful implementation of B2B integration projects and – shooting from the hip – I claimed that “the only barriers to successful B2B projects are politics and ignorance”.

Pithy, indeed.

But my point was that technology itself isn’t usually a barrier anymore. It might have been five years ago, but not anymore. Whether you’re still using EDI or SOA, doing traditional ecommerce or Cloud computing, there are plenty of B2B products and services availabile to help. Rather than technology, the barriers to success for B2B projects are usually non-technical, such as internal politics (IT group in-fighting and no shared B2B strategy), unrealistic expectations (trying to force one method of B2B onto customers — good luck), or simply ignorance (unaware of innovations like Cloud governance or packaged integration).

Similar barriers to success impact higher-order IT initiatives such as SOA and BPM initiatives, so perhaps its no surprise that B2B integration projects have similar challenges. Yet I still have quite a few conversations with companies who aren’t aware of the opportunity to succeed in B2B. No, not every technical challenge has been resolve (e.g., ubiquitous authentication – *sigh*), but, really, your challenges are less likely technical and more likely politics and ignorance — no friends of B2B.

I welcome your comments.

No, integration isn’t cool – as it was 10 years go – but it still rocks. Without it even cloud computing – IT’s latest darling – is just another set of IT “stove pipes”, reminiscent of the Circa mid-1990’s “stove pipes” of internal applications that took us a decade to integrate.

A few weeks ago Google announced enhancements to its Google App Engine (GAE), which included its new Secure Data Connector to integrate its cloud-based stove-pipes, with those in your data center – see Google App Engine Comes Closer to Enterprise Adoption. This week IBM and Hubspan announced WebSpan (I’d suggested “HubSphere”, but – hey – I only do marketing as a hobby) – an integration services offering using integration as a service (IaaS) that links stove-pipes of on-premise applications with trading partners and cloud-based functionality (my analysis of that should be published next week).

Interesting that for both IT mega-vendors these announcements were part of larger PR initiatives, GAE enhancements overall for Google, and one of many partnerships for IBM announced at its IMPACT event. By itself that makes my point. Integration isn’t the goal – it’s an IT pinch-hitter, an enabler for higher-order IT objectives like process improvement or cost containment.

A large retailer with 4,500 suppliers recently asked whether they should integrate their suppliers in-house or outsource the project; either way the goal is to automate then later improve the procurement process. A small biometric solutions company recently installed a packaged integrating process to synchronize sales orders between Salesforce.com and Quickbooks to lower costs and improve customer service (I’m publishing a case study on this). In both cases integration itself wasn’t the goal – it’s a means to an end. Context, not core. It adds value – like a beautiful patina on the coin of IT.

The result: consider using a BPMS for processes with the following characteristics:

·       The process is distributed, i.e., spanning multiple applications

·       The process involves complex rules

·       If the process is complex overall

·       If you have a need to monitor the process

·       The process requires improvement

·       If many instances of the process will be deployed

·       If you have sufficient availability of legacy interfaces to support the process 

We concluded that the way to use this list is to apply these criteria to your own list of internal company processes, using the criteria to eliminate processes that don’t fit the criteria, and thus are unlikely to produce a sufficient ROI when deployed via a BPMS versus other approaches. We also concluded that ETL (extract transform load) and other point-to-point style of integration projects were not very good candidates for BPMS technology.

Some form of these guidelines have no doubt been produced many times before, and likely often have been more rigorously vetted (see Gartner’s own Two Factors That Help Identify the BPMS ‘Sweet Spot’ – login required). But having advised clients pretty often on “When to Use (or Not Use) a BPMS” in the past, I thought this was a pretty reasonable set of guidelines. If we missed anything obvious, please post your thoughts.

Benoit Lheureux is Research Vice President of Gartner Research and Agenda Manager for the Application Platforms (Middleware) Research Area. His research focuses on application and process integration in multi-enterprise (business-to-business) scenarios. Benoit has 30 years of experience in the IT industry. Prior to Gartner he was a senior architect for BeXcom, helping to design multienterprise collaborative applications. Prior to that he was a senior consulting analyst at NCR Corporation, helping Fortune 50 corporations architect distributed computing solutions as well as to deploy and tune massively parallel database applications. Benoit also did system development on distributed database tools, database gateways, and clustered databases.

Coverage Area

·         SOA and Application Infrastructure Convergence

        o        The role of application infrastructure (Middleware) in SOA projects

        o        How various middleware is converging to support SOA, BPM and ERP

·         Multi-Enterprise (B2B) Integration & Infrastructure

        o        Strategy, technologies, trends and best practices

        o        Integrating packaged applications, trading partners, SI’s & SaaS

·         B2B gateway software vendors

        o        Market segment trends, functionality, vendors, pricing, etc.

        o        Example vendors: Axway, Sterling Commerce and webMethods

·         Integration service providers (evolving EDI VANs)

        o        Market segment trends, functionality, vendors, pricing, SLA’s, etc.

        o        Example vendors: E2open, GXS, Hubspan

Typical questions I answer from IT end-users:

·         What role does middleware play in SOA, BPM and ERP projects?

·         How is various middleware converging, and how do I choose which to use?

·         What factors should I consider in my multi-enterprise integration strategy?

·         Should I run my own B2B integration hub or leverage an evolving VAN?

·         Should I use EDI, AS2, XML, Web Services or FTP in my B2B project?

·         How much does it cost to do B2B integration myself? To outsource it?

·         How are VANs evolving – and what is Integration as a Service (IaaS)?

·         How do I choose between providers of B2B software and services?

·         How do I integration with my SaaS, marketplace or SI provider’s Apps?

·         What are successful strategies for Cloud Computing and SaaS Integration?

Detailed Research Focus

SOA and Application Infrastructure: The research area called “Application Infrastructure” focuses on the platform and integration middleware used to run and integrate applications. The research covers user trends, technologies, product functionality, product deployment, product and vendor selection, as well as return on investment, best practices and strategies for effective product selection and deployment associated with supporting legacy applications, ERP packaged applications, and new (often customer-built) SOA applications.

Multi-Enterprise (B2B) Application Integration: Requirements, trends, standards and technologies, particularly all forms of multi-enterprise infrastructure, i.e., B2B software and B2B services. Vendors I cover include providers of B2B gateway software, e.g., Axway (Cyclone Commerce), Sterling Commerce and webMethods, and providers of integration as a service including evolving EDI VANs (e.g., Sterling Commerce, GXS, Inovis), emerging internet VANs (e.g., Hubspan, ICC and SPS Commerce), industry consortia and marketplaces (e.g., Elemica, Liaison, Railinc) and specialists (e.g., BetweenMarkets, E2open and StrikeIron).

I publish the Gartner Integration Service Provider (Integration as a Service) Magic Quadrant and the B2B Gateway Software Magic Quadrant. I also publish research on these market segments, including decision frameworks for B2B projects (e.g., how to decide between in-house and outsourced B2B projects), vendor selection (what criteria users should use to short-list vendors), negotiating a good contract (e.g., pricing and SLAs), understanding the relevance of innovation on B2B projects (e.g., EDI versus AS2 and Web services), how to increase the value of B2B projects (e.g., self-provisioning, process visibility, data quality and compliance management), and the similarity (and distinction) of SaaS versus Integration as a Service (IaaS).

Adapters (or “connectors”) and Adapter Suites: Software used to implement “point-to-point” integration, to build composite applications, and to “bridge the gap” between integration middleware and application systems and data. This includes adapters for multi-enterprise integration, e.g., RosettaNet, Appliances.

Packaged Integration: Software, comparable to packaged applications, which is an “off the shelf” solution for application integration. In particular this includes packaged integrating processes and packaged composite applications. Various forms of packaged (or pre-configured) integration is increasingly used to facilitate both internal and multi-enterprise integration projects.

EDI specifications are generally heavyweight – often 25 to 75 or more pages. For example, Target’s EDI 850 (Purchase Order) Implementation Guide is 48 pages long. Despite standards even the ubiquitous EDI 850 purchase order varies substantially from supply chain to supply chain. (“Standards are great – everyone should have one!”).

The “EDI binder” schtick is clever because the degree of EDI complexity and diversity is daunting – so many companies often can’t or won’t deal with EDI themselves. FUD generates business, right?

So what about SaaS API’s? These are proliferating to the same degree that SaaS solutions are proliferating, i.e., fast. Are SaaS API’s better, i.e., easier to deal with, than EDI specifications?

In some ways, yes. For example, SaaS API’s are typically implemented using Web services via SOAP, REST or other Web technologies. You can directly execute these using any modern Web-enabled middleware and application development tools. This is generally easier than translating EDI, then importing or exporting data from applications.

But are SaaS API’s any less complex than EDI? Or any less diverse? Consider:

• Salesforce.com Force.com Apex API’s specification … 500+ pages
• Taleo Business Edition Web API … 50+ pages
• Nirvanix Storage Delivery Network API … 90+ pages

The dirty little secret of SaaS API’s is the “Devil in the Detail” – that, yes – like EDI, these specifications are, generally speaking, remarkably complex and diverse.

Robert Mitchell of ComputerWorld has learned that SaaS integration a leading cause of IT headaches – but many IT users are only now beginning to realize its complexity. But some companies understand this complexity – which may explain why Salesforce.com offers 90+ SaaS integration solutions across 40+ 3rd-party technology partners. This may explain why there’s a whole cottage industry of IT vendors (e.g., Boomi, Cast Iron, Pervasive, et al) that are focused on SaaS integration solutions.

It’s because, well, you know, SaaS APIs are cool – in an EDI Retro sort of way.