Lou Franco's Software Business Blog : sharepoint

SharePoint Document Management Checklist: Get Things Done

loufranco — Sat, 09 Jan 2010 15:56:21 GMT

Windows IT Pro published a checklist for SharePoint Document Management. It covers some of the things you need to think about in addition to just adopting SharePoint (storage, interoperability, backup, security, etc)

Those things are important, but instead of concentrating on the infrastructure mechanics of document management, it’s better to talk about the purpose. If you are sitting in front of your computer looking at SharePoint and thinking about folders, Documentum integration, your SAN, and backup procedures, then something has gone completely wrong.

The reason to use any tool is to get stuff done – pay invoices, process claims, answer inquiries. The more you can get SharePoint and whatever you add to it to put your work in front of you and help you do it, the more you will get out of it.

Here’s my checklist of what to look for in Document Management that will help you get work done.

Are all the things you need to process a document organized and easy to get to while viewing it (Annotations, meta-data, document editing)?
Are related documents readily accessible?
Can you compare two documents easily? For example, the purchase order and the related invoice or two versions of your newsletter.
Is search integrated so that I don’t need to leave my management window to bring up another document?
Can I correct a badly scanned page with an ad-hoc page rescan right from my viewer?

Of course everything needs to be backed up, versioned correctly, integrated, etc. But if that’s all you get, then you won’t get the full benefit. In the end, the ROI will be driven by the business getting it’s work done, so don’t stop at just the infrastructure requirements.

SharePoint Empowers Users from @meetdux

loufranco — Wed, 25 Nov 2009 13:08:07 GMT

Dux Raymond Sy (@meetdux) is writing a series introducing SharePoint to executives. For it, he created this compelling video about how easy it is for a project manager to create their own collaborative intranet without IT.

SharePoint Empowers Users from Dux Raymond Sy on Vimeo.

Why it’s not surprising that SharePoint is being used for Records Management

loufranco — Mon, 23 Nov 2009 19:46:15 GMT

I just read an article in the midmarket CIO section of TechTarget reporting on Forrester’s finding that SharePoint is gaining market share in Records Management.

The finding is surprising because SharePoint 2007 has some "significant shortcomings" when it comes to records management (RM), said Hill and others. While miles ahead of its portal-centric 2003 version, SharePoint 2007 is a less-than-ideal tool for the exacting task of maintaining records -- from paper, digital documents and databases to physical objects -- throughout their lifecycle. Missing features include:

Physical records management -- for example, the ability to apply retention policies to warehouse boxes.

Federated records management, or the ability to apply controls to objects in other repositories.

Department of Defense certification for records management, (DoD 5015.2-STD V3), required by many federal and other agencies of business partners.

This is only surprising if you think of SharePoint as an out of the box solution. If you plan on using SharePoint with no customizations, then it isn’t an acceptable Records Management System. But, SharePoint is a platform, and all of these missing features are easily added by third-parties or by the IT department of the organization.

Microsoft even got their own records manager, Christina Torres, to write a whitepaper on how Microsoft uses SharePoint and Exchange to manage their records. The opening paragraph talks about how to “implement a records management system”, not install one. In reality, even an out-of-the-box RMS is going to require customization – so Microsoft’s offering is not so different and it offers two big advantages:

It’s quite a bit cheaper
The front-end is fully integrated with Office – making adoption much more likely

Or as Forrester put it:

As for SharePoint's current popularity among records managers, despite the gaps? Hill said a familiar interface is a powerful thing. "I attribute it to Microsoft's extremely bright strategy of tying together SharePoint with its office portfolio and giving knowledge workers a user interface they are very familiar with," Hill said.

Is Capture where SharePoint’s Next Billion Will Come From?

loufranco — Thu, 05 Nov 2009 14:28:41 GMT

Jeff Shuey thinks the next billion dollars for SharePoint and their partners is in Document Capture.

I submit that SharePoint can add another $1 Billion dollars to this by focusing on [the Document Capture section] of the ECM market alone. […] which includes scanning, faxing, and otherwise importing paper based documents.

Jeff has written about this opportunity before.

