About 10 years ago, all you heard about in IT was consolidate, consolidate, consolidate. Back then consolidate meant economies of scale, bring all website together and save money by utilizing less resources and infrastructure. This really worked in the short run, but news flash, the silos are back: they never went anywhere. The silos I’m talking about are brain trusts of business units that work as a team but don’t really share. The walls of the silos are still there; they are just within the ECM now. ECM itself has built its own silos: silos of services.
So I was reading an article entitled, “How to Save the News” in the Atlantic. It describes the downfall of the traditional newspaper revenue model with the help of the Internet and Google. But Google says it’s on the newspaper’s side. Google’s assessment of the journalism is that the “Bundling was the idea that all parts of the paper came literally in one wrapper—news, sports, comics, grocery-store coupons—and that people who bought the paper for one part implicitly subsidized all the rest…” The internet is forcing newspapers to unbundle their sections, thus their revenue cows.
The idea of unbundling got me thinking about a platform in the enterprise that is allowing business units to manage their content in “silos” without worrying about the cost anymore. The platform is doing to ECM what Google and others are doing to the newspaper industry. The platform integrates well with the OS, productivity software, and the email system. The platform offers most of what ECM offers. The platform licensing model makes sense. The platform is SharePoint.
OK. So how do ECM solution providers unbundled the stack and content that has taken years to design, develop, and deploy? Answer: One business unit at a time. Webservices and CMIS will allow for the slow migration away from the great “consolidation” ideas of the early 2000s. As migration happens, some of the standards and best practices that were too expensive to implement in the past will be implemented. Business units will be able to do what they want in their information “silo”, but will be using standards of metadata, taxonomy, security, business process, and records management. Farming for knowledge will be possible by virtue of these standards. The days of the ubiquitous file share will come to a close, the new platform that will be taken for granted is SharePoint.
ECM vendors will split up their services and sell them separately. For example, workflow services are in desperate need of enterprise integration. ECM software can and should pursue this. Also, records management should be an integrated service with SharePoint. Not the underlying repository. Unbundling and expanding ECM services will be key to ECM’s software strategy.
Friday, May 28, 2010
Thursday, May 27, 2010
Decoupling ECM
As your enterprise content migrates from one repository vendor to another, you will feel the pain of not following decoupling standards that I’m sure were implemented but not fully. By “not fully” I mean in 2001 you tried an interoperable integration only to cancel it because the APIs were limited and the performance was slow. To add fuel to the fire, CMIS is being pushed on us and that means if you’ve been following standards of information architecture with metadata, linking from external sources, training application integration, workflow, taxonomy, and databases, you’ll be fine. However, who has been able and/or could afford to follow all of the best practices? Anyone?
Below is a list that starts to detail what needs to be looked at when thinking about decoupling and preparing for CMIS or a migration.
Metadata
Is the object model and attributes designed well? Are there issues with attribute that have one name, but are used for other functionality? Will system date attributes like creation date and modified date trigger any unexpected actions? For example, if you have a retention schedule based on creation date and you migrate your content (creating a new creation date), what’s the real creation date?
Intranet/Portal
Links from a website via a URL that points to content in the repository will most likely be broken during a migration. Portlet Integrations that use APIs to query content in the repository will have to be checked. Content that is published to a separate website will have couplings with attributes from the repository which will break.
Training
Links to content (SOPs) as training material that is triggered by changes in modification dates will have to be redesigned.
Taxonomy
Relationships of folder structures with attributes will have to be reviewed.
Web services
Any dependencies with attributes and content ids will be broken.
Database Integration
Redesign any dependence the integration with repository database has on system generated dates.
Below is a list that starts to detail what needs to be looked at when thinking about decoupling and preparing for CMIS or a migration.
Metadata
Is the object model and attributes designed well? Are there issues with attribute that have one name, but are used for other functionality? Will system date attributes like creation date and modified date trigger any unexpected actions? For example, if you have a retention schedule based on creation date and you migrate your content (creating a new creation date), what’s the real creation date?
Intranet/Portal
Links from a website via a URL that points to content in the repository will most likely be broken during a migration. Portlet Integrations that use APIs to query content in the repository will have to be checked. Content that is published to a separate website will have couplings with attributes from the repository which will break.
Training
Links to content (SOPs) as training material that is triggered by changes in modification dates will have to be redesigned.
Taxonomy
Relationships of folder structures with attributes will have to be reviewed.
Web services
Any dependencies with attributes and content ids will be broken.
Database Integration
Redesign any dependence the integration with repository database has on system generated dates.
Friday, May 14, 2010
Free DCTM Object Model Tool
As a developer and solution architect you know it's a pain to document the object model and attributes deploy it and then document it again after minor changes -- and there will be changes. This tool allows you to select any dm_sysyobject child type and show its attributes and up to four levels of that object's child objects. Comes in handy to visualize a repository's object and metadata structure.
Wednesday, May 12, 2010
Legal Discovery Drill
If you ever want to really drive home the need for records management and info architecture in your enterprise, run a discovery drill on the production systems. Drive it from Legal and send in “auditors” for outside counsel and work through the IT processes, testing, term searches, extracts and exports, org charts, the works.
In the least it would tick off the admins and DBA’s who have to do the grunt work. But, it could open up all sorts of discussions around the right ways to structure metadata and content such that the discovery process is more straightforward and less risky. Preserving content is half the battle; the other half is finding it.
There will always be a divide between managers who want to identify and separate content as “records” and those who recognize that the process of record identification is too much work and that all content should be considered part of the record albeit in a “big bucket” sense. For example, email that is not considered a record by a small group of records managers and is deleted could be later deemed extremely relevant to an investigation and a judge could decide to slap an adverse judgment on the evidence meaning that the jury should assume the worse possible conclusion about the email’s contents. The risk of this is weighed by counsel…
In the least it would tick off the admins and DBA’s who have to do the grunt work. But, it could open up all sorts of discussions around the right ways to structure metadata and content such that the discovery process is more straightforward and less risky. Preserving content is half the battle; the other half is finding it.
There will always be a divide between managers who want to identify and separate content as “records” and those who recognize that the process of record identification is too much work and that all content should be considered part of the record albeit in a “big bucket” sense. For example, email that is not considered a record by a small group of records managers and is deleted could be later deemed extremely relevant to an investigation and a judge could decide to slap an adverse judgment on the evidence meaning that the jury should assume the worse possible conclusion about the email’s contents. The risk of this is weighed by counsel…
Friday, May 7, 2010
Mapping your Records Retention Schedule
OK, so you had a consultant meticulously categorize and detail every type of record your company has and how long to keep them. The consultant looked at all of the paper documents for the passed 20 years which have been stored at Iron Mountain. This you thought is the source of all records, but did the consultant cross reference these “best practice” categories/file plan with the actual ECM repository(s) in use today? Did the RRS get vetted by a representative sample of business groups from the company? Is the RRS in a form that can be easily modified during the years it might take to implement it and the constant tweaks made to it on an ongoing basis?
Let’s assume that some of these questions were considered and that you have a reasonably well put together RRS. Now let’s look at the RRS to figure out how to apply it to an ECM application. Mapping the RRS columns of information may not be that obvious at first glance. The column headers will be generic like “record class name” and “customer record class code”. Which one should be what the Records Officer sees and what should the Users of the ECM see? The “code” is usually distinct thus it should be used as the File Plan number and Record Series Indicator. The File Plan corresponds to the folder or classification and the Record Series Indicator corresponds to the retention schedule object.
When you see the columns “Event” and “Period” these correspond to the status that triggers the status date and how long to keep the content in that state. For example, if the period states ACT+INA 6, this means keep the content if it’s active and dispose of it when the content is inactive for 6 years. The event could be when the content was created, or if the content is superceded. The schedule is attached to the Record Series Indicator and might have multiple schedules per series for ACT, INA, ARC, CLO, etc.
The “description” section might have extra information which could be useful for classification terms or record series types. It should also be added to the configuration to help describe both the File Plan and the Record Series Indicator.
Do you have content types and lifecycle states?
Doc type, status, and status date are essential to configuring your RRS. These may be obvious based on how the ECM object model was designed or how workflows push content through their states, however it assumes that all your content is processed this way and most important that it is consistently processed this way. A tall order for even the best designed repositories.
User Adoption
As you map and configure your RRS keep User adoption in the back of your mind. Think about seamless use for tagging records. Should all content be a record or just some designated by the Records Officer? My opinion is that all content needs to be disposed of eventually so all content is a record. There are different levels of records importance to the company and these will be retained, monitored, and secured accordingly.
Let’s assume that some of these questions were considered and that you have a reasonably well put together RRS. Now let’s look at the RRS to figure out how to apply it to an ECM application. Mapping the RRS columns of information may not be that obvious at first glance. The column headers will be generic like “record class name” and “customer record class code”. Which one should be what the Records Officer sees and what should the Users of the ECM see? The “code” is usually distinct thus it should be used as the File Plan number and Record Series Indicator. The File Plan corresponds to the folder or classification and the Record Series Indicator corresponds to the retention schedule object.
When you see the columns “Event” and “Period” these correspond to the status that triggers the status date and how long to keep the content in that state. For example, if the period states ACT+INA 6, this means keep the content if it’s active and dispose of it when the content is inactive for 6 years. The event could be when the content was created, or if the content is superceded. The schedule is attached to the Record Series Indicator and might have multiple schedules per series for ACT, INA, ARC, CLO, etc.
The “description” section might have extra information which could be useful for classification terms or record series types. It should also be added to the configuration to help describe both the File Plan and the Record Series Indicator.
Do you have content types and lifecycle states?
Doc type, status, and status date are essential to configuring your RRS. These may be obvious based on how the ECM object model was designed or how workflows push content through their states, however it assumes that all your content is processed this way and most important that it is consistently processed this way. A tall order for even the best designed repositories.
User Adoption
As you map and configure your RRS keep User adoption in the back of your mind. Think about seamless use for tagging records. Should all content be a record or just some designated by the Records Officer? My opinion is that all content needs to be disposed of eventually so all content is a record. There are different levels of records importance to the company and these will be retained, monitored, and secured accordingly.
Subscribe to:
Posts (Atom)