Blogs

Very few people outside of the Department of Defense have more firsthand experience with the DoD 5015.2 Electronic Records Management Software Applications Design Criteria Standard than I do.  I first began working with the Standard in the late 90s when I was hired as consultant for a small company called TrueArc.  TrueArc was the new name for a company called Provenance.  Provenance had one product, a records management application called ForeMost.  A few years before I joined the company, ForeMost had become the first records management application to be awarded DoD 5015.2 certification. 

Over the course of the next 12 years or so I played a major role in the design, creation and certification of four entirely new electronic records management applications (including two SharePoint-based solutions) and consulted in the product design or certification process of at least a half dozen others. 

In the past I have supported the Standard because I honestly believed that, while it certainly wasn’t perfect, it nevertheless provided a reasonable framework for managing records in an electronic environment.  However, over the last few years that opinion has changed considerably and I have come to view the Standard as both an obsolete relic of 20-year-old business model and a failed attempt to provide effective functional requirements for managing electronic content through the final stages of the information lifecycle.  And I believe as a Certified Records Manager and dedicated Information Lifecycle Management professional, I am ethically obligated to state my opinion publically. 

________________________

The first version of DoD 5015.2 was released in 1996 after many months of extensive research by dedicated analysts at the Department of Defense with the support of a number of private sector Records Management professionals providing consultation.  From a technical perspective, 1996 is several lifetimes away.  For those of us who are old enough to remember, the early 90s saw the creation of a new set of collaboration products which, at the time, were called ‘Document Management’ applications.  There were many vendors creating many different versions of Document Management products, but it wasn’t long before a small number of products captured the significant majority of the market. 

For the most part, these solutions provided the basic functionality required to manage unstructured content through the early stages of the Information Lifecycle: Creation, Distribution and Use.  Most products had some rudimentary features that provided limited support for the fourth stage of the Information Lifecycle, Maintenance.  None of the major Document Management solutions natively supported the last stage of the Information Lifecycle, Disposition.  This limitation precipitated the creation of a new software market segment, the Records Management Application. 

Just as with Document Management applications, many new Records Management products were released over a short period of time, but only a handful of solutions were broadly adopted by the general market.  (The significance of the market-driven evolution of these product sets should not be underappreciated. The notion of completely different applications managing distinct stages of the Information Lifecycle helped perpetuate the belief that unstructured content can be separated into non-record ‘documents’ or official ‘records’ -  when in fact that distinction is completely irrelevant given that all of this material is discoverable evidence in a legal matter and must all be managed accordingly.  I believe the idea that unstructured content can be segmented in ‘records’ or ‘documents’ has caused incalculable damage to the Enterprise Content Management industry and confused users, vendors and even other Records Management professionals ever since.) 

Even though a few forward-thinking vendors were just beginning to integrate their Document Management solutions with existing Records Management applications and creating the first rudimentary Enterprise Content Management solutions, separate solutions for ‘document management’ and ‘records management’ was the state of the market when the DoD decided to create the first version of the Standard.  And the DoD wanted to standardize how they managed their ‘records’ across all branches of the Service, so it made sense for them to build a standard around functionality that focused on the end-state lifecycle stages that were currently being addressed in existing records management products - at the exclusion of most other lifecycle management features that were included at the time in document management applications. 

Interestingly, this explains why the DoD named the 5015.2 Standard the ‘Electronic Records Management Software Application Design Criteria Standard’ and why the Standard itself says it “sets forth mandatory baseline functional requirements for Records Management Application (RMA) software used by the DoD Components in implementing their records management programs”. 

The problem here is obvious to anyone even remotely involved in the Enterprise Content Management industry: stand-alone Records Management applications haven’t existed for almost a decade.  The first few years after the turn of the last century saw a flurry of acquisitions by the established Document Management vendors of the smaller Records Management application companies.  These products were integrated (with varying levels of success) and the first Enterprise Content Management (ECM) solutions were the result.  These new integrated solutions were the first to provide customers with the ability to manage unstructured content across the enterprise throughout its lifecycle.  From creation to distribution, to use and maintenance and to final disposition, content was being managed cradle-to-the-grave in one unified solution.

Yet the DoD Standard never adapted to this fundamental shift in content management technology.  Through more than 17 years and three versions of the Standard, it has steadfastly remained a very detailed set of functional requirements for a records management application.

I remember when I was young, my dad would often carry a beeper with him in case his office needed to contact him quickly.  At the time, I thought that was pretty cool technology.  Beeper use was fairly common back in those days and I imagine there was at least one industry standard that they applied to. 

But of course technology evolved and beepers have been replaced by cell phones, an exponentially better solution to the problem that beepers addressed. 

The cell phone industry has a myriad of standards to which it complies.  And I wouldn’t be at all surprised if those standards don’t include some small set of requirements left over from beeper technology.  But those standards address the current state of the technology: cellular phones, not beepers.

The DoD 5015.2 Electronic Records Management Software Applications Design Criteria Standard is a beeper standard in the Age of iPhones.

________________________

