Two weeks ago, I started out with a quote from a fellow systems developer that included the question: “I was wondering what the fascination with SharePoint is ‘out there’?” I have to admit, I found myself asking the same question about two years into our SharePoint deployment. Not that everyone was fascinated mind you; if you follow this blog you know I spend a lot of time marketing SharePoint to our small group of users. But what I did find surprising were the times people would ask me “why can’t I do [some fat-client system task] in SharePoint?” Why would they want to? If I follow this blog, I know the answer to that question – proximity. People don’t like bouncing from one thing to another during the course of the same task.
In an attempt to please some of the people some of the time, I now find it necessary to connect our fat-client systems to SharePoint. Readers of this series may have picked up on the fact that those fat-client systems are written in Smalltalk. I won’t debate the merits of Smalltalk over dot-net here, I’ll simply say: “if you’ve used both, you understand why I want to keep using Smalltalk.” Microsoft doesn’t make that an easy task, but to their credit, they do make it possible. SharePoint is accessible via Web Services and Smalltalk can take advantage of that mechanism. Right now, we have the talented people at TotallyObjects (Ipswich England) developing a Smalltalk to SharePoint connection framework. I’ve worked with these guys for many years and we tend to hand them, as their lead developer likes to say, our “tricky bits” of coding. If it were up to me, I’d hack my way through SharePoint’s Web Service interface and get one system working, and then repeat about 60% of that work in the second system. After TotallyObjects is done, I’ll have a reliable interface to SharePoint for all my systems.
Beyond the proximity effect for our users, is there any real benefit to linking front-office systems to SharePoint, or SharePoint to back-office data? Of course the answer is yes. Microsoft knows that, and that is why SharePoint 2010 will support better and easier connections to back-end data. Presenting back-office details in charts and dashboards has always been a cherished goal of SharePoint architects and, like so many other features, it was possible in 2007 and it gets easier and more powerful in 2010. Our users want this to be bi-directional; they say: “if the best place to keep track of contacts is SharePoint, why can’t that contact list generate a pick-list in those fat-client applications?”
Of course, we can do that; we have already made enough progress that I know I can read a SharePoint contact list, generate a pick-list and link, for example, one of our policies to a risk manager identified in SharePoint. But, what if that risk manager retires? How do we make sure SharePoint data that is in use by our applications, doesn’t get destroyed? Two things are going to make that possible. One is workflow; when a SharePoint user wants to alter something, we can determine in a workflow if that action is going to cause a problem. If there is a problem, we can point the user in the right direction to solve that problem. The second tool available to us is permissions. SharePoint’s granular permission structure makes it easy to let people do what they need to do without being able to do what they should not do.
But wait, this sounds complicated; are we sure there is real benefit here? Yes! It may be complicated but it’s less complicated than writing and maintaining custom applications – trust me, I do both of these things for a living. It may be easier for a developer to build and maintain a custom application, but developers are expensive. Likewise, it may be difficult to train end-users to design and maintain SharePoint, but it’s at least an order of magnitude harder to train them to write code! If we can get end-users comfortable performing in SharePoint, what was once the possession of tenured applications, we not only make the users happier and more productive, we lower our total cost.
We are about 75% of the way through our first migration of a fat-client system into SharePoint. The data is being entered and maintained in SharePoint today. Reporting will be the first application we wire-up using our Web Service interface. For now, we’re using an export to Excel. This has been a simple exercise and I don’t believe we have solved or even seen all the problems that are out there. Still, I know what it took to develop the system we eliminated and I know what it took to eliminate it – we are way ahead!