The Portal is Dead! Long Live the Portal!

I had a great time presenting at the Perth SharePoint User Group last Tuesday. I've uploaded my deck to my SkyDrive if you're interested.

The session talked about surfacing relevant information in the context in which it's needed. The example I gave is of a sales person who gets an email from a customer requesting an increase in the number of widgets in their current order from 1000 to 1500 units. Traditionally, this has meant that as the sales person I would have to do the following things

1. Look up the customer in the CRM system to find the contact history for the company and a link into the accounting system
2. Look up the company in the accounting system to check that they've got sufficient credit
3. Look up the widget code in another module in the accounting system to check that we've got sufficient stock to fill the order
4. If we don't have sufficient stock on hand, look up the widget code in the ERP system to see when we expect to have the stock available
5. If that's not soon enough, look at another module in the ERP system, as well as in the CRM system and the accounting system to find which of our other customers' orders we can defer to fill this change.
6. If I work out that it's possible and sensible to increase the order, change the order in the accounting system (and any other orders that may have been affected) and the details in the ERP system to reflect the change(s)
7. Finally, go back to my email system and respond to the customer with my decision. Update the details of the contact with the customer in the CRM system.

That sequence of events takes some time to achieve and, perhaps more importantly, requires a switch of context every time I switch systems (count 'em, there are 11 context switches in the 7 steps above!)

The promise of Office Business Applications (OBAs) is that this context switching will be significantly reduced or, potentially, eliminated completely. If, instead of the sequence above, I had the relevant information available as a part of the email then I could make and communicate my decision in the context of that email.

At the session there was a bloke sitting up the back who asked some very pertinent questions about what this session meant for the portal, and in particular for all that stuff we'd been saying about using SharePoint as the place people go to discover stuff, anything, they need to know about the organisation. Yesterday I got an email from that bloke, who turned out to be Jeremy Thake, pointing me to a great post he'd done after thinking more about the session and the questions he'd raised.

Jeremy's first concern seems to be that I positioned the Office Client tools as the place to get all the information you need, but for the past n years he's been hearing the message from Microsoft that SharepPoint is the the presentation layer for all of your back-end systems.

"Why not go to SharePoint for these things? Isn't that what the Business Intelligence Pillar of the SharePoint stack is for (Dashboards and Reporting Services, Excel Services Integration)?"

On the surface, he seems to have a point, but one of the key themes I was emphasising throughout the presentation was the ability of OBAs to surface contextual information that's applicable to the task or question at hand. I don't think this precludes the portal as an appropriate place to surface key business information, in fact there are a number of scenarios where it's eminently suitable. Of course, the portal's not just the presentation layer. It's also a set of services that can be consumed by the contextualised applications. It provides a repository for the information created by the use of client applications. It centralises the dissemination of information.

Jeremy's next concern is based on the premise that if we give users a richer experience than what they can get through a web page, they'll want to use it:

"My main concern is that by pushing the Information into Office applications, it will obviously look a lot more feature rich and perceivably be faster than any web page in SharePoint. I understand that Office development has been around a lot longer than I've been writing code, but this seems like a pretty aggressive marketing push based on the information out there"

Well, yes, I guess that's true. We've always talked about the spectrum of reach to rich (by the way, I love the fact that Jeremy's linked to Erika's blog - I've been addicted to it for a while now). My concern is that if we only focus on the reach and exclude the rich then our users won't thank us. To be fair to Jeremy, that's not exactly what he's asked for. He wants us to spend more time making the portal richer. That's a laudable goal (and one towards which we're constantly striving), but the fact remains that the rich client experience will always beat the web experience. With the constant improvement in the client platform, with integration with the video game quality graphics engine, the search, the RSS feed store, the networking awareness, the improvements to the Office UI and more, we'd be doing our users a grave disservice not to take advantage of it.

Next, Jeremy raises the question of Office Development (although I think he mainly means deployment). He comments on the model of apps being available offline and somehow makes this sound like a bad thing. I do understand that some people want complete control over the environment at all times, but that doesn't help our users be productive wherever they are. Jeremy also says is that the ClickOnce deployment model relies on users being online. That's not completely true. It relies on users being occasionally online. This model is generally more than adequate. If there's a component of your app that relies on the cloud for critical functionality, then disable it while the user's not connected, but let them get on with the rest of their work without being tied to the cloud (that's a beautiful image isn't it?)

Jeremy then asks "Where does SharePoint fit?". I don't think anything's changed. SharePoint is a great aggregator, portal and source of services. You surface the information it provides in the client that's applicable to the task at hand. If the task is responding to an email, then surfacing that information in that email is probably the most appropriate and efficient technique. In other situations, surfacing it in a Sidebar Gadget or on a web page or as an SMS message might be more appropriate. You use the right tool for the job.

Speaking of tools, Jeremy also had a concern about this diagram.

He seems to have inferred that because the word SharePoint is not listed in the "Professional Developers" sector of the diagram, that SharePoint doesn't feature in the professional Office developers' toolkit. That's not the case. Visual Studio is a great tool for deep SharePoint development work. For example, there are two new project types in VS2008 that deal specifically with SharePoint workflow.

So, I apologise if I gave the impression that "Office Development is far more superior to SharePoint Development", that was not my intention at all. My intention was to highlight some of the ways you can use the Office Client tools to make use of the great information aggregated and presented by SharePoint and your other LOB applications.

Finally, Jeremy quotes Steve Balmer "[Sharepoint] is the missing link between personal productivity and Line of Business Applications" and asks where that leaves Office. My take on this is that it makes Office (client) the personal productivity bit and Office (server - including SharePoint) the missing link.