I’m going philosophical for a moment here. Why do we have a technical systems oriented concept of “single point of failure”? Aren’t we all “single points of failure” and the recovery from our absence is proportional to the much we shared of our experiences? The risk of losing a connection, process, services, invocation, etc is proportional to how much we know about system’s interactions and what their limits are.
Redundancy is nothing but an attempt to backfill a single point of failure. Redundancy is really just a double point of failure if you think about it. How many points of redundancy is really risk free? If you have one hot backup system to failover to, then what do you have if that fails? It’s better than nothing, but not fail safe. Enough of this sophomoric banter, let’s try to figure out a list of single points to check and test.
Any call for failover and redundancy is mandated by a Service Level Agreement between the business and IT. This agreement has flexibility factors built into it and is most likely an extension of a more comprehensive regulatory or industry standard. It usually happens when an old policy didn’t work according to plan and the C’s freaked out.
Can you perform an in-place upgrade a system without downtime? If not, what services in the application stack are not redundant enough? Here’s a common list of systems and issues to consider:
Application Servers
Should be clustered for failover, however do sessions really failover gracefully or do Users get errors during the failure?
Database Servers
Should be setup with a hot failover like an Oracle RAC system. This would allow for backup recovery. Also, as storage expensive as transaction logs are some cases these could be a life saver.
Service accounts: Local vs. Domain
I understand that applications need to be secured between services and file systems, but to only allow domain accounts for an application sets up a potential for one account to run services that could all fail if there is an account lockout of that one domain account, or Active Directory. Local admin accounts serve the same purpose and in most cases can be substituted for the domain account.
Storage Backup/Restore
Storage itself is relatively straight forward; backing it up and restoring it is a whole different story. Backups are usually done on a rolling basis: full on the weekend, incremental on the weekends. But, what happens when a restore from tape is needed? The normal backups get delayed because the same system is used for both. Do you know how long it takes to restore from the backup? Are the backups redundant? How close is the backup machine to the application? Is there a whole DR off sight solution?
Saturday, July 10, 2010
Wednesday, July 7, 2010
Free Export/Import Tool Registered tables, groups, ACLs, and Users (for DCTM)
When it comes time to designing the community, information, and structures of the repository, these Java tools will come in handy. They facilitate deployment between environments. They also allow for editing in Excel and porting back into the repository.
Wednesday, June 23, 2010
Forcing Structure by Leveraging a Crisis
Leveraging a crisis happens all the time in politics and the financial industry. Why not leverage a crisis for the sake of organizing content? Let's face it unstructured content will remain as such unless a fire is lit under the businesses responsible for making the mess in the first place. Here are five possible avenues to pursue if the opportunity arises. The idea here is to build a foundation of detail and context, the "who, what, and where" of Zachman's framework. This will provide a foundation to then apply certain tools to go to the next levels of acting on the content in ways that structure, permission, and dispose.
Legal
Let's say there's a lawsuit against your company and the legal department is breathing down IT's neck to find, collect, and produce information and content pertinent to the case. You're not too happy with the 3rd party vendor who is helping collect the information. The business is somewhat removed from any searching activities. Most of the burden is on IT. But why? Who created this chaos call "content management"? What you could do is use the litigation request as a method to push back detailing content and context to the business under the guise of needing this information for legal counsel.
Cost
When cost cutting is running it's course through your company, use this to apply a cost charge structure where the business units bear the burden of paying for all aspects of IT. For example, if you inventory your ECM user groups, I bet you'll find a few groups which use larger percentages of the system in terms of licenses and storage capacity. When these groups feel the pain of actually paying out of pocket for IT's services and storage, they will quickly want to figure out what the records management policies are and dispose of content. They will also want to structure their content to better understand what they have and who owns it.
Security
If there is a breach in the ECM system, unauthorized access to sensitive information, the business will want to clamp down on access control. This will prompt the business units to figure out what they have and who can see it. It would be a good time to apply metadata and better folder structure to the content as they are applying ACLs.
IT Capabilities: Limits of DR and SLA
The next time a system goes down because of backup time during an upgrade, or recovering from a flooded data center, the business will be tick off, but receptive. This could be an opportunity to mandate standards of ECM organization and use.
Resources
If the work requests of the ECM system are back logged and the business is complaining, try pushing back an agenda of redesign and restructuring the content and information architecture. Too many customizations to a system could mean it's time to upgrade and apply standards that help integrations and interoperability.
Legal
Let's say there's a lawsuit against your company and the legal department is breathing down IT's neck to find, collect, and produce information and content pertinent to the case. You're not too happy with the 3rd party vendor who is helping collect the information. The business is somewhat removed from any searching activities. Most of the burden is on IT. But why? Who created this chaos call "content management"? What you could do is use the litigation request as a method to push back detailing content and context to the business under the guise of needing this information for legal counsel.
Cost
When cost cutting is running it's course through your company, use this to apply a cost charge structure where the business units bear the burden of paying for all aspects of IT. For example, if you inventory your ECM user groups, I bet you'll find a few groups which use larger percentages of the system in terms of licenses and storage capacity. When these groups feel the pain of actually paying out of pocket for IT's services and storage, they will quickly want to figure out what the records management policies are and dispose of content. They will also want to structure their content to better understand what they have and who owns it.
Security
If there is a breach in the ECM system, unauthorized access to sensitive information, the business will want to clamp down on access control. This will prompt the business units to figure out what they have and who can see it. It would be a good time to apply metadata and better folder structure to the content as they are applying ACLs.
IT Capabilities: Limits of DR and SLA
The next time a system goes down because of backup time during an upgrade, or recovering from a flooded data center, the business will be tick off, but receptive. This could be an opportunity to mandate standards of ECM organization and use.
Resources
If the work requests of the ECM system are back logged and the business is complaining, try pushing back an agenda of redesign and restructuring the content and information architecture. Too many customizations to a system could mean it's time to upgrade and apply standards that help integrations and interoperability.
Friday, May 28, 2010
Unbundling the silos within ECM
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.
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.
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…
Subscribe to:
Posts (Atom)