The records and information management standard ISO 15489 groups authenticity with sister concepts reliability, usability and integrity. The standard tells us the retention phase of the life cycle of the record should eliminate as early as possible -- and in an authorized, systematic manner -- records which are no longer required. In addition, the record should retain its context so future users may judge its authenticity and reliability.

An authentic record is one that can be proven to be what it should be, created or sent by the creator or sender, and created or sent at the moment it was created. The iteration lends credibility to the definition, but translated in simpler terms, think of it this way: You don’t mess with the record once a document is declared to be one. ISO 15489 advises the use of policies and procedures to “control the creation, receipt transmission, maintenance and disposition of records to ensure that records creators are authorized and identified.”

Procedures support the issues around conversion and migration -- “any kind of system change, including format conversion, migration between hardware and operating systems or specific software applications, for the entire period of their retention.” When a records system is discontinued or decommissioned, no further records may be added to the system, although they should continue to be accessible. The most important reference to authenticity occurs in ISO 15489’s Technical Report (Part Two): evidential weight.

If the integrity or authenticity of a record is called into doubt in court by suggestions of tampering, incompetence, improper system functionality or malfunction, the evidential weight or value put on the document by the court may be lost or, at least, reduced, to the detriment of the case.

Also, the standard’s authors were foresighted enough to describe the relationship between authenticity and media and/or application storage.

Records should be stored on media that ensure their usability, reliability, authenticity and preservation for as long as they are needed. Issues relating to the maintenance, handling and storage of records arise throughout their existence, not only when they become inactive. Systems for electronic records should be designed so that records will remain accessible, authentic, reliable and useable through any kind of system change, for the entire period of their retention. This may include migration to different software, re-presentation in emulation formats or any other future ways of re-presenting records. Where such processes occur, evidence of these should be kept, along with details of any variation in records design and format.

Business Connectivity Services

Authenticity is a half-step outside the purview of systems architecture, but SharePoint 2010 does valiantly try to address it in small but significant ways. We’ve already discussed In-Place Records Management versus records transition to the Records Center, so I won’t dwell on that here. I prefer to discuss authenticity from a Business Connectivity Services (BCS) point of view, or “authorization.”

Business Connectivity Services is a service application that bridges the gap between external softwares and SharePoint 2010 sites, lists, search functions and user profiles. The SharePoint 2010 Administrator’s Companion tells us two of the many benefits of BCS are “a deeper integration of data into places where a user works” and “centralize(d) data security auditing and connections.” The Administrator creates the BCS application, then the base metadata, and finally names, properties, permissions, and custom settings. They can describe all of this in an XML file (aka “the BDC model”). Then, once the file is imported into SharePoint 2010, the external data becomes available to the web applications associated with the BCS application.

The Companion tells us “the BCS data connectivity layer (BDC) uses connectors to access the external systems. Connectors allow the end user to connect to databases, cloud-based services, Windows Communication Foundation endpoints, web services, the .NET assembly that gathers data from multiple sources, and custom external systems that have non-static interfaces that change dynamically.” BDC Administration creates, reads, updates, and deletes objects within the metadata store.

Drilling down further, external content types (ECT) -- the building blocks of BCS -- define “fields and behaviors of data in SharePoint and Office Client applications. The model adds meaning to…the data. It describes…the relationship between the different types of data.” The most important object within the model file is the “Entity” object. It refers to the ECT, which relates to information from the external system. The Companion tells us that it could be an author, a customer, a sales order, or a product (i.e., metadata or records series). Each entity object consists of a number of child XML element tags, which include:

  • Methods: create, read item, update, delete and read list
  • Actions: a link to the external system and write-back scenarios (for example, opening an email)
  • Access Control Lists: permissions for the objects in the models

The model file provides one of the many audit trails useful in e-discovery. More on that later.

A Rose By Any Other Name…

The italics above are my emphasis. The Companion admits “the creation of base metadata and resource information is an important activity” but doesn’t quite…know…how… to further define it. I think the italicized selection lends credibility to ISO 15489’s assertion that policy must support the procedure -- that SharePoint 2010’s authentication architecture between itself and third-party applications falls under the authenticity and audit trails headings of the records and information standard.

Who may define metadata for IT while its SharePoint 2010 team plans the implementation? Attention, records folks: Do you see where you can add value? We can provide a high-level overview of the importance of evidential weight as it pertains to metadata and records series development in a high-profile, corporate-wide implementation. The database administrator writing this model file needs your services.

Records professionals are a fantastic resource to serve the SharePoint 2010 team in the business analyst role. The essential point is this: The typical Records Center role in SharePoint 2010 shouldn’t satisfy us records and information management professionals anymore. We can answer deep systems and information architecture questions.

Editor's Note: You may also be interested in reading: