Using Today IBM announced the launch of Watson Workspace Essentials, an enterprise-targeted offering of Watson Workspace. Watson Workspace itself has been in preview since World of Watson last October, during which time it has matured and had quite a bit of development. The product is still available free of charge, but this offering is specifically aimed at enterprises with additional support, authentication and guest access support. For most of this year and last I was using the browser client (Firefox on Windows was my weapon of choice!). But more recently I’ve been solely using the Electron client. It is a very nice experience, small, lightweight and easy to use. The choice available is nice.
The plethora of chat and persistent chat software may seem exhausting and one may wonder why IBM should bother with Watson Workspace. The strength is cognitive and the ability to add applications around the chat. Alan Hamilton (belated congrats to our new IBM ICS Champion wrangler!) has blogged to give more concrete examples about this. It’s an area I’ve also been active in, working with Christian Guedemann since the end of last year on Watson Work Services Java SDK, which Christian used in a sidebar widget for IBM Notes and Eclipse. I used this in my ODA session at IBM Connect to push notifications to Watson Workspace within about 100ms of a document being saved. And I’ve used other apps to link Slack and Watson Workspace and via IFTTT recipes to post tweets and RSS feeds to Watson Workspaces (I have a Workspace for all questions posted to StackOverflow and XPages forum, and another Workspace for all tweets mentioning me and OpenNTF, to provide a single dashboard).
But this can all be done with Slack already, which also has APIs. APIs have been available from very early on with Watson Workspace and like Connections Pink APIs are at the core of what Watson Workspace and Watson Work Services are, encouraging app dev with the platform. But Where Watson Workspace adds benefit is on the conversational interaction, using natural language recognition and training to monitor for particular comments and take action as a result. And a whole workflow can be built from that first response, giving a powerful discussion beyond just a basic chatbot. Some of that was discussed at the workshop after Engage and I’m sure we’ll see more at Social Connections next month. But as an app developer, it’s worth bearing in mind that as well as using the UI of Watson Workspace, there’s nothing stopping you using Watson Workspace in the background behind an application, posting content to Watson Workspace for actions to be taken on the content and the result used back in the application.
At Social Connections I will be delivering a session titled “Using Watson Work Services Java SDK“, Tuesday October 17th 9:40 – 10:10am in Room 1. The full abstract is:
The Watson Work Services Java SDK is an open source project available on Maven Central or as an XPages library. It provides ease for Java developers to integrate with Watson Work Services, using standard builder approaches to set up queries and returning Java objects as the response. It avoids the need to manually manipulate JSON for both REST and GraphQL access to Watson Work Services. Come along to this session to quickly learn how to leverage this SDK in your Java projects.
I’ll be diving into the Watson Work Services Java SDK, giving some examples and talking about the cognitive aspects. Of course it’s only a half hour session, so I won’t be diving deep into the examples, but it will give a good detailed understanding of how to use the API. It’s already available as an OSGi plugin for XPages developers to use, and the documentation has been written to try to make it as easy-to-use as possible.
Some features of Watson Workspace are still pending, like editing and deleting a post, and these have in themselves generated a lot of discussion about ability to audit. Of course in a non-enterprise environment, there is less concern about content being edited or removed. But even with Twitter there has been controversy about individuals deleting a tweet although the ability to retweet makes it harder to deby responsibility for offensive and incriminating content. But when we’re talking about content from enterprise communications and a persistent chat where there is no need to “retweet” to followers because all relevant people are in that discussion already, there are bigger issues at stake about editing or removing offensive and incriminating content.
But the product has already been extremely useful for discussions with the offering team at IBM during the preview, for communication with the developers on the API and more recently for communication with the wider ICS offering team. These channels, built on a high degree of trust and respect, have been very useful during this year and Moments has also been very informative when out of the office for extensive periods.
Paul, from a user (non-programmer) point of view what do you think made it worth using this over other chat products ? I agree that Moments if great but if you only have a small number of group member and a small volume of update every day it become less important to catch up.
The cognitive aspect is just starting, but it’s something that I expect IBM to build on in the future. There are already a lot of out-of-the-box integrations like IFTTT that are low- / no-code. Yes, other chat products like Slack provide that as well, but partners like Workato are getting on board frequently. And if you look at what’s new with Slack over recent months, there are steps being taken that demonstrate influence from competitive products like Workspace and Teams: additional language support, changing terminology from “teams” to “workspaces”, email integration, a focus on enterprises. There are clear differences between Slack and Workspace architecture – Slack is separated into different workspaces and channels within them, Workspace (at the moment) has a flat hierarchy. The free Slack edition also has a limit on the number of messages retained, I don’t think Workspace does. The real strengths will come from “conversational workflow”, and this is not something that’s coded. It’s more around training on different ways something can be asked and different keywords within those queries, and then how the workflow will progress from there. Look for more on that in the future, but the big challenge will be customers getting their heads around what could be done and how it could be used, then spending some time to train it accordingly.