I’ve just signed up for a webinar that KnowledgeLake are holding entitled “Realizing True Records Management with Microsoft SharePoint 2010“.
KnowledgeLake were gold sponsors at the SharePoint Best Practices conference that I went to in London earlier this year, and, I have to say, it was a top-notch event. I had visited KnowledgeLake’s booth and I’m curious about how good their product actually is.
So, it was with interest that I read the “Reasons I should attend“. These included the following:
Now, the first reason seems to be pretty standard when describing the virtues of any content management system. As is a demonstration, as well as hearing a customer case study..(Just change the name of the ECM system.)
What really grabbed me by the short and curlies was the second reason “Discover why SharePoint will succeed in records management where other ECM platforms have failed“. Now, this is interesting…I want to hear about this secret sauce that McSharePoint has.
Reason 4 is also one that got my attention. Here the phrase “enterprise approach” really stood out. I’ve been involved with SharePoint since 2007, and, coming from an ECM background, it was very evident to me that SharePoint 2010 is now being hawked as a bigger beast. And this is not only in the “functionality” of SharePoint 2010, but also in other ways. There are more “enterprise-level” whitepapers out now, and the official Microsoft SharePoint training is focusing more on the “business-side” rather than just pure technology.
I’ve registered for the webinar. I’ll be taking notes, and will try and report back on my findings.
Reference Links
I’ve been very aware of something for awhile now…and that is “I don’t know where I fit in”. However, it wasn’t until recently when I read Nick Inglis’ blog post that I really came to realise that my “problem” is actually not an uncommon one.
In his post Nick comments that when he’s speaking at a SharePoint event, he often gets categorized under “Other“.
This is because (as he states) the SharePoint world doesn’t quite have a place for those who do work with SharePoint but in an ECM/ERM/Governance capacity.
The Salem Consulting Group have made a list of “plausible” SharePoint roles. I have listed them below, and have added a quick description in between parentheses. These include:
(Note – The original post (authored by Ian McNeice) from Salem offers a more detailed description of these roles. The link is at the end of this post.
In Nick’s post, he describes an “Information Professional“.
These are the people that have been busy developing models of governance … and have been driving forward the conversation about how SharePoint can be used as a “proper” ECM (and yes, maybe even ERM) system.
Looking at Ian’s list, I think the closest role that matches this is the “Information Architect”. This is the person who insists on maintaining a correct classifications, taxonomies, etc while has expertise in document management, version control techniques, data retention polices, publication and archiving practices.
Being prompted by Nick’s post, and then looking through Ian’s post has certainly help me better “label” myself.
Prior to this, even though I have worked in the Document Management field for over 10 years, I could never find a way of describing my skill set to a “SharePointy” (is that what you call a SharePoint fan?). I can set up, and administer SharePoint sites. I can design user interfaces. I can set up farms, as well as write kick-ass documentation. But I could do more than that.
Thanks to Nick and Ian, I’m going to go and update my LinkedIn profile.
Excellent References
Recently I’ve been involved with a client project that included moving some SharePoint sites from one web application to another as well, as moving document libraries from a top site to a sub-site.
While I work at the Business level (business systems analyst role), the move itself was done by client’s IT Infrastructure people. Fortunately they were smart enough to copy the content, instead of moving it. This was a brilliant idea, as it gave us the ability to have the original content still available.
Once the content had been moved the next step was to check that no documents had been missed. Now, the site owner (at the business level) had the best idea of what content would be stored in the doclibs, but as there were 64 of them, (some with 100 documents, many with documents in the thousands), doing a direct comparison was not easy. There was also the fact that the new locations had been “unfrozen” and people were uploading documents.
We investigated various ways to do a comparison. This involved creating special views for the docbases that would include only documents created before the “unfreeze” date, and then doing a screen by screen comparison. This was quickly deemed as not practical, and not handy, and bloody tiring.
Then we tried exporting out the lists from the original location to spreadsheet, and then doingthe same with the new location so that each list was in columns next to each other. And then doing a side-by-side comparison. This was definitely more practical, and we thought that it was a plausible solution. Until we discovered that for one of the doclibs there were 900 documents in the old location that were not in the new location.
Fortunately we came across a tool from MetaVis. The application suite of this product included a “Live Compare” feature. With this we were able to easily select one particular site in the left part of the screen, another site in the right screen, and then select the docbases that we wanted to compare. And then after clicking on the “Go and check the differences” button (it was actually titled “Compare Now”), we could see which documents were in the old location, and were not in the new location, and vice versa. This was great! And compared to manually comparing lists, was sooo much easier.
As well as any differences in content in the doclibs, we were also able to see small differences in other configurations. This was very handy.
Now – I know that the main functionality of the MetaVis tool is to do with migration, and architecting, but this “Live Compare” functionality certainly saved us a lot of time and frustration.
Yesterday, the third #ECMJam was held. A lot of people were involved and it was a very interesting discussion about
the place of SharePoint in the world of ECM.
Bryant Duhon was the Jam facilitator. Check out his “Introductory” post here (http://www.aiim.org/community/blogs/expert/ECMjam-SharePoint-and-ECM).
There were a number of Questions that formed the basis of the discussion. These were:
| “ | Q1: Is there problem with #sharepoint expectations, marketing, or the product itself? | |||
|
| “ | Q2: #SharePoint / #governance — how to do it for real (in 140 characters or less!) | |||
|
| “ | Q3: Is there/has there been a backlash vs. #SharePoint? http://ow.ly/60GnJ |
|||
|
| “ | Q4: What does #SharePoint do well ootb? What doesn’t it do? |
|||
|
| “ | Q5 Can #SharePoint solve #collab and DM problems for larger companies, as well as smaller? Can/does it really scale? |
|||
|
Each question raised some interesting responses.
With regards Question 1, there was a feeling that SharePoint was not quite an ECM application:
| “ | #ECMjam A>Q1 Sharepoint is no #ECM system when you take the #AIIM definition as reference | |||
|
| “ | #ECMjam A>Q1 Sharepoint claims to be #ECM, but a lot of ECM vendors make money enriching SPS2010 with ECM functionality | |||
|
| “ | Q1: There’s a problem with expectations! #SharePoint isn’t the be-all/end-all too many folks seem to believe. |
|||
|
Others pointed out that the problem isn’t with what the product, itself, can do, but with the “misunderstanding” of what SharePoint actually is.
| “ | Q1: IMO, SharePoint “problem” is not with product as much as with misunderstanding of what, why, where, how it can/should be used. |
|||
|
| “ | Q1 Agree that SP does a lot and what it does, it does well. TCM is the big gap. #ECMjam | |||
|
| “ | Q1: #sharepoint is a platform, but was sold as a product. Leaves users spending $$$ to get what they were promised #ecmjam | |||
|
| “ | Q1 you can not achieve ECM with 1 product or a platform, SP still does not provide scanning OOTB #ecmjam + you need PM consulting & techserv | |||
|
| “ | Q1 Saw recent data from a SP conf that for every $1 of SP license it sells, partners sell $6 of services. Underscore OOTB issue. #ECMjam | |||
|
| “ | Q1: So expectations are over-hyped and fueled by microsoft to make #SharePoint out as more than it is. #ECM #ecmjam | |||
|
| “ | Q1. As follow up to my previous comment, from my standpoint, people just seem to buy software as a panacea. Why not more plan 1st #ecmjam | |||
|
| “ | Q1. My theory, it’s from Microsoft, so folks believe it’s just going to be out of the box #ECM. #ecmjam | |||
|
| “ | And not just by Microsoft RT @bduhon: Q1: So expectations are over-hyped and fueled by microsoft #ECM #ecmjam | |||
|
| “ | Too hard, too long, too obvious! RT @bduhon: Q1. people just seem to buy software as a panacea. Why not more plan 1st #ecmjam | |||
|
Question 2 (SharePoint and Governance) was met with a unaimous response – PLANNING & CONTROL
| “ | #ECMjam A>Q2 #Sharepoint governance needs good planning and administration esp. in distributed environments | |||
|
| “ | 4 characters: P-L-A-N. 5 characters: T-H-I-N-K RT @bduhon: Q2: #SharePoint/#governance: how to do it (in 140 characters) #ECM #ecmjam | |||
|
| “ | #ECMjam Q2-You can define segments of SP with different technical restrictions to assist in governance (e.g. size quotas for team sites) | |||
|
| “ | Q2: #sharepoint governance must be both centralized and distributed. Policies set by org, solution design by business units. #ecmjam | |||
|
| “ | #ECMjam A>Q2 Viral, uncontrolled installation and usage of #Sharepoint is the death of every information management governance! | |||
|
| “ | Q2: Governace requires planning up front and RIM on the back. Can’t be done with a full featured ECM #ECMJAM | |||
|
| “ | Q2 @piewords “Viral w governance can work.” Sort of like a organizational social media policy? #ECMjam | |||
|
| “ | More involved but yes RT @inoldland: Q2 @piewords “Viral w governance can work.” Sort of like a organizational social media policy? #ECMjam | |||
|
| “ | Q2 so how do you explain governance to an end user and get them involved? Easy to say, hard to do #ecmjam | |||
|
| “ | There, and in CIO office (and in Redmond?) RT @bduhon: Q2. So #governance is where a hammer is needed? #ECM #SharePoint #ecmjam | |||
|
| “ | Q2. So, @danieloleary @jessewilkins: #governance is where a hammer is needed? #ECM #SharePoint #ecmjam | |||
|
| “ | So what kills #SharePoint? RT @incontextmag: Q2: SP doesnt kill governance. People kill governance. #ecmjam | |||
|
| “ | Q2: SP doesn’t kill governance. People kill governance. #ECMJAM | |||
|
| “ | (Answer) So what kills #SharePoint? Governance! (sometimes) RT @incontextmag: Q2: SP doesnt kill governance. People kill governance. #ecmjam | |||
|
| “ | Only against over-inflated expectations. RT @bduhon: Q3. Is there/will there be a backlash against #SharePoint? #ECM #AIIM #ecmjam | |||
|
| “ | #ECMjam A>Q3 #Sharepoint is already outdated compared to mobile and apps | |||
|
| “ | After 10 yrs? Seems to me we should have seen one already. <Q3. Is there/will there be a backlash against #SharePoint?> #ECM #AIIM #ecmjam | |||
|
| “ | #ECMjam A>Q3 #Sharepoint is too complex in relation to consumerisation of #collaboration & #ECM | |||
|
| “ | Q3: There surely is a @sharepoint backlash, but it’s misguided, because it’s based on the misunderstandings we discussed re: Q1. #ecmjam | |||
|
| “ | Q3 Backlash will come only if SP doesn’t deliver value. Same reason there’s backlash against anything. (Apologies to Susan Faludi.). #ECMjam | |||
|
| “ | Q3: SharePoint has a place, but it’s not a mass market tool. It won’t ever be the Facebook of ECM #ecmjam | |||
|
| “ | Q3: The problem is that they market it as ECM but ECM is a category and no one product is all ECM. #ECMJAM | |||
|
But someone pointed out:
| “ | Only in our circles; elsewhere they promote other stuff (eg, collab) RT @incontextmag: Q3 The problem is that they market it as #ECM #ecmjam | |||
|
Question 4 discussed what SharePoint did well, and what it did not do well.
While this question didn’t generate the same discussion as others, there were some interesting comments.
The “does well” comments included:
| “ | Q4 SP does sharing, collaboration and portals very well OOTB. It does not handle high-volume, transactional stuff well. #ECMjam | |||
|
| “ | Easy way to share Office docs. Replacement for file shares. RT @bduhon: Q4: What does #SharePoint do well ootb? #ECM #AIIM #SP2010 #ecmjam | |||
|
| “ | Q4 – Collab & portals are good. Governance, transactional content, capture weak. #ecmjam #ecmjam | |||
|
| “ | #ecmjam Q4: Good: Basic document management. Huge improvement over shared drives. Bad: Dependent metadata and field validation. | |||
|
| “ | Q4 SEARCH! In 2010 they nailed it, wish every platform was as functional #ecmjam | |||
|
Whereas, the “does not do well” included:
| “ | Q4 SP doesn’t do BPM well. Managing docs from outside an org’s four walls that need to be processed. #ECMjam | |||
|
| “ | Q4: Doesn’t physical records management, BPM, transactional content management, scanning & capture, archiving & library services #ECMJAM | |||
|
| “ | Q4 – Weakness: Seen many orgs empower depts to make their own teamsites, but result is too many silos and no enterprise governance #ecmjam | |||
|
| “ | Q4: SP default is to store as blobs, inflating the DB, but if you do much you need a SP work around. #ECMJAM | |||
|
Question 5 asked “Can SharePoint solve collaboration and DM problems for larger companies as well as for smaller?“
Generally it seemed that while SharePoint was useful for a small company, the administration, and maintenance requirements were too high to make it practical.
| “ | #ecmjam Q5 SharePoint has always been able to scale the difference is it puts it in the users hands front end, versus other ECM backend | |||
|
| “ | #ecmjam Q5 so scaling requires more planning, but absolutely can scale for large companies | |||
|
| “ | Q5 the time to live and staffing requirements are too much for small business, #sharepoint is a better fit for larger orgs #ecmjam | |||
|
| “ | #ECMjam A>Q5 #Sharepoint can solve DM problems in smaller orgs but is some overkill in regard to admin | |||
|
| “ | Q5 no 4 SMB’s. lack time and IT resources. rely on specific OOTB and references to their biz/problems that dont exist #ecmjam | |||
|
| “ | Q5: Technically (performance, scaling) Yes, but for the features and manageability No. #ecmjam | |||
|
| “ | Short ans: yes. Better ans: yes, but, with “but” = may require 3rd pty apps RT @bduhon: Q5 Can #SharePoint really scale? #ECM #AIIM #ecmjam | |||
|
| “ | Q5 the best way to scale sharepoint is to run in the cloud #ecmjam | |||
|
| “ | What kind of cloud? Cloud cloud or VM? RT@shadrachwhite: Q5 the best way to scale sharepoint is to run in the cloud #ECMJAM | |||
|
| “ | #ECMjam A>Q5 #Sharepoint as Office365 SaaS might be the solution for SMEs | |||
|
| “ | @bduhon q5 Not yet. There is promise for the future for SP for SMBs with Azure and the future cloud platformed SP in dev. #ecmjam #AIIM | |||
|
| “ | Q5 Wondering if performance is an issue as SP scales (when it does). #ECMjam | |||
|
| “ | #ECMjam Q5: We’re 26,000 people. SP scales, but it needs careful focus and planning. | |||
|
| “ | Q5: hmmm. Scale in what way? functionality … no. of users … geography … ? #ecmjam | |||
|
For a read of the actual tweet stream, click here (http://www.hashtracking.com/fast-report/?hashtag=ecmjam)
Previous post: SPX Series – SharePoint eXperience – (aka SPX) – Series Introduction
First off – I want to explain that I am, in no shape or form, an SPX “expert”. I’m just a guy who has been using SPX since it was first released. I’m not a coder, so can’t tell you all the cool ways that the web parts can be tweaked, or made to dance. I am able to share with you the some of the “lessons learned”, and tips . that I have picked up over time. Some of what I write might be incorrect. Please feel free to let me know if that is the case.
And, where possible, if there are other resources that explain something better than I can, I’ll point you to it.
So without further delay I will launch into today’s SPX post…”A little bit of history“.
In 2007 Microsoft introduced SharePoint 2007.
As well as providing the ability to store content in its own repositories (doclibs, lists), it also provided web sites that could be populated with web parts that allowed users to interact with internal content (lists and SharePoint repositories), as well as external content. This included other LOB enterprise systems (such as SAP, Siebel, etc). There was no native way to connect SharePoint and Documentum though.
A company called Wingspan had also developed technology that provided Web Services connectivity to Documentum. This consists of the Docway Server, and Docway “Portlets”, (and for SharePoint – Webparts), and allowed for single sign-on, cross-docbase browsing, as well as the ability for users to access, create & update content from a Portal.
CSC’s FirstDoc, provides a layer that sits on top of Documentum, and allows for compliance with many of the Pharmaceutical regulatory requirements imposed by the various regulatory authorities (FDA, EMA, MHRA, etc.)
Using Wingspans technology, CSC (or, at the time, FCG), were able to create special webparts that allowed users to interact with their FirstDoc system from a SharePoint Portal. These offered about 85% percent of the functionality provided by the native FirstDoc application.
The first version was released in the 2nd half of 2007, and had the moniker “version 4.3“. This was to keep the version inline with the (then current) version of FirstDoc. It was compatiable with version 5.3 of Documentum.
There were 17 webparts available. These included webparts for browsing cabinets, listing the logged-on users checked-out documents, displaying the Home Cabinet, an inbox webpart, an very handy object-view webpart that could be configured to display one particular folder, or cabinet), an also handy query-view webpart that allowed content to be displayed based on a query, as well as an assortment of other functional webparts, and administration webparts.
Each web part offered a user the ability to further interact with an object via a context menu that showed extra functionality depending on the type of object that was clicked upon.
Courtesy of CSC
This first version was an excellent step towards greater flexibility in creating interfaces for users that better matched their daily work style. For the 80% of users who rarely log into FirstDoc, it provided a quick and easy way to get to specific documents. Links to specific documents could be sent via e-mail, and when a user clicked on it, the document would automatically be opened, without having to go through a process of logging into a client and searching for a document.
But there were also several shortcomings. There was the 20% of hard-core users that quickly discovered that 
there was still a lot of functionality that was not available. Also the SPX interface did not offer the same flexibility that WebTop did. You couldn’t easily change the columns that you wanted displayed, the search functionality when compared to the WebTop search was very limited, and the way of interacting with the documents was different. The context menu was not found in WebTop. Performance was also a bit sluggish especially when using the webparts over a WAN.
To be fair, CSC were also restrained by the limitations of the underlying Docway technology.
(However, Wingspan have been making continual improvements to their technology and CSC have been able to take advantage of this).
CSC listened to the concerns that the hard core users (as well as the administrators) were having. Version 5.0 of SPX was released in the middle of 2008, with Product Alias Search functionality, the ability to limit search results, and also the ability to add multiple documents to a workflow. Version 5.0 was also compatible with Documentum 6.0
Then later that year, version 6.0 was released. This was based on Documentum 6.5, and an upgraded version of Docway(6.1). It had been designed to be backwards compatible (with configuration, it could work with version 4.3 of FirstDoc). This allowed SPX to work over multiple docbases of different versions. As well as this, the Inbox and Query webparts were tweaked so that values could be automatically passed on the URL. Menu selection was made configurable. A quicklink capability was added that allows a link to be configured that will launch FirstDoc functionality, and the ability to View Relationships, and Audit Trail reports was added.
Then, in the later part of 2009, version 6.1 was released with even more functionality – Virtual Documents could now be viewed, multiple files could be imported, a new :”My Views” webpart was available, as well as the ability to view the Workflow Status report. Importing related documents was now, also possible. A version 6.1.1. was also released but this was a correction to a limitation that was previously believed to be uncorrectable.
Courtesy of CSC
In 2010, version 6.2 and 6.2.1 were released. The only difference was that 6.2.1 was certified for use with SharePoint 2010. Both versions also used Docway 7.0. And there was a bundle of new features and functionality. These included: the ability to register interest, the availability of the WebTop Search app as a webpart, a single-box search (“Google-like”), Saved Searches, the ability to display custom properties in the web parts, clipboard tools, subscription notifications, as well as other functionality.
CSC are working on the next release of SPX, and it looks like they’ll be adding even more functionality to close the gap between SPX and WebTop.
FirstDoc doesn’t have its own client application – it extends the functionality of the EMC Documentum native client – “WebTop”. EMC has announced that they will be phasing out this out sometime soon. As a result CSC are dedicated to ensuring that SPX is ready to be a replacement.
So – that’s the end of my “A little bit of history” post. If have made mistakes anywhere, please feel free to let me know.
Image via Wikipedia
This post continues from the previous one where I debated some of the draw-backs of using a network file share.
In that last post I mentioned there are some situations where using a file share can still be useful.
Company A has been storing content on a file share for many, many years. People have the been granted access to specific folders, and they also have the freedom of creating sub-folders (which they do).
Over time, the file share becomes unmanageable. As Adrian pointed out in his post, this has several disadvantages: nothing can be easily found; a lot of the information ins inaccessible; collaboration is not as effective as it could be, etc.
Recently Company A became aware of SharePoint. “Cool!” they thought, let’s move everything into a document library. Then we won’t have problems any more.
I certainly agree that a product like SharePoint can be useful. Once the content is in SharePoint, it can be further categorized using metadata, made accessible through the use of views, etc, and can be easily searched. Company A also thought this way.
Company A considered a couple of options here:
Both option 1 and 2 are good options. Having all the content in SharePoint means that it’s all there in one place. Security can be applied, as well as versioning.
Option 2 increases the findability of the content even more by adding rich, meaningful metadata. Company A can create a taxonomy that allows the content to be suitably categorised. Combined with customizable views, users can display the content of the document libraries in multiple different ways.
The file share has worked well for a long time. The main concerns were:
a. manageability – it was hard to manage security to the fileshares, as well as keeping track of when files were modified. It was also extremely difficult to navigate the folder structure; and
b. findability – It was almost impossible to locate any files (unless you knew where they were in the first place.
Keeping this in mind, here are a couple of alternatives Company A could consider:
The advantages of the first scenario is that you avoid that very, very large database. By setting up the fileshare as a content source, you can configure SharePoint to crawl it. And, as a result users can perform searches to find what they want. Scheduling incremental crawls allows SharePoint to pick up any changes that are made to the content of the files.
The disadvantage of this becomes obvious when the security changes on the file. A full crawl is necessary to pick up any security changes. This means that if there are regular security changes (new users being granted access to the share, access to documents being changed, etc) a full crawl is required. This can take a very long time (especially with a slow/busy network).
In this second scenario, a little bit of work is required to identify all the documents that are not “active” documents (i.e. the documents that users are not currently modifying). This would include films, images, executables, and any files taht are not “dynamic”.
Then the company could move any documents that are “dynamic” (still being edited, etc) into SharePoint. Then, as described above, extra metadata can be added to improve findability.
The fileshare can then be treated as an “archive”, and the security changed to be Read Only. This will ensure that no documents get modified. And therefore the content only has to be crawl once.
Alternatively, lock down the file share so that no one can modify the permissions on folders or documents. Because there is no security change, no full crawl is required. Regular incremental crawls can be scheduled to pick up an changes to the content of the document.
The other day I was watching a demo of AvePoint’s File Share Connector. This connector allowed users working in SharePoint to interact seamlessly with the documents that were actually in the file share.
The obvious advantage of this is that SharePoint functionality is available, without jamming all the files in the database.
I was pretty impressed with what I saw. However – I haven’t used the connector myself, in a real-live situation, so I cannot make any comments on it. If you have used it, please feel free to let me know.
Adrian McGrath recently wrote a post called “The Problems with Shared Network Folders“.
It’s a great post, and Adrian is someone that I have a lot of respect for. He’s a smart guy, and I learn a lot from him. In the post (read it here ), Adrian discusses the disadvantages and limitations of using Shared Network folders.
These include:
In essence Adrian is correct. Using Shared Network drives does have limitations, but in the spirit of debate, I’d like to make a few comments on what he says.
Duplication of documents and confusion as to what the latest version is.
Complex file and folder naming conventions
Lack of consistent folder structures
Redundant documents
These are all indeed real problems. Are they inherent to Shared Folders? Not really – these can also happen with Document Management Systems.
Governance plays a large part in ensuring that these sort of things do not happen. Information Architecture is critical in ensuring that a suitable structure exists, defined by folder, and metadata, so that every document has a correct location.
However, this does require enforcement. Without enforcing such a system, even EMC systems can end up overly complex and with duplicated (and therefore redundant) documents. A lot of these systems, however have de-duplication functionality built-in (Documentum), and, if not (SharePoint), there is often a third-party tool that will do this.
Ineffective Search
Can’t argue with this. Unless some sort of indexing application is implemented, searching will be very inefficient.
There are many applications that allow Shared Network folders to be indexed. These include applications such as Google Desktop, Windows Search, X1, etc. SharePoint, also, has the ability to index information in file shares, as well as making the search results a little bit more meaningful.
Inaccessibility of information
Adrian is definitely right here. Most (if not all) companies are quite strict with their network security. Users are not able to make ad-hoc changes.
However this can also occur in an ECM system depending on how much “freedom” a user has. I have seen some situations where, because the security policies in the ECM system were so strict, that users have resorted to exporting a document to a file share, so that it can be shared with others, or worse, e-mailed to an external party.
A good governance model helps to reduce this, as does training. If the users are aware of why something is enforced then there is, often, a better chance of compliance.
Lack of subscription and notification
Limited ability to synchronise documents offline
Inability to cross reference and relate documents
No arguments here
Lack of document governance and control
Compliance, Risk & Legal Admissibility
Impeded collaboration
I’ve mentioned governance in my comments above. A good plan is required to ensure that documents are not haphazardly placed in seemingly random locations. And, as Adrian mentioned, Most ECM systems provide an audit trail keeping a record of the “actions” upon a document (when a document changes status, etc).
However, this is only effective for versions of the documents that are within the document management system. Once it is outside of the system (a user exports, or e-mails, a document) there is no audit trail. (Often this is done to collaborate with someone who does not have access to the ECM system.) This can create compliance issue. Again – good training, and governance, helps to reduce this risk.
Storage and maintenance costs
As Adrian mentioned, the amount of storage space required in a file share can be quite high, as users store more, and more content. And he is correct that because of the scattered nature of such content, this leads to inefficiencies.
ECM systems tend to handle the storage of content in one of two ways:
If the ECM system is configured to keep create a version every time a document is checked out, and then checked back in again, the number of “duplicate” versions can increase quite quickly, thereby requiring extra space. Of course, setting a lower limit for the number of version kept can help reduce this. Configuring the system to purge all minor versions of a document (e.g. 0.1, 3.2, etc) when a major version (e.g. 1.0, 3.0) is created also ensures that disk space is kept to a minimum.
Keeping documents in the database as a BLOB also presents extra maintenance. As with a file system, the databases can grow exponentially. Often extra work is required to ensure that the database still performs efficiently.
I am convinced that to be able to keep content in a system that allows adding meaningful metadata, auditing, security, document life cycles, and workflows, is critical if a business needs to track, control or route content. Often these activities will exist to match the requirements of a business process, and to make it more efficient.
However there are a few situations where using a file share is still of value.
In my next a later post I will go into this more…
A Tweet by @pelujan the other day started me thinking. The tweet was:
Speaking of waxing nostalgic – who remembers #FileNet distributor and rendezvous queues? Remember WorkFlo script? Talk about #BPM 1.0. :D—
Patrick Lujan (@pelujan) March 07, 2011
I responded to his tweet because I do remember “workflo”. It was something that FileNet developed back in 1985. I admit that this was indeed 10 years before I got into IT (having spent those 10 years doing stuff in laboratories), but I was very aware of it as it played a big part in a lot of their technology.
In fact, my first introduction to ECM was PC Docs, and also FileNet’s early Content Management application “Saros Mezzanine”. This was followed by their Image Management Services application running on an AIX system. It stored scanned images on WORM disks in an OSAR unit, and had a robotic arm jukebox. It was a bloody impressive , but also daunting, system (especially when you are new on the job, and you’ve been told to support this system at a very hostile client site).
Over the years I got more an more involved with FileNet and their products, getting to know the idiosyncrasies of each one. I worked as a consultant, and each client had its own unique requirements, environments, and situations. Very often I would go home at the end of the day feeling beaten up.
At the end of 2006 I moved into a position working with Documentum, and quickly after, SharePoint. However, this time, I was the client, and so if something didn’t work, someone else was responsible for “fixing it”. This gave me more time to think about the potential of the systems in terms of the industry I was now working in. I actually went home feeling a lot more relaxed.
Now, the one thing that always struck me, when I was working with FileNet, was that, compared to a Microsoft product, there was not a lot of material available. The majority of what you learnt came about through personal experience. You were on the battle field getting the scars. You felt that you had “earned it”.
Of course, there were forums available, and FileNet themselves had a great store of answers to questions, etc. (I used to trawl their partner site just to pick up nuggets of knowledge). Documentum (now EMC) have the same thing which I still use.
At the end of the last century (gawd – that sounds awful) I got my MCSE, and have kept up to speed with Microsoft technology since then. In 2007 I developed a Portal site that hooked into Documentum, and then, having got some scars with that, I got my SharePoint 2007 certification.
Now I am trying to build up my knowledge of SharePoint 2010. This time I’m trying to take a more business application view of the technology. I did AIIM’s SharePoint Master course, which gives a more “real” view of SP2010, especially with regards to Document Management. (See this post, and this one.) However, I realise that it’s still handy to have the MS certification under my belt, so I am working towards Microsoft SP2010 certification also.
I’m don’t want to pay for a course, and so I’m using the over-abundant resources that can be found on the internet (white papers, MS videos, MS learning material, etc). The more material I cover the more I am aware that the same message is being thrown at me – “how great SharePoint 2010 is”. (I’m not going to get into a discussion regarding this, as this has been covered by multitudes of blogs and forums on the internet).
The fact is I find myself slowly, (and blindingly), convinced. I’ve started chanting the mantra, and doing the dance.
Microsoft has produced so much stuff on their latest “shiny object”. It’s amazing. There books, videos, whitepapers, forums, faqs, technet articles, etc, etc, etc. There is also a conference/user group/gathering for the devout, almost every second week. And there are “evangelists” – people who spread the Word.
Got to admit, I am going to one of these conferences in April – the Best Practices Conference, being held in London (#bpcuk). The US one has just finished, and I was following the tweet stream (#bpc11). The funny thing was – I got to the point where I was “religiously” checking on the progress of the conference, and the activities of the participants (albeit the more “tweetal” – think of the word “vocal” but in terms of tweeting – amongst them). And I found myself just wishing I was there, wishing I was with these people and seeing, and sharing, what they were. (Quick – slap me!)
I never got this “ecstatic feeling” with FileNet. It was all mud and barbed wire. You were earning your stripes “old school”. And even though I have attended the Documentum user group conferences (Momentum) for a few years now (which is one of the high-points of my year – have only missed one over the last 5 years), I’ve never felt the (illogical, zealot-like) fervour that I am starting to experience now.
Related Links
http://geekswithblogs.net/SoYouKnow/archive/2011/06/14/is-the-sharepoint-community-past-its-prime.aspx
Recently a friend of mine was working on creating a Document Management portal.
That is, he was using SharePoint as the user interface,w. and was populating the pages with web parts that would allow the user to interact with a back-end document management system.
He had built up the Portal using SharePoint 2007, and had created several sub-sites that contain web parts that were relevant to the requirements of specific groups of users. He had run some informal testing and had confirmed that the web parts were offering the business users the functionality that they required. He had also spent some time on the design of each page. He was using a standard master page so that each sub-site had the same look and feel, but had made small tweaks to each page so that the presentation of the web parts was optimal.
Then he wanted to move the system to a SharePoint 2010 system. Fortunately the Portal site was not yet in use, and nothing extra, or unknown, had been done to the sites, so was pretty sure there wasn’t any customization. However he wasn’t sure what the best way to get his Portal from 2007 to 2010. So he called me.
We had a look at the options:
SharePoint 2010 had already been installed on a new, suitably spec’d server, so an in-place upgrade was not an option.
We examined the database attach method. This would involve making a backup of the 2007 content database, restoring it in the new SQL Server installation on the the new server, This sounded like a good option. The only thing we were worried about was the third-party we parts (the ones that hooked into the third-part document management system). We weren’t quite sure how these were going to respond.
We considered the third option – building the site from scratch on SP2010. This also introduced new challenges. Could we migrate the default. master from 2007 to 2010? I knew that 2010 didn’t use default.master, but now used v4.master. What impact would that have? We also had the ribbon to contend with, as well as the “Tags & Notes”, and “I like it” buttons. (The sites were meant to be static, offering only the ability of users to work with their documents. It was not meant to be a “social” site.)
One other benefit of an in-place, or database attach upgrade, was the fact that SharePoint 2010 offered a “Visual Upgrade”. That is, the 2007 look and feel is maintained, and there was the ability to “preview” how the sites would look in 2010. Once you were happy with them, you could make the changes permanent.
This would have been nice, but, because of the fact that we wanted to make sure that we could document how the Portal was built up, we decided that option 3 would be the best option.
So – the decision was made. The first step was to install the third-party web parts. And this is where it got interesting. We were using the latest version of these web parts that were SharePoint 2010 compatible, so we thought there would be no problem.
Except there was one small thing…
The third-party web parts were designed to use WSE. WSE, or Web Services Enhancements, is an add-on to the .NET framework that offers improvements to security and communication. It was released in 2005. The SharePoint server had been installed by another department according to a “standard”, and this included WCF, or Windows Communication Foundation. WCF was brought out as the “next-generation web service/interoperability framework”.
So here was the question: Do we get the department that installed the SharePoint server to uninstall 
WCF, and install WSE? Or do we ask the vendor to test, and certify that their web part technology will work with WCF?
Removing WCF and installing WSE would have very little impact to the overall scheme of things (the server was not being used for anything else), BUT it would mean a non standard installation.
On the other hand, the vendor has stated that their application was compatible with SP2010, and one would assume that it would be designed to use the newer WCF component.
Currently the discussion is going back and forth between the two options.
One thing though, this small compatibility issue wouldn’t have become quite so obvious if we had not decided to build up the Portal from scratch.
Related material:
——————————————————————————–
