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.