I had no input on the original version of the 5015.2 Standard.  Nor did I provide any consultation on either of the subsequent revisions.  If I had, I am under no illusion that I would have done a better job designing the Standard than the dedicated people at the Department of Defense have done.

That said, there are about 170 unique functional requirements in the DoD 5015.2 and I can tell you from experience that all but a very few of them are either irrelevant, obsolete, over-engineered or completely unnecessary for managing the final stages of the information lifecycle of unstructured electronic content given today’s technology. 

A detailed description of the problems with each requirement in the Standard would fill a good-sized book and (despite overwhelming appearance to the contrary) I am trying to be brief - so I will limit my discussion to concerns I have with a few high-level groups of requirements. 

If you are not entirely familiar with the certification process, it is important to keep in mind that DoD 5015.2 certification is an all-or-nothing proposition.  In other words, the product vendor hoping for certification must meet every one of the 170+ requirements to be granted certification, so no one set of requirements is more important than any other.

Cutoff Processing

As a Certified Records Manager, I have a fairly well documented understanding of how organizations manage records through their lifecycle.  Over the course of my career, I have only occasionally heard mention of organizations including a cutoff process as the Standard defines it as part of their records management practices.  And these organizations have always been some part of the US Federal government and cutoff has always been limited to managing physical (e.g. paper) records rather than electronic records.   

I do not see any real benefit to including a cutoff process in managing electronically stored records.  The notion of a cutoff was created to facilitate the bundling of (paper) records that expire at different intervals so the transfer or destruction of those records could be carried out with more efficiency.  (For example, a paper record due for destruction on June 3^rd, one due for destruction on June 17^thand one due for destruction on June 25^thwould all have Cutoff Dates of June 30^th, would all be put into the same folder and all destroyed during the scheduled monthly records disposition process.) 

Because the destruction (or transfer) of records can be automated in an electronic records management environment, the value of cutoff processing has been completely eliminated.  Yet there remains dozens of Cutoff Processing requirements in the DoD Standard and vendors have spent millions and millions of dollars developing functionality to meet those requirements. 

Metadata Management

There are two iron-clad rules in effective records management: 1) minimize the burden on the end user and 2) create accurate record classification strategies.  Break either of these rules and your entire solution will be rendered useless.  The Baseline Compliance Test Procedures for certifying against the Standard is full of countless metadata requirements for a wide range of record types.   The level of metadata tagging suggested by these procedures would almost certainly impose an undue burden on any organization’s end users and would undoubtedly result in an extremely low (perhaps even zero) adoption rate. 

In addition, there are a number of very specific, sometimes obscure, requirements for how certain properties must behave.  Meeting these requirements is often difficult for product vendors because their metadata properties are normally a core component of their solutions and usually very difficult to modify.  But the solution vendor is forced to create these unique metadata features that, at best, provide marginal utility in a production implementation. 

Email Records Management                                                                                   

The Standard has scores of very clearly defined requirements for email records management.  All but a very few are wholly unnecessary and simply won’t be used in a real-world production environment.  As anyone who has been employed in the last 20 years knows, the proliferation of email has been explosive.  More than any other record format, the process of declaring an email record must be extremely simple.  Any solution that is the least bit taxing on the end user is certain to fail. 

Yet the Standard still requires incredibly complicated (and ultimately laborious) email records management functionality for product certification. 

Is it nice, for example, to be able to classify an email and all four of its attachments into different categories across the file plan, each with its own unique set of metadata and each with a link to the email and the other attachments?  Yeah, sure.  Will anyone in a real world implementation ever actually do that for one email, much less the multiple email records they may have to declare every day?  No, absolutely not. 

Non-electronic Documents 

As the title of the DoD 5015.2 Standard suggests, its intention is to provide procedural guidance for managing the lifecycle of electronic records, yet it includes some very specific requirements for managing non-electronic (i.e. paper) records, as well.  Interestingly, these requirements are not at a level that would allow an organization to realistically manage all of their non-electronic records in the same certified solution that manages their electronic records.

There are separate standards for physical records management solutions and some great products with excellent integrations with existing electronic Information Lifecycle Management applications.  The DoD Standard should defer to them and focus exclusively on the features and functionality required for managing electronic records. 

Records Relationships

The Standard requires the ability to associate one record with another through records relationships.  A certified solution must be able to create custom hierarchical types, as well as custom peer-to-peer relationships types that can be applied to two or more records across the repository. 

These relationships are expected to be part of the record’s metadata and managed along with the retention and disposition of the target record (e.g. if Record A has a relationship with Record B and Record B is destroyed as a result of meeting the end of its retention period, Record A’s relationship to Record B should also be destroyed.)

Years ago when virtually all of our records were on paper it made sense to have a few relationships types that could be applied from one record to another (cross-reference and convenience copy are two that come to mind).  But things have changed since then.  Given today’s technology - especially with respect to search and retrieval capabilities - this functionality, particularly at this level of complexity, is almost certain to go completely unused in a production environment. 

Metadata-based Security

