A fellow Solution Architect I work with specialises in Records Management and is on the Professional Records Management Associations boards etc. here in Australia.

I have also been reading through Joel Olsen's Whitepaper on Compliance Features in the 2007 Microsoft Office System that was written back in November 2006.

What I am attempting to do is investigate how the likes of TRIM, OpenText and Interwoven work in terms of Records Management/Document Management and see where Sharepoint matches these "out of the box".

Platform Advantages

The advantage of Sharepoint is that it is built on a framework with a very substantial API Object Model. This enables me to write implementations that hook into the Sharepoint platform pretty much anywhere I please...potentially meaning that you can do anything you want in Sharepoint but it's going to take billable effort to do it.

Other Vendor products don't have as many hooks in and as many interfaces exposed which makes it hard to definitely be able to say yes to functionality especially around areas of User Interface and Events where Sharepoint is extremely strong.

The nice thing is that most of the API work in Sharepoint would be added using Features to Site Collections with hooks in for Events etc. A lot of other vendor products mean hacking away at the platform code which means that upgrades become a living nightmare! This is something that is often forgotten to be mentioned when doing custom development on such a platform.

Over the next few weeks I intend on producing some more structured articles on what Sharepoint can do in terms Records Management and where it needs work.

Quick Look

 I showed the Records Center to our Guru and she started flying requirements at me based on all the "Acts" that are out there. I've put a very brief account of some of these points:

Declaring a record
Once a working document is declared as a record all of it's versions should be captured and should be viewable. The document, as part of the record, should not be editable and versions of the document, also part of the record should not be either and should not be able to be deleted.
The first thing that our guru noticed was that you could delete versions of a document in a record and that you could also edit the metadata on the record.
She also noticed that sending the document to the Records Center still kep[t the document in the Document Library as well as now having a Record with a document inside it in the Records Center. Even to me this looked a bit unclear.
There isn't much out there in terms of Records Management, in the forms of books, white papers, blog articles and I intend on trying to open this area up a bit.

Record Declaration
Another area that she explained to me was around Record Declaration in terms of Document: linking, extraction, superseding, copying and moving.
Linking - From first glance, declaring a Word Document as a record that has a Hyperlink to another Sharepoint Document did not grab that Document as well when it created that Record.
Copying - Obviously as the Records Center can route to Document Libraries, you can copy and move the Records like any other List Item. I have yet to see whether it keeps an audit trail of these actions for the Record though. Obviously this could be done via Events, but again is more custom development.
There also seemed to be no options for the other features there either around extraction and superseding.

Where next?
I probably need to find out who the Sharepoint Records Management gurus are to shoot me down on my findings and show me how it really works as I go and I will be writing these lessons down as I come across them to save anyone else the pain.

The problem with jumping ahead with a Records Management solution, is no doubt Microsoft have now poached a few Records Managers and are taking all this feedback and writing in all this functionality into the Records Center as either a service pack, a Site Template release or possibly as part of Sharepoint 2009.
It is a major hole in the ECM story for Sharepoint as a Enterprise solution and I would be strongly recommending 3rd Party integration with OpenText, TRIM or Interwoven if there is a strong Records Management requirement.

Watch this space as I delve deeper into the world of Records Managers.