I've mentioned this in passing before but it's important enough to be worth reiterating in a post of its own. In my opinion, it is the single technical failing of IBM connections.Cloud and the one technical issue I want to see resolved ASAP.
There are currently two sites that you can choose to host your IBM Connections.Cloud data in; the United States and Japan (there might be a third site but I'm not sure, so I'll be sticking with the two for now). You can only use your email address for connections once in the world and it limits the people that you can invite to your communities.
For example, say you didn't know about the two sites and you (Bill) just went through the default setup, your data would end up in the American data centre. Then say, Fred, who works at a more legally minded company decides that his data can’t be on American servers
In any case, Bill is now set up on the American server and he has a nice little community going. He decides to invite his friends, Bob, Jane and Fred.
- Bob is already set up on the American server because he’s part of another community there, so his existing password just lets him access Bill’s shared content.
- Jane has never used connections, so she’s now invited to set up a FREE new account. She does this and then suddenly she’s got access..
- Fred however, can’t be invited. He’s already a member of connections. You’d think that he could login using his existing credentials and access Bill’s systems but he can’t. People on the Japanese server can’t see data on the American… and vice versa.
This also means that if Fred creates a community then he can’t invite Bill, Bob or Jane. Unless they use a different email address.
In our case, being in Australia, you'd think that the solution would be for the newer communities to move to our region. We asked IBM about this but it turns out that moving is not a simple matter. In fact, the recommendation was to set up again instead.
The reason for this is fairly obvious if you think about it. If the connections server farms are closed environments then moving would break any comments, shares and discussions that you've had with other people in your "previous" region.
Moving is clearly not an option.
Setting up Two Sites
Setting up two sites is a much better option, so let's presume that Bill is an Australian who wants to engage Australian businesses. Bill wants to set up a second site.
Then there's the hurdles of setting up a second site where IBM expects a different domain name (more on that in another post), for simplicity, let's assume that Bill creates a new second site with a different email address.
Bill can now recreate his community on the Japanese server and engage Australian Businesses. Of course, while he can now engage Fred, he's no longer able to engage Bob and Jane because they're on the US server.
Bill now has a problem where he has two communities and no way to replicate data between them, other than manual intervention.
Where to from here?
I was going to go into detail and explain why simply moving users by letting them expire would still not fix the problem but I think it's fairly obvious (and tedious). Even if you let the licensing expire in the US and then tried to create the users on the Japanese server, you'd still face the problem of not being able to use the same email address and the loss of "historical data", such as likes, comments and even Verse emails.
I can see why IBM have done made the choices that they have. It’s a way of getting around the "fear factor" of the patriot act but unfortunately, it breaks connections. What connections needs more than anything else is a "connection" between their data centers... and with the Australian data center (and presumably a few others) looming on the horizon, it's clear that they need to resolve this problem quickly.
Google has perfected global single sign-on so I don’t see any reason why IBM shouldn't too.