If you have ever had a position in IT where there was a “dotted” line in your responsibility to another group, you’ve worked for embedded IT. If you have developed an application on your desktop to support your team, you have been embedded IT.
CIO’s always want to centralize most of embedded IT to achieve the cost savings of common services, infrastructure, and architecture. I’ve been embedded and centralized, both of which have their faults.
Here are some aspects of embedded IT that could be potentially missing from a centralized model:
Well understood business requirements: ability to read between the lines
Trust in your teammate’s ability to deliver
Efficiency of work and play is a given
Hard work is observed and appreciated by the business
Governance is organized and strong: no dotted lines needed
Content is fully described to suit the project at hand
Sneaker net workflow works well
Here are some aspects of centralized IT that could be potentially missing from an embedded model:
Automated workflow
Consistent metadata and values which describe content
Governance which is tuned into the goals of IT as a whole
Consolidation and sharing of duplicated services
Lack of trust in your teammate’s ability to deliver on a project due to being spread thin
Business requirements that are read literally
Friday, September 17, 2010
Monday, September 13, 2010
Creative Destruction of SharePoint
SharePoint is trying to transform, or split up ECM into pieces, similar to what Schumpeter referred to as “creative destruction”. Schumpeter’s use of this term implies that in order to have innovation the current paradigm has to be superseded.
What aspects of ECM will be crushed in order for SharePoint to innovate? Will ECM actually be destroyed? I have doubts. The main “innovations” of SharePoint over ECM software are based on shortcomings of the software suites, not the solutions or platforms. SharePoint is not as much innovation as it is a fix to chronic ECM problems:
What aspects of ECM will be crushed in order for SharePoint to innovate? Will ECM actually be destroyed? I have doubts. The main “innovations” of SharePoint over ECM software are based on shortcomings of the software suites, not the solutions or platforms. SharePoint is not as much innovation as it is a fix to chronic ECM problems:
- A more unified architecture, as opposed to the patch work of typical ECM suites
- Easier to configure and build sites from templates (unless you have to customize, which is most of the time)
- Ease of Use: by definition SharePoint is easier to learn and use, unless your thousands of users already use another software suite.
- Already in the house as an OS and email system, thus foundationally integrated, which is the key business driver for Microsoft-based systems.
- Less expensive, in the short run, but the long run expenses will depend upon reducing the need for customizations and traditional library management services.
ECM suites will have to develop and innovate on their strengths, which in some cases are slowness to change with the times. Most small mistakes made in implementing content management systems were made on a continuing basis for cost and lack of direction reasons, not because of the obvious flaws in the software. The market of ECM has created the dinosaurs of ECM suites, not the other way around. All large enterprises, which own the largest amount of licenses, can not and will not move at social media speeds.
Social media has many more iterations to go through in order to develop the depth of ECM requirements. SharePoint will run in parallel of the ECM suites for some time to come, maybe nibbling off bits of functionality and previous integrations. In the mean time, ECM will hopefully rewrite their core software to be more open source and model their applications and added value on innovations rather than bandaids.
Litigation Response as Wedge in IT Issues
Let’s say you have litigation response that the legal department has mandated. It becomes clear that the overall cost to outsource the discovery of self-organized content repositories with limited metadata and historical changes in metadata values, let alone file shares and email, is staggering.
The Legal Hold project revealed issues in many other areas of the company, namely that there was no central data management architecture, records management was not automated enough, and central governance of the embedded IT groups was ineffectual.
In this case, the Early Case Assessment was controlled by outsourced personnel instead of an automated tool. The mandate acted as a wedge that opened up the heart of the issues that almost every enterprise has to some degree: namely the lack of coherent standards which span all applications and are well understood and governed.
The Legal Hold project revealed issues in many other areas of the company, namely that there was no central data management architecture, records management was not automated enough, and central governance of the embedded IT groups was ineffectual.
In this case, the Early Case Assessment was controlled by outsourced personnel instead of an automated tool. The mandate acted as a wedge that opened up the heart of the issues that almost every enterprise has to some degree: namely the lack of coherent standards which span all applications and are well understood and governed.
Tuesday, August 31, 2010
Floodlight vs. Spotlight in eDiscovery Solutions
Floodlight
I had the privilege to be entertained and enlightened by a few recent demonstrations by leading eDiscovery/Legal Hold software vendors. After listening and looking at smoke and mirrors, each vendor revealed that their core competency still remains their strength and eDiscovery is an extension or add-on rather than a full fledged solution. The “floodlight” approach of these vendors to eDiscovery was not achievable given the current state of the offerings.
A true eDiscovery/Legal Hold vendor has yet to emerge. The add-on vendors flooded the market by buying the pure plays, but couldn’t have imagined the difficulties of integration that these add-ons have created. The issues behind efficient eDiscovery are squarely in the business’s camp and not in IT. Not one of the vendors mentioned the integral importance of common and historical metadata management. If the doc is not described well enough, good luck discovering it. If Record Management is not fully functionally incorporated into the business daily routine, docs will not be disposed of according to compliance mandates.
Search Vendor
Core: Index and Search Results
Platform: Most
Hold: Export out of repository to file system
Vision: Nice long-term story if affordable
Agent: stealth/regular desktop agents
Connectors: Most applications with varying levels of customization needed
Index: Best in class, but dependent on the source content's metadata accuracy
Collection: Kind of fuzzy given that the exports from repository are done without built in abilities to validate source content accuracy, ie. ways to test discrepancies.
Forensic Vendor
Core: chain of custody of collection
Platform: Windows
Hold: Office docs on file system by using extra control files for tracking
Vision: Deal with Windows file system content
Agent: no client agent
Connectors: Windows and SQL
Index: Dependent on other’s indexing
Collection: Searching and collecting are secondary to browsing and selection.
ECM Vendor
Core: Workflow, doc lifecycle, storage management
Platform: Most
Hold: Export out of repository to file system with xml metadata file. This potential removes the source context, auditing, and access control information from exported content. What about a hold inside the repository?
Vision: Partner with eDiscovery solutions and let them deal with the issues.
Agent: stealth/regular desktop agents
Connectors: Many, but disappointing connector to own system
Index: Does not compare to robust search engine eDiscovery product
Collection: Built-in export is marginal out-of-the-box and third party tools need customization for legal department export and metadata requirements.
Spotlight
When will eDiscovery solution providers design the foundation of their offerings around metadata/records management prerequisites and controlling the chain of custody? Of course this is not easy for any enterprise to achieve, but focusing a “spotlight” on specific areas and building the solution each area at a time will get this done. This “spotlight” approach will force the business unit that is most motivated to solve their organizational issues around RM and metadata. The policies and procedures can be created after the first spotlight is finished. Subsequent spotlights will be dependent on the quality of governance and policies in place.
The spotlight approach would show the strength of pure play solutions over floodlight enterprise solutions. The forensic vendor would shine when testing Windows file system content only which would be a bad start. The holy grail of all of these solutions is the ability to introduce a layer (like RM solutions) where the intelligence gained by indexing, searching, and collecting could be written back on the content for better future classifications and entrance to the semantic qualities of future systems.
I had the privilege to be entertained and enlightened by a few recent demonstrations by leading eDiscovery/Legal Hold software vendors. After listening and looking at smoke and mirrors, each vendor revealed that their core competency still remains their strength and eDiscovery is an extension or add-on rather than a full fledged solution. The “floodlight” approach of these vendors to eDiscovery was not achievable given the current state of the offerings.
A true eDiscovery/Legal Hold vendor has yet to emerge. The add-on vendors flooded the market by buying the pure plays, but couldn’t have imagined the difficulties of integration that these add-ons have created. The issues behind efficient eDiscovery are squarely in the business’s camp and not in IT. Not one of the vendors mentioned the integral importance of common and historical metadata management. If the doc is not described well enough, good luck discovering it. If Record Management is not fully functionally incorporated into the business daily routine, docs will not be disposed of according to compliance mandates.
Search Vendor
Core: Index and Search Results
Platform: Most
Hold: Export out of repository to file system
Vision: Nice long-term story if affordable
Agent: stealth/regular desktop agents
Connectors: Most applications with varying levels of customization needed
Index: Best in class, but dependent on the source content's metadata accuracy
Collection: Kind of fuzzy given that the exports from repository are done without built in abilities to validate source content accuracy, ie. ways to test discrepancies.
Forensic Vendor
Core: chain of custody of collection
Platform: Windows
Hold: Office docs on file system by using extra control files for tracking
Vision: Deal with Windows file system content
Agent: no client agent
Connectors: Windows and SQL
Index: Dependent on other’s indexing
Collection: Searching and collecting are secondary to browsing and selection.
ECM Vendor
Core: Workflow, doc lifecycle, storage management
Platform: Most
Hold: Export out of repository to file system with xml metadata file. This potential removes the source context, auditing, and access control information from exported content. What about a hold inside the repository?
Vision: Partner with eDiscovery solutions and let them deal with the issues.
Agent: stealth/regular desktop agents
Connectors: Many, but disappointing connector to own system
Index: Does not compare to robust search engine eDiscovery product
Collection: Built-in export is marginal out-of-the-box and third party tools need customization for legal department export and metadata requirements.
Spotlight
When will eDiscovery solution providers design the foundation of their offerings around metadata/records management prerequisites and controlling the chain of custody? Of course this is not easy for any enterprise to achieve, but focusing a “spotlight” on specific areas and building the solution each area at a time will get this done. This “spotlight” approach will force the business unit that is most motivated to solve their organizational issues around RM and metadata. The policies and procedures can be created after the first spotlight is finished. Subsequent spotlights will be dependent on the quality of governance and policies in place.
The spotlight approach would show the strength of pure play solutions over floodlight enterprise solutions. The forensic vendor would shine when testing Windows file system content only which would be a bad start. The holy grail of all of these solutions is the ability to introduce a layer (like RM solutions) where the intelligence gained by indexing, searching, and collecting could be written back on the content for better future classifications and entrance to the semantic qualities of future systems.
Saturday, July 10, 2010
Single Point of Failure
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?
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?
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.
Subscribe to:
Posts (Atom)