And, he’s not the only one. Ralph Gammon’s Document Imaging Report (the leading document capture industry newsletter) is also tracking SharePoint’s inroads into the capture market:

With the 2007 release, Microsoft first got serious about SharePoint's document management capabilities. With the 2010 version, there are even more document management capabilities.

Although SharePoint doesn't have any inherent document imaging, in many ways (but certainly not all) a scanned image can be managed like another electronic document. Because of this, we are seeing increasing interest in using SharePoint for document imaging.

Ralph is collecting document capture in SharePoint case studies – keep an eye on this section of the site if you’re interested in how SharePoint is disrupting the capture market and providing significant value.

More “8 Things” goodness: SharePoint + ECM

loufranco — Tue, 27 Oct 2009 14:55:04 GMT

The AIIM Digital Landfill blog’s 8 Things series is still going strong. The latest is Michael Elkins (from the Kestral Group) on 8 Things to Consider when Implementing SharePoint with Another ECM engine.

SharePoint sites are often created with little thought with respect to long term use. As a result, when it comes to linking into another ECM solution, users are hit with unexpected changes and restrictions to sites they have become accustomed to. Understanding the functionality people use, or expect to use, from each system is vital to the successful blending of the capabilities.

What it boils down to is that SharePoint is great for getting work done (collaboration, dealing with living documents, workflow, etc.) and the ECM is great for keeping records and complying with laws. The interesting parts are when documents transition from one to the other type.

Google’s Apps at Work

loufranco — Thu, 22 Oct 2009 18:57:34 GMT

Over at Jeff Shuey’s blog, I read about the announcement of Google’s Apps at Work. Jeff’s an absolute expert on what it means to be a Microsoft partner – he was a Partner Manager at Microsoft and in the ECM space, he’s been a Parter/Alliance manager for Kofax and Captaris. His take:

The challenge for Google will be to empower a vibrant group of partners that are willing to adopt, adapt, and accelerate.

I completely agree with him that partners are key to Microsoft’s product strategy (in any market), and that Google has yet to show that can replicate it.

Right now, without partners, they can only replace the parts of enterprise infrastructure that aren’t customized. The obvious one is e-mail, and that’s the main message on the AppsAtWork site: “switch from Microsoft Exchange”, not from SharePoint. They are definitely pushing the envelope of communication generally, but that won’t matter if I can’t tailor it to my specific (custom) needs.

Ironically, part of the problem Google is going to have is that you don’t need help installing their system. It’s already installed in their cloud – you just need to sign up and pay. The first company people turn to will be Google itself, not a partner. In the SharePoint world, you usually need help to get started and then partners can provide value-added services on top of that.

For role-models, Google needs to look at SalesForce and Apex. Not just working together, but copying Apex for Google Apps.

CMIS and SharePoint 2010 – What will it be?

loufranco — Tue, 28 Jul 2009 12:24:01 GMT

CMS Report is lamenting the lack of details of CMIS and SharePoint 2010:

While Microsoft announced their support for CMIS in September 2008 there has been little word from Microsoft on when we'll see CMIS available for SharePoint users and whether CMIS will be incorporated into SharePoint 2010.

And he’s right – Bryan gives an exhaustive list of mentions of CMIS, and they are all one-liners, rumors, or extremely vague.

SharePoint CMIS support should mean that they can interoperate with CMIS repositories (which they already can, with custom code) and that they provide a CMIS layer on top of their repository. The latter is also possible now, since anyone can deploy web-services into SharePoint and the SharePoint Object Model is already rich enough to implement CMIS. The issue with third-party solutions is that they are limited to the public interface, but Microsoft would have access to the underlying data model and would be able to do a better job, especially with queries.

For CMIS to be successful, it will need to be a first-class citizen, as I wrote when CMIS was first emerging:

[…] if [each ECM vendor’s] implementation of CMIS doesn't match their proprietary API, then we may find ourselves still writing code for each one. The main reason is that if we have competitors, and if there is a performance benefit, it will outweigh the benefits of a smaller code base. Our customers won't care if we support other systems, only what the best one for their system is. So, the more successful we are, the more likely we'll be writing ECM specific code.

