Allow me the privilege of being the Devil's Advocate: "programming source code is NOT a record".
Obviously, much depends on how you define a record.
Under the broadest definition, almost anything can be a record including, as I have mentioned before, geological core samples.
The problem with the most expansive definition is you have no boundaries. In a "no boundaries" situation, "scope creep" becomes institutionalised, and such well-accepted methods as cost-benefit analysis fail altogether.
So perhaps one could say that, in theory -- and in the right business context -- programming source code COULD BE a record, but that under, most organisational settings, it SHOULD NOT.
A fruitful discussion indeed.
Fred
-----------------------------------------------------------
Frederic J. Grevin, Vice-President
Records Management Department
New York City Economic Development Corporation . www.nycedc.com
[log in to unmask] . w. 212.312.3903 . mobile 917.510.3016 . f. 212.618.5722
-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf Of Stakhov, Gene
Sent: Tuesday, October 09, 2012 11:17 AM
To: [log in to unmask]
Subject: Re: Is programming source code considered a record?
Ilana,
This is a topic of great interest to me. Like my colleagues who've submitted their opinions, I too contend that an organization's source code amounts to intellectual property and ought to be treated as a record with business value. As Mimi Dionne stated earlier, retention can be managed on a per-project basis or for Life of Corporation, etc.
The difficulty I've found in real world implementations of this lies not so much in the conceptual definition of what source code is, but in the tactical mechanics...the bridge between the system of record (source code control system - i.e., SourceSafe, Subversion, etc.) and the enterprise RMA - assuming one exists. Usually this bridge, or "connector" needs to be written from scratch. Also, in the course of the development (or code version upgrade) process, modules of code are moved around, deleted, obviously modified, etc. The task of ensuring immutability - from a purely records standpoint - is much more difficult in the dynamic nature of software development. Of course it's not impossible, but managing code as records requires much more active involvement from the person(s) managing the code repository. It also involves buy-in from the developers, team leads, QA folks, etc.
I've felt for a long time (and have presented on the notion) that the maturity model and principles of ... The Principles ... can (and SHOULD) be mapped to the principles of sound software development (and/or the SDLC), if not for the obvious task of managing source code as a record, then at the very least for bridging the communication gap between IG and IT.
Eugene Stakhov, CRM, CDIA+
Senior Solution Architect
Lighthouse Computer Services, Inc.
[log in to unmask]<mailto:[log in to unmask]>
Twitter: @crmgene
909-CRM-GENE
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
