The Sametime Blog
If anyone's opinion should be taken into account on these things that would be Carl's. I'm pleased to see that he thinks we did a good job with the Proxy and that he qualifies it as a good replacement for STLinks. Thanks, Carl.
Marlon Machado 100000PEST email@example.com Tags:  sametime enterprise-connect cebp uc 2,100 Visits
As you may know, I demonstrated our recent integration with Ion Objects at Lotusphere. I blogged about it way back in December and I got a few questions from some of you about the integration. I showed the integration live at the Sametime pedestal at Lotusphere and we're going to do the same at Enterprise Connect. This time, though, we're going to demonstrate the integration at the CEBP pedestal.
John Kotch, Founder and Chief architect of Ion Objects is going to stop by the CEBP pedestal throughout the week to hang out and talk about the many cool CEBP applications they're planning to offer their customers now that Sametime is just another object in their framework.
Make sure to stop by the CEBP pedestal if you want to learn more. Here's a short overview of the integration:
Webcast replay available: Leverage the Sametime platform to build Communications Enabled Applications
Jacques Pavlenyi 1000002W2A firstname.lastname@example.org Tags:  communicatons-enabled-bus... unified cebp webcast uc communications #ucoms sametime 2,024 Visits
On November 10, the Lotus User Group hosted a Webcast by Marlon Machado, Product Manager Sametime Platform and Solutions at IBM Lotus. The Webcast was titled "Optimize Your Business Apps with Communications and Collaboration Services”. For those of you who could not make it, the session was recorded and is now available online for limited time, free to LotusUserGroup.org members. You can watch it on the LotusUserGroup.org site here.
There's an interesting article in eWeek titled "Unified Communications Adopted in Parts by Many Companies" (you can find it here). The author touches on a series of interesting findings that validate my view that UC adoption is more effective in the context of enriching business processes to enable people to collaborate or to participate more effectively or, as we like to say, in the context of CEBP.
First, the author quotes Mathias Machowinsky, an analyst with Infonetics, who says UC can mean whatever you want it to mean. This is a good thing because no two companies do things the same way--well, they do but they don't. Case in point: all banks do loan origination but the people and the corporate culture of individual banks influence the way loan origination is actually executed. Those nuances are the reason collaboration and communication services may be needed (or not) to enhance the business process. This falls well in line with our view of CEBP: you don't do CEBP with a closed product; you need a platform flexible enough to allow you to do what you need.
Secondly, Machowinsky recognizes that multi-modality is key and he points out that there is no absolute definition for the most commonly used modes of communication; that each company has different requirements and that choices depend on need. Moreover, that choices are driven by the needs of day-to-day operations. Again, well in line with our vision. I've always said CEBP is driven by line-of-business, not by IT.
Then the author goes into whether UC solutions require a PBX. I say it depends: if there's a PBX in place, a sensible UC solution should leverage that investment and integrate with it to help the customer get the most out of it. From a CEBP perspective, what's needed is the ability to call a person, not a location or a device, in order to minimize or eliminate human latency. So, what matters is the ability to integrate with what's in place and with what people use.
I find it interesting that, in the article, a Chicago-based company decided to adopt Microsoft's UC solution integrated with an Avaya PBX but they still use an external audio conferencing service "...for investor calls where you may have a few thousand people." From a CEBP perspective, scalability and availability are crucial. Once you move from BP to CEBP and your corporate culture internalizes the new modus operandi it's hard to go back. It's like going back to a 2,400 baud modem after experiencing broadband.
Overall, I think it's a good article. It validates some of the principles upon which we've built our CEBP strategy and confirms many of the trends we're seeing in various industries. It's a good read.
About a week ago I wrote a post on this blog in which I asked our readers two questions:
I asked that any responses to these two questions be posted in the form of comments on the corresponding post. So far, I see 58 people have seen the post but no comments have been recorded.
If you have an opinion but would rather not comment on this blog please feel free to send me email. My email address is my first-name initial (m) followed by my last name (machado)--no space in between--at "us" dot "ibm" dot "com".
I'm really interested in your opinion and any feedback on the subject will be greatly appreciated.
Marlon Machado 100000PEST email@example.com Tags:  strategy web-browser expeditor cloud cebp 1,869 Visits
Today instead of giving you something to make you smile (or just roll your eyes) I would like to, instead, ask you, dear readers, a couple of questions.
I'm interested in your opinion because, first of all, I'm very curious about the make-up of the readership of this blog and I hope your feedback will give me a better idea of who actually reads this stuff. Secondly, because I think these are fair questions to ask.
The only thing I can promise you to do with your feedback is to internalize it and use it to enrich the awareness I rely on to nurture my decision making. If you feel so inclined as to indulging me with your feedback please feel free to comment on this post.
The first question I'd like to ask is: What's your take on the direction we're setting for the Sametime platform vis-a-vis CEBP? If you recall, our take on CEBP basically says that CEBP is about collaboration facilitated and empowered by unified communications. Moreover, we're saying that, to be effective, CEBP must be intimately linked to business process management (BPM). We call the whole thing BPM + UC² = CEBP and the BPM world looks at it as "Social BPM" (see this post for more on the philosophical underpinnings of this rationale).
My second question is: Do you see things such as CEBP and Cloud being delivered exclusively through the Web browser? The reason I'm asking is because we're seeing the Web browser as the easiest way to implement many of the CEBP scenarios we're working on. We're working with the WebSphere Portal team in building templates for industry use cases in banking, retail and insurance and a few work streams we're pursuing with the IBM BPM team and a few select business partners are also centered around Web browser interfaces. I'm also noticing the emergence of an unwritten assumption that everything coming from the Cloud must be delivered through the Web browser.
I don't think this should be the case because not all applications are suited for the browser--especially in situations involving task workers. I happen to believe the idea of heterogeneous mashups--the kinds of applications you build using Lotus Expeditor and, by extension, the Sametime Connect client--is also a viable proposition for both, CEBP and Cloud alongside the Web browser particularly for task workers.
I'm looking forward to hearing your opinion about these two issues.
Have a good weekend, everyone.
I want to elaborate a bit on the ideas I rambled about on one of my previous posts about how UC without collaboration doesn't do the trick and how this makes IBM's vision for Communication-Enabled Business Processes (CEBP) better than our competitors'.
Humans are wired for communication. We just cannot shut up (some more than others) and that's why our brains developed the ability to create language as a coding system to express ideas. This is also the reason our bodies evolved to have the anatomical features that allow us to talk and not just grunt and howl at each other--we still do that in general but that's another story. In short, communication is natural to us and we will communicate no matter what; even when we have nothing important to say (Twitter anyone?)
Collaboration, on the other hand, is trickier. We are social animals but human nature is not necessarily wired for cooperation. Instead, we are wired for survival at a very individualistic level. Our brains have evolved to understand that cooperation is a more cost-effective way to survive than going it alone and, arguably, having learned to internalize that understanding is what makes us civilized. However, collaboration is learned behavior and that's why it doesn't come as natural as communication.
So, when we put the two together and we end up participating in a CEBP having the ability to communicate with others doesn't mean much unless we have something to talk about, i.e., a context. Some of our competitors will tell you that CEBP is all about adding voice to everything, which suits them well because they sell hardware and phones, but what do you do once you got the SIP session going? What do you say besides "Hello!"?
In my view, CEBP is as much about collaboration as it is about communication. In order to get there you need to create the conditions that will provide the context in which people will collaborate before they have anything meaningful to communicate about. This is known as Business Process Management, or BPM, and IBM is a strong player in this market.
For us, BPM is not just about automating everything and removing people from the picture. It's about optimizing and creating context. Collaboration is a new theme within BPM and there are new buzzwords such as "social BPM" and "people-centric BPM" that reflect the ways in which this may play out:. The way I see it, collaboration is the realm where people operate within an optimized business process and communication is what enables them to collaborate.
We always say we don't do just UC. Our thing is UC² (Unified Communications and Collaboration). When you do BPM+UC² you're bound to get a better CEBP as a result.
We're working with the IBM BPM team in building concrete scenarios for CEBP. We're just getting started and we're very excited about the possibilities. Stay tuned.
People are asking me about how one would integrate Sametime and the new WebSphere Application Server v7 Feature Pack for Communication-Enabled Applications (WAS 7 FP CEA). The answer is you use the new Sametime 8.5 Proxy Toolkit to aggregate the functionality at the user interface level on the Web browser and let the servers sit next to each other or, potentially, run on the same box--after all, the Sametime 8.5 Proxy server is a WAS-based REST services runtime.
A customer service scenario where a Web application provides WAS 7 FP CEA-based co-browsing and reactive click-to-call can be enriched by adding presence and instant messaging capabilities through the Sametime Proxy. Co-browsing can be greatly enhanced by giving customers the ability to chat with a specialist on the other end of the firewall when talking is not an option for whatever reason. The same goes for peer-to-peer co-browsing scenarios.
I've been reading lots of literature about Communication-Enabled Business Processes, or CEBPs over the last few weeks. Most of it seems to revolve around the notion that CEBPs are nothing but voice-enabled business processes; that all you need to do to enable a business process with communications services is add voice to it. Other ideas around CEBPs call for taking the basic premise of eliminating human latency to the extreme and to actually measure how much a business process can be accelerated through communications enablement in actual minutes. I think both notions fail to present the full dimension of what CEBPs are and why we need them.
I agree that the main purpose of turning a regular business process into a CEBP is to deal with human latency. However, there are business processes in which human intervention is an intrinsic feature and, as a result, expected to be part of the process. I'm talking about processes where human decision-making must be rooted on reflection and careful evaluation of pros and cons, reflection that will invariable manifest itself as latency in the overall business process. I wouldn't mind, for instance, having my doctor taking enough time to evaluate the best treatment options for me or a fund manager taking time to go over a company's books and strategy before investing my money in it. What I would like is for both, my doctor and my broker, to be able to access all the contextual information they need to support the thought process and to have the tools to eliminate latency from their own decision-making process.
I think in these cases the goal behind communication-enabling business processes should be to prevent the process from slowing down as opposed to accelerating it just because faster is better. Doing this requires more than voice, chat and video. It requires a healthy combination of real-time and asynchronous communications and collaboration services to reduce not only human latency where needed but to enhance the context to support decision-making.
I think work styles have a lot to do with the perception that CEBPs are all about voice and reducing human latency. Traditional work styles tend to hover towards extremes: you're either sending email (the most asynchronous way of communication aside from snail mail and fax) or you get on the phone with that person if you can't walk into his or her office. And so, if these are your parameters, that's what you're going to try to optimize. When, on the other hand, you're used to live in a multimodal environment in which chat, voice, a blog post, an entry on a Wiki or a tweet can get you the information you need and when knowing the person who gave you the answer is just there without you having to talk directly to him or her, that's when you realize email and voice alone are way too extreme. Then you learn that just having access to the context in which that person operates can be enough.
Why am I talking about this? Well, this is how we define CEBPs in the Sametime world. We view Sametime as more than just real-time communications--hence the "UC²" thing. We do have the real-time communication capabilities that our competitors have and we also provide the asynchronous and context-based means to provide a better way to do CEBPs through Sametime Advanced and with the help of our sister products and I think we need to talk more about this. I know I should probably write this in a white paper at some point (and I will) but I thought it necessary to rant about it a bit here just to get it off my chest..
See you all in Orlando.