Eventually CMIS will be the right way to interact with repositories, but like Bryan from CMS Report, I’d appreciate some guidance from the vendors on when the CMIS standard will be done and implemented in their products.

Is SharePoint Scary?

loufranco — Wed, 22 Jul 2009 16:47:00 GMT

Last month, I wrote about a Computerworld article on the cost of SharePoint that concluded:

If CIOs treat SharePoint as off-the-shelf software, the costs will indeed be onerous. However, if CIOs treat it as an enterprise information platform and content management system, SharePoint will yield tremendous value-and potentially at a fraction of the cost of comparable ECM solutions.

I thought about this again while reading this Peter Campbell article on why SharePoint scared him. It’s an overview of the benefits and drawbacks of SharePoint in a specific organization, and concludes:

After four years of agonizing on this, here's my conclusion: When the product matures, if I have organizational buy-in and interest; a large hardware budget; a high-performance Wide Area Network, and a budget for consulting, Sharepoint will be a great way to go.

Ultimately, for Peter, it comes down to cost, because four of his six points are either about cost of licenses, hardware, etc, or a problem in SharePoint that has many third-party solutions (external blob storage, for example). In the comments, Peter explains why hosted SharePoint wouldn’t work for him, which would be a typical suggestion to a small organization that didn’t have the infrastructure in place.

Like many solutions, the costs are very easy to quantify, but the benefits are not. For example, there’s a lot of value to the extensibility of SharePoint – not just in that it allows organizations to standardize on a web-application deployment framework, but that it also enables third-parties to provide common extensions. Peter also mentioned how well it fit in with the rest of his systems (Exchange, Office, Windows Directory), and that would also translate to cost savings. However, the value of those benefits isn’t as clear as the cost of a server.

The challenge to Microsoft and its partners is to help organizations quantify these benefits in a believable way.

SharePoint Cost Overview

loufranco — Tue, 30 Jun 2009 17:20:55 GMT

Here’s a good article in Computerworld for determining the true cost of SharePoint. Key message, it’s just like any other enterprise software, don’t treat it like off-the-shelf software:

If CIOs treat SharePoint as off-the-shelf software, the costs will indeed be onerous. However, if CIOs treat it as an enterprise information platform and content management system, SharePoint will yield tremendous value-and potentially at a fraction of the cost of comparable ECM solutions.

Absolutely right. SharePoint can be managed and added on to by end-users, but there should be some sort of central control to set standards and provide common customizations.

For example:

If you care about branding SharePoint, then that is something that should be done by IT or consultants for the entire installation.
SharePoint comes with some built in workflows, but new ones need to be created in code or SharePoint designer – best to have IT provide the ones you need.
Obviously, if you have any kind of complex storage requirements, IT is going to have to deal with that.
IT should find and install 3rd party components that meet common needs. For example, if you have a bunch of departments that each need to incorporate paper-based processes via scanning, viewing, and collaborative editing then you want to standardize on a document imaging SharePoint solution.
The Computerworld article makes a good point about governance. Depending on your requirements, you may need more than just a written policy, and it might be important to build or buy a solution to enforce your rules.

Given a good foundation, users will be able to create a lot of functionality on their own, and they will be able to think about it like they think of other Office apps (like Excel), but there are some things that IT will have to set up to make this possible.

Jeff Shuey on Capture in SharePoint

loufranco — Wed, 24 Jun 2009 20:25:32 GMT

Jeff Shuey thinks Document Capture in SharePoint is up for grabs:

Companies that had a chance to own this space have faltered. The leading vendor of document capture for 20+ years is Kofax. They have fallen flat and cannot seem to get out of their own way to make anything significant happen. I’m sure there are wins in various places across the globe where Kofax products are being used to address the document capture needs of companies. My point is that Kofax as a company has not made the right moves to go after what I can see is easily a $3-5 million dollar opportunity in the first year and has the potential to be a $1B dollar business.

Jeff used to work at Kofax, and he knows them a lot better than I do – so I’ll let his analysis stand.

Jeff then goes on to mention a few companies that are entering this space, including (ahem), Atalasoft (with Vizit).

