What I Would Do With Groove

I've been getting great feedback from my previous post spawned by Groove angst. It does seem like Groove is at an inflection point and, given the state of things today, hard to see how it captures the imagination. As Don Dodge likes to put it, not only is Groove a vitamin and not painkiller, but its unclear what vitamins and minerals are even in the Groove pill.

Given that, I think it's time to dream again. After all, if you asked any Groover back in, say, 2004 if 'Offline SharePoint Cache' was their vision I doubt they would have had kind words for you.

So now in 2008, as part of the world's greatest Office Suite, don't you think its OK to be a bit more expansive? Putting on my virtual 'Chief Software Architect' hat, here's what I would do: mimic SharePoint not by copying data locally and pushing it back but by copying their architecture model.

Web Parts and Web Services

Here's a secret-- SharePoint is not concerned so much about the UI experience as it is about the data experience. Yes there are some nice icons and the color scheme is pleasing, but I'm confident SharePoint out-of-the-box won't be pushing the UI design and interaction experience. They'd much rather developers and ISVs flesh that out because, in addition to making things look pretty, they most likely also specialize their solutions for more specific business needs than a mass-market SharePoint product can do out-of-the-box.

So they have a Web Part architecture that folks like Bamboo Solutions (one of our partners) can develop against and users can drop in to their SharePoint environment.

And they have a Web Service architecture that folks like TeamDirection can use to send data back and forth from client to server and do interesting things with.

As a developer, it really is a Model View Controller architecture with the three elements being three applications working together according to contract.

If Groove is looking to copy SharePoint, then this is what it needs to copy. Better yet, because it's on the client, it will be able to do a few things only a client application can do-- most importantly integrate with data on your desktop, but also providing a rich visual experience.

Here's the vision:

No more effort with Groove Forms. No need to reinvent the arduous aspects of HTML form development on the client. Instead...

Go to Silverlight as the UI within the Groove client. This will let you leverage the current investment Microsoft is making to build a generation of Silverlight programmers. But add a wrinkle...

Make Groove a Special Silverlight Container that gives permission for Silverlight to integrate with the desktop. This allows Groove to become the world's best Rich Internet Application delivery platform. Which is great as long as you don't forget to..

Continually invest in Groove Web Services so that developers can easily pump desktop data in and out of these Rich Internet Applications and tie their current business processes together.

I am not saying Groove shouldn't talk to SharePoint. Groove needs to talk to SharePoint for SharePoint will be the way business will organize their data and processes.

But Groove's opportunity is just as big, only instead of coalescing data and process according to the macro business needs, Groove can coalesce data and process according to the micro Information Workers needs. Perhaps its a bit trite, but I do think Groove fits very well in line with Microsoft's former 'Information at your fingertips', current 'your potential' and general 'empower the user' vision.

There's nothing wrong with going back to your roots. You just have to re-dream it sometimes.

Ruminations on SharePoint and Groove

One of the great things about being a Microsoft MVP is the chance to go to the MVP Global Summit. Microsoft essentially takes the most knowledgable, most active and most vocal people in to answer lots of questions, preview what they're working on and shower you with positive vibes. The cynic would say its only smart tactics (which it is :), but judging by all the product teams representatives-- both the presenters and the note takers-- I certainly came away with the impression they listen to and value feedback.

Without going in to specifics, one of the more contentious issues seemed to be how SharePoint and Groove will work together. As Internet News reported of Ray Ozzie's and Steve Ballmer's speeches, they both received 'what about Groove' questions during their Q&A. Again without going in to details, the Groove folks are not enthusiastic on what is happening today and what is planned for tomorrow.

Of course, this shouldn't come as a surprise if you read this blog for TeamDirection was the premier Groove ISV with its bundled Groove Project Edition. The fact that I attended the conference as a SharePoint MVP is probably all I really need to say.

But I can't help myself.

Groove’s strength is its decentralized architecture, which should be the perfect complement to SharePoint’s centralized architecture. Two people gave me perfect examples of this during the conference: Matt, a SharePoint MVP I sat next to at several SharePoint sessions and Steve Ballmer. The example was being able to suck all the information from disparate sources onto your personal device and keep it synchronized.

Fundamentally this is a powerful architecture because it can centralize data on your desktop-- the flip side of SharePoint powerful architecture centralizing data on your server. In fact, it used to be Groove could house the .NET framework in its environment and thereby give developers a rich user experience with sophisticated peer-to-peer networking for gathering and updating all this data. I'd even go so far as to argue that Groove, because of its ActiveX and then .NET support, was a compelling vision of a Rich Internet Application framework.

Yes, I did say 'was', for you'll notice that the .NET framework is no longer accessible within Groove and their forms environment is too primitive for robust development. As a developer, I would love to see .NET reappear within Groove and give me the ability to integrate with desktop applications and the powerful peer-to-peer workgroup synchronization.

It doesn't even have to be Windows Forms as the UI. I'm most impressed with Silverlight and think that should be bolted on to Groove as a means to marry a better Rich Internet Application solution with a great distributed synchronization solution.

Think about it-- a unified model for accessing centralized (SharePoint) or decentralized (Groove) data with a common Rich UI tailored to the groups needs. In fact, Groove can enhance Silverlight in two important ways:

1) It could facilitate data synchronization among a group of Silverlight users without having to poll a central server.
2) It could be a recognized 'Safehouse' whereby Silverlight would be allowed to access local resources. That is, the one place where Silverlight will let you access local resources like your file system or other application interfaces.

What's the one complaint RIA developers have? You can't do anything with the local resources. How much of an advantage (and selling point) would it be if Groove could fulfill this story? I'm looking forward to providing Silverlight solutions married to SharePoint as a means bring value add to my customers working on a SharePoint hub. But I'd love to be able to take, more or less, the same UI, plonk it into a Groove spoke and provide uniformity for ad-hoc workgroups too.

I think you could even pitch 'RIA Safety Zone' in an elevator :)