No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Measuring the Size of the CEBP Market

Recently, I received a question about the size of the CEBP market. My knee-jerk response was that there is no CEBP market, per se. "Communications enabled business process" is itself a process, not a market; there is no SKU for CEBP.But in fact, there is a market for CEBP, and it is closely tied to integration. If you are embedding communications into business processes, you need to connect two things: the communications application(s), and the business process automation (BPA) application(s). You can't have CEBP without the "C" or the "BP." (You could embed communications into business processes without BPA applications, of course, but that wouldn't be much of an improvement from what we do now: "Once you receive a customer order, e-mail or IM me and I'll look it over" is not really communications-enabling the process.)

There are three areas that will contribute to the CEBP market:

* Professional services, which all but the largest companies will need to integrate their existing communications and BPA applications;

* Middleware software, to help companies integrate their communications and BPA applications on their own, "out of the box;"

* Packaged applications that include communications and BPA capabilities in a single software suite.

While packaged apps with everything included might appeal to the SMB market, most companies already have a communications infrastructure in place--why would they want another one from a third-party CEBP vendor?

It's also unlikely that middleware will have much of an impact in this space in the near term-there are too many protocols and too many business-process applications. It's more likely that vendors will partner with one another to make their software work together out of the box (see IBM Lotus and SAP, or iLinc and salesforce.com). That could change if the CEBP market proves fertile, and if communications applications are built on a common code base (i.e., SIP, 100%).

That leaves professional services, which will grab the lion's share of the CEBP market for the foreseeable future. And indeed, this is a rich market to mine. Unified communications add significant value to a company's bottom line when they are integrated with business processes, to help reduce human latency and shrink the time it takes to complete the process in question. But injecting communications such as presence/chat, conferencing and voice into BPA software is no small feat-from either a technical or a business-process point of view. Most companies will not be able to tackle the integration on their own, and they will look to their vendors and service providers for help.

Paul Sweeney, the Director of Innovation at VoiceSage [http://www.voicesage.com/website/index.asp] and the original questioner who asked me about the market size, says, "If it involves 'integration,' it isn't CEBP." That struck me as strange--CEBP is, in my mind, all about integration-until I realized that what he really meant was CEBP may offer an opportunity for companies to look outside the box for solutions to their-and their customers'--communications and business process problems.

As he put it: "I think that the outline you have works for big iron guys like Microsoft, IBM, Avaya, and Cisco. But I think there is an opportunity to go straight for the re-invention here, and I think these guys see that also (thus the jump from UC to CEBP, and why CEBP is played as being part of the Collaboration play). If you think of the 'process' as being data rich, with data context, and not dependent on any one vendor, then (de facto) you have an Internet based (web as platform), 'Systems Integration.' The question here might be one of perspective: do I really need IBM/Accenture in here, or can I build this/adapt this CEBP 'Process In A Web Box,' and deploy it myself? Given the likelihood of what Open Systems is going to do to the hardware side of things, I think anyone with a brain in these places is trying to figure out, 'how does what we do right now position us to be a service provider, not a vendor?'

What do you think?