Atalasoft is the leading provider of .NET imaging SDKs, which includes our DotTwain product for capture. We’re also a member of the TWAIN working group, creators of InspectorTWAIN (TWAIN driver grading service), and with Vizit SP, we’re bringing our imaging expertise to bear in SharePoint. Another company on Jeff’s list, BlueThread, announced a partership with us at AIIM in March:

Atalasoft’s Vizit SP, a zero-footprint no-download document image viewer with cleanup, editing, and annotation features, is now fully integrated within BlueThread’s SmartDesk, a highly-configurable end-user ECM application framework. With Vizit SP and the advanced ECM/BPM capabilities of SmartDesk, users can readily view process-enabled content stored within Office SharePoint Server 2007 no matter the document type (Office, PDF, TIFF, CAD, etc.) within a completely web-based SmartDesk interface.

At the end of his blog, Jeff asks if there really is a Capture gap in SharePoint – clearly, we think so – and remember, capture is more than just scanning – it’s everything that goes into getting the document and metadata into your system. That includes barcode reading, OCR, indexing (including human assisted), capture QA workflows, and document clean-up. Each of these represents an opportunity for partners to work with Microsoft to make SharePoint an ideal capture system.

CMIS in SharePoint 2010

loufranco — Mon, 18 May 2009 12:31:46 GMT

Lars Fastrup has a round-up of the new features of SharePoint 2010. Among them is that CMIS will be supported. I’ve already blogged that Microsoft released a sample project for consuming CMIS in a document library, which has been possible for a while, so I assume that CMIS support must mean that we’ll be able to interact with SharePoint documents via CMIS.

There has been some wondering whether Microsoft could support CMIS without rearchitecting. We’ll see how it looks when it is released, but there is nothing in CMIS that Microsoft couldn’t implement with the current object model, and they have access to the underlying data model, so I have never understood what the issue is. Also, since they are one of the companies driving CMIS, it isn’t likely that they would approve of an interface that they didn’t think that they could implement effectively.

It will be interesting to see if CMIS support will be extended to the Office desktop applications. Right now, Word, Excel, etc, communicate to SharePoint via a proprietary interface, when CMIS would work just as well. If they supported CMIS then they would be able to connect to Alfresco (which already supports CMIS) and other ECM systems that will probably have CMIS by 2010 as well. Of course, there is nothing stopping those systems from implementing Microsoft’s current interface (as Alfresco and Atalasoft have done), but this would be an indication that CMIS is not just for external systems, but Microsoft is willing to build on it as well.

Document Storage: Database Blobs or the Filesystem

loufranco — Tue, 28 Apr 2009 18:27:14 GMT

About a year ago, I wrote about some of the technical issues around image storage in a database – mostly I concentrated on some of the implementation issues.

Over at, Never Talk When You Can Nod, Andrew Chapman has been laying out the case for taking blobs out of the database and storing them on the filesystem – specifically with regards to SharePoint and documents.

Of course, since Andrew works for EMC, you would expect that he would recommend filesystem based storage, because they offer products based around this kind of storage – in fact a big reason for EMC to acquire Documentum was to acquire a customer base that needed to efficiently store blob-like data. SharePoint’s default behavior of storing the blobs in the database makes a lot of their products less effective.

Given that bias, he still makes a compelling case that at deploy-time, the benefits are too great to ignore:

Imagine a world where content created in SharePoint was automatically routed to the most appropriate location depending on factors such as values in the object's attributes, where the object is in its lifecycle and/or who created it. Imagine that this was done without in any way affecting the SharePoint end user experience or any applications built on top of SharePoint. Imagine if doing this didn't just reduce risk and costs but it also made your SharePoint deployments more scalable and robust.

And then lays out the case, and in a further post, he lays out the options with SharePoint, specifically describing the difference between Remote Blob Storage and External Blob Storage – again, he would want to push EBS, because that’s an API that EMC can write to and get you on their storage solutions, and RBS is implemented internally by SharePoint/SQL Server (using SQL Server’s new Filesystem field type) – however, he does make a compelling argument (e.g. selectivity and transparency). Make sure to read Andrew’s full list of pros and cons of EBS and RBS.

