Business – not SharePoint Solutions

imageTwo recent projects have caused me to realize that SharePoint has finally arrived in our small organization. I don’t mean that it’s here and in use, it’s been here since 2006. I don’t even think I’m talking about “adoption” the way that word is often used with respect to SharePoint. It’s arrived in that it’s now part of the permanent landscape and that’s a good thing. It’s good because people aren’t fighting the idea of SharePoint. On the other hand, SharePoint has only managed to shove itself into the mix. It isn’t the dominant player. It isn’t calling the shots. It’s on the team but it has to play by the same rules as everything else.

One of the projects we are close to completing has SharePoint in the leading role. The application is a portion of our payables process and people are now creating payment requests in SharePoint. Other people are reviewing those requests, adding comments and still other people are approving those requests. If all of this lived in SharePoint, SharePoint would rule the day. However, the back-end of this process is a desktop application that takes those approved requests and prints checks. That application also creates ACH transactions and wire-transfers. Eventually SharePoint will be the starting point for all those transactions, but everything SharePoint does has to feed that system.

Other processes are involved too. For example, we can’t present a payable for payment without making sure that the person / company we are trying to pay isn’t a terrorist. In that case, the back-end process is actually the starting point. We check vendors before we authorize them to be paid and we continue to check to make sure they don’t become terrorists. I suppose the back-end stuff could be done in SharePoint but it’s easier the way we’ve done it.

Note: All of those processes involve data that is stored in SQL Server and my crew had to battle with every imaginable issue (all of them permissions) to get those connections working reliably.

The second system we are working on is a storage system for some very important information. In order to make sure this stuff is available when we need it, it will exist in SharePoint on premises, some of it will be replicated in SharePoint Online and some will be replicated on a bunch of iPads. In this case, SharePoint is cast in the boring supporting actor role. Yes, SharePoint is holding all the stuff in house and holding all the stuff online, but the iPad app is the cool kid. Accordingly, SharePoint has to try to fit in.

We decided that the way the content is organized in the iOS app will determine the way it is organized in SharePoint. In other words, the list and library structure in SharePoint will correspond to the structure of root categories and detail topics in the iPad app. The app design is intuitive, something that SharePoint struggles with out of the box. The design is simple enough that it won’t take much work to make SharePoint look and feel consistent with the iPad. Still, a few years ago, this wouldn’t have been a consideration.

SharePoint and SQL Server was an arranged marriage and like many of those, it works, but it’s weak on love. We are making the connections work, the connections do work, but they all seemed to have taken more effort than should have been required. SharePoint and iPads? I’m pretty sure that was never part of anybody’s plan, but it has to work. We have to build a solution that spans those platforms and looks like it was meant to be.

Welcome to the real world SharePoint.

Episode II

imageShortly after I posted the first episode in this little mini-series on leaving SharePoint, Christophe a.k.a. @PathToSharePoint suggested that Office 365 might be the answer to the problems we are having. I responded, telling him SharePoint 365, sorry SharePoint Online will have a role in our future, just not this role. It is as if SharePoint Online had shown up for an audition, missed the lead role but got picked up as an extra on a different film. Hey, that’s show-biz.

The reason we looked at SharePoint Online was because we thought it would be easy. In some ways, it would be easy. Unfortunately, the ways in which it would be easy are the ways it would be easy for us. We already know SharePoint, so working with SharePoint in the cloud would be a snap. We already have the content organized in SharePoint so moving it to the cloud would be a snap. We already own MetaVis, so moving our on-premises SharePoint stuff into the cloud would be…what’s the word for a snappier snap…let’s say easy-peasy. The problem is that we’re supposed to be making life easier for our customers. How does that work for me?

Once when I was discussing two options with my boss, he summarized my arguments by saying:

“Let’s see, the business benefits are the same. Option one is expensive but it would be easy for you. Option two is cheap but it will be harder for you to work with. I’m going to go with option two.”

That’s the thing with business problems, the solutions are spread across a spectrum of benefit. If we can’t have the whole rainbow, we have to focus on our members and our customers first.

The big reason SharePoint Online would be easy is because we are going to use it for a part of our normal business process. We have some stuff in SharePoint on premises that requires high availability. Specifically, it needs to be available when our office is without power. We don’t have any redundant power options, so we have to create redundant content. The content is in SharePoint, the redundant content will be in SharePoint online, done. That works really well, but again, it works for us. There are ways to make it easy for our domain users to log into SharePoint in the cloud, but our customers aren’t in our domain. In order to get them to login, they would have to have some sort of Microsoft account.

As far as Microsoft is concerned, this isn’t an issue because everybody either has or can have a Microsoft account. Yeah, but that’s not really the case. Some people don’t have an account. Some of those people don’t want one. Some people have a Microsoft account, but it isn’t associated with their job.

I had to create a Microsoft account in order to work with an association I belong to. As an old boss used to say: “the process was 1, 2, 6;” in other words, a snap. I don’t use this account very often, but whenever I do, my first task is to delete about 100 pieces of junk mail. This is the last thing I want our customers to have to do in order to work with us.

In addition, for security reasons, some of our customers are prevented from using personal credentials to access content while at work and others are prevented from creating such an account that is linked to their domain email address. In our on premises implementation, we had a separate domain and we issued credentials when necessary. Moving to the cloud seemed like a step backward as far as user experience goes.

Finally, in addition to all of the above, if we did go with SharePoint Online as a solution, our content would be in SharePoint, duh. I you remember the original post in this series, the problem with that is that most of our customers, I’d say 95% of them; simply want to download files from our repository. They don’t want calendars, tasks, blogs, wikis, custom lists, metadata and workflows – just the files. When that’s all they want, you either have to spend time to make SharePoint look less capable than it is, or you are going to make your customers wade through a process that seems overly complex.

If you are a lover of suspense, stop reading. I’m going to spoil the ending of this saga. We have decided to use Citrix ShareFile for this application. I’ll explain why we selected it and how we use/plan to use that service in the final installment of this series. Until then, I can say that we are very excited about it, our employees are very excited about it and the customers we’ve spoken to are very excited about it.