There are two primary forms of metadata-based item-level security required by the DoD 5105.2 Standard, ‘Supplemental Markings’ and what I’ve always referred to as ‘Access Control Columns’.  Supplemental Markings are required properties on records (or ‘folders’), while one or more Access Constraining Columns can optionally be applied to records as necessary to meet the particular record’s unique security requirements. 

The security provided by Supplemental Markings (SMs) is similar in most ways to that provided by Access Control Columns (ACCs) except for a few small differences.  To be as brief as possible, a user or group of users is assigned predefined SM values, such as NOFORN or FOUO, and one or more of those values are optionally assigned to individual items in the file plan.  In order to have access to those items, a user or group must have all of the values assigned to them.  (As an example, if a user is only assigned NOFORN and the item he wants access to is assigned NOFORN and FOUO, he would be denied any access to it.)

ACCs are user defined fields that can optionally be designated to support item-level access control.  For instance, a property could be created called ‘Region’ and it could be designated as an ACC.  It could have three predefined values, Region A, Region B and Region C.  One or more of these values could be assigned to a user or group and one or more of these values could be assigned to an item in the file plan.  However, unlike with SMs, a user or group only needs to be assigned one of the values to access the item.  So, if a user is assigned a Region value of ‘Region A’ and an item is assigned values ‘Region A’ and ‘Region B’, he would still be granted access to the item.

Used separately, these item-level security requirements can become very complicated quite quickly when implemented in a production environment.  But, technically speaking, they must be able to work together, as well.  So it is very possible a scenario may occur where a single record has active Supplemental Marking security requirements and one or more Access Control Columns.  Given the tremendous volumes of records in most mature repositories, this potential real world scenario – which product developers must consider and test for - would produce a mind-boggling level complexity and render the entire solution unmanageable. 

Product vendors have spent countless hours developing features that meet Supplemental Markings and Access Control Column requirements.  Unfortunately, I would be very surprised if there are any organizations out there – public or private – that actually use them. 

________________________

By themselves these design flaws are problematic enough, but they unfortunately become compounded by the certification process itself.  The 5015.2 is a detailed description of how the US Department of Defense wants to manage its electronically stored records.  The processes, procedures, roles and permissions are all designed to meet the specific requirements for records management functionality in a DoD repository.  In this respect, the 5015.2 more closely resembles a solution requirements document than an application standard.  Yet the Standard has been widely adopted by non-DoD agencies, State and Local governments and countless private sector organizations in the US and across the globe. 

Standards are meant to define solutions to problems experienced by an entire market, not one particular customer. But vendors are forced to meet every requirement in the Standard (as interpreted in the official Baseline Test Procedures) or risk failing certification. 

For example, the Standard requires that a certified solution allows a user to file a single unique record in multiple locations in the file plan, maintain links between them and manage each filing according to the retention and disposition requirements assigned to the record category or folder into which the record has been classified.  From a technical perspective, this is an extremely complicated requirement and product companies spend thousands of man hours and hundreds of thousands of dollars creating functionality to meet it. 

Yet I can’t imagine why this requirement is included in the Standard at all.  This isn’t something that was ever required in paper-centric records management.  In fact, it wouldn’t have even been physically possible with non-electronic records.  This requirement is just one of several in the Standard that make me sometimes wonder if its designers sat back and came up with ideas that started with the phrase, ‘Wouldn’t it be cool if we had a requirement that…’, but never actually justified its inclusion from a market-wide best practices perspective.  

My other primary concern with product certification is that what passes for compliance with any particular requirement seems to be completely arbitrary.  No consideration seems to be put into the idea of whether or not the solution is a realistic interpretation of the requirements that would be readily adopted in a real world deployment. 

For instance, I’ve seen solutions (none of which I’ve designed) that manage retention and disposition workflows that require the user to suspend the workflow when a particular event occurs and then restart the workflow at the end of a given retention period.  But the retention period could be 25 years or more.  Is that a valid solution to the problem?  Does anyone really believe that an organization would maintain a suspended workflow – like a car idling in your driveway – for 25 years?  How about 10 years?  Or five?

And I’ve seen certified email solutions – again, not of my design – with declaration strategies that require the user to move the email to a managed folder, add some metadata properties, wait (usually overnight) for the system to route the email into the records repository, log into the repository, navigate to wherever the email record was routed, add additional metadata values and finally approve the email record for classification into the file plan.  

I am not arguing that these examples of certified solutions don’t meet the letter of the law for their particular requirements.  Technically speaking, they do.  What concerns me as an experienced Records Management professional is I am certain beyond doubt that they would never actually be used to manage anyone’s records. 

________________________

Standards play a vital role in virtually every industry.  They are essential to progress, particularly with regards to information technology solutions.  I thoroughly believe in standards and I support them completely.  I just can no longer support this one.

  ________________________

[Editor's Note: Don's article has sparked quite a bit of debate, both below and in two separate blog posts:

Mark Mandel: I Support DoD 5015.2; and Encourage ALL Federal Agencies to Adopt It

Ron Layel: To Support or Not Support the DoD 5015.2 Standard (Some pet peeves and views on the debate from a RIM practitioner’s perspective)

Enjoy them both; and the conversation.]