EBS is something we get asked a lot about with regards to Vizit – specifically, does Vizit work with document libraries that are using EBS for the document storage. As Andrew describes, EBS is implemented below the SharePoint Object Model, so that it’s transparent to any add-ons written on top of it – so yes, Vizit, and any SharePoint features written on top of the SharePoint Object Model are completely compatible with EBS (and RBS which is implemented at an even lower layer inside of SQL Server).

Jeff Shuey on the Microsoft Partnership Ratio

loufranco — Thu, 23 Apr 2009 15:30:19 GMT

Jeff Shuey has put 16 years in the ECM space working for Microsoft and Microsoft partners, so when he talks about the partnering with Microsoft, it’s worth paying attention to. Two recent posts caught my attention:

First, Jeff talks about how partners fit in to the SharePoint ecosystem.

[…] SharePoint is really only complete when partners are involved.

Partners have created hundreds if not thousands of solutions. Some of which are listed here and here, but there is so much more to be done. If executed correctly the potential exists for SharePoint to become the framework that underpins many of the solutions of tomorrow.

As I alluded to above - SharePoint by itself is not the be all - end all solution. However, when combined with the experience, expertise, and energy of the partner community SharePoint really shines.

Of course, as a Microsoft partner with an ECM viewer SharePoint add-on, I’m all ears. The whole post is worth reading to get a sense of what end-users, partners and Microsoft get out of the relationship. Generally, since Microsoft is a platform company, they rely on strong partners to adopt and extend their platform. Jeff’s other post on this topic explains why partners should build on Microsoft platforms:

The 1:3:5 Ratio – Why is it important? This is a ratio I have vetted over the last 10+ years in working with and for both Microsoft and partners to verify and validate the value proposition for both Microsoft and the partner ecosystem. It is a conservative estimate of what partners and Microsoft can expect to generate in revenue from each engagement. When done right this ratio can be increased and more importantly can be made to be extremely predictable and repeatable. This is the golden ticket for Microsoft and Partners.

What does the 1:3:5 ratio mean to Microsoft? to Partners?

The 1:3:5 ratio is a set of numbers that correlates to $1 for an ISV and $3 to Microsoft and $5 to the SI. It relates to what the ISV can expect to make; it tells Microsoft what they can expect to make; and it tells an SI what they can expect to make for each engagement / sale they make with Microsoft products. Again, when done right it makes for a very predictable and repeatable business model. Smart partners know this is the key to their success in the Microsoft partner ecosystem. Microsoft knows that building this ecosystem is in their best interest too.

Since SharePoint sales are at about $1B, that gives a crude estimate of the SharePoint ISV market at $333M.

SharePoint Designer 2007 is Free

loufranco — Thu, 16 Apr 2009 20:43:26 GMT

Andy Dale has a great article about getting started with SharePoint Designer now that it’s free. Of course, the best tips are that SharePoint Designer is very dangerous – you need to be careful.

I have had access to Designer, but now that’s it’s free, somehow I feel like taking a look at it – I have some processes that I have wanted to automate (with the workflow designer). I’ll update when I have something to say about it.

Microsoft’s First CMIS Moves

loufranco — Mon, 16 Mar 2009 15:28:00 GMT

Via the CMSWatch, I took a look at this MSDN article on Microsoft’s first attempt at showing how SharePoint and CMIS might work.

The article links to this SharePoint solution that implements CMIS external document libraries. The focus is on bringing content into SharePoint via CMIS, not in exposing SharePoint content. In this preview, they implement custom fields on the documents, workflow and search support, and single sign-on.

One thing to note is that this is what is possible today using the SharePoint object model, not necessarily how it will actually be implemented. For example, to participate in workflow, the external library implementation uses a hidden document library. I wouldn’t expect that in the official version.

Still, it’s interesting to see that CMIS can be leveraged today in SharePoint if the need arises. In this example, they integrated SharePoint to a custom external repository and wrote the CMIS layer themselves on top of it. This makes it possible for all SharePoint users to try this out even if they don’t have access to FileNet, Documentum, etc.