How many times have you seen or heard of an enterprise-wide ECM deployment dwindling to a halt after rolling out to a few business units? Anywhere between six to twelve months is spent on planning, architecture and design yet when it comes to the implementation and uptake the program loses momentum.

So where do they go wrong?

The answer is in a number of areas but more often than not, you will find fault in the strategy and the approach to the user base.

The “enterprise design” might be perfectly valid but are the business units ready for it in all its glory? Some will be (usually the ones rolled out to first, by happy co-incidence) and others won’t. Most of the company will actually understand the need for ECM. What they won’t be ready for is the complexity that an ECM solution can bring.

From a product perspective, let’s take WebTop as an example. WebTop is feature rich. You can perform every ECM based function through this UI so it is great for experienced ECM users but it can also be complex and confusing for ECM beginners.

In a word, it is about understanding “maturity”. Now we harken back to the strategy. Understanding the ECM maturity of the organisation is key to getting the deployment right.

The EMC IIG Services organisation uses the ECM Roadmap study to get the overall planning right. Amongst other things the Roadmap study plots a course for the ECM program, that over time (steps not leaps!), moves the customer from their current level of maturity to the level they require – their target state.

The focus of this post, the Enterprise Core Solution Framework (ECSF), is one of the “tools” that we use in this process. It helps address the maturity issue by supporting an initial “thin and wide” approach the ECM deployment.

Enter ECSF – A Core Solution Approach

ECSF or the Enterprise Core Solution Framework is an EMC IIG Services offering initially built on WebTop but now extended to provide a reusable set of business services available to any application interacting with the repository.  It embodies our services experience and best practices to provide a simplified end user ECM experience while at the same time giving business units the control to manage their business content.

The key principles of ECSF are:

1. Initially take a “Thin and Wide” approach
2. Devolved Information Governance
3. Enable Sharing of Information
4. Introduce Cross Functional Collaboration
5. Attack The Blockers to Document Management
   1. Metadata creation
   2. Access to working documents
   3. Transparency and simplicity
   4. Business Centric not Tool Centric
   5. Balance Standardisation & Flexibility

ECSF uses a business-layered architecture to support these principles. Business Services are used at the technology layer to ensure consistent use of the solution regardless of the interface being used. Business configurations are managed by key business and IT personnel to provide the rules and structures that are used within Business Applications. Business Applications are used by the business community to perform their content management functions.

The following diagram shows these layers:

That Sounds Great but What Does is Actually Do?

To explain what it does let’s look at the key pieces of functionality.

Roles

ECSF introduces a standard set of roles to help the business manage their content. These come in the form of folder and document roles, both of which are configurable.

Folder roles are used to manage folders:

• Members – users who can create documents in a working folder
• Guests – users who can browse and view documents in a working folder
• Business Authority – users who control working folder memberships and available document types in a working folder

Document roles are used to manage the document creation and approval processes. The default roles and privileges are:

• Authors -authors can edit or read a document whether it is in the “Draft”, “In Review”, “In Approval”, “Issued” or the “Historic” state
• Reviewers – reviewers can only edit or read a document when it is in the “In Review” state
• Approvers –  approvers can only edit or read a document when it is in the “In Approval” state
• Consumers – can read a document once it has been issued

Document types

Document Types are designed to hide the underlying object types from end-users, and simplify document creation, indexing, access control and general use throughout the document’s lifecycle. They are a configuration item within ECSF that represents logical classes of documents that are meaningful to the business (SOP, purchase order, annual report, project Charter, etc.).

A document type:

• Has a security profile
• Has one or more document templates
• Has an optional lifecycle
• May have a naming convention
• May have special attribute modifications / overrides
• May have additional versioning restrictions

Folder Types

Like Document Types, Folder types are a configuration item within ECSF that represent logical classes of folders that are meaningful to business (a contract folder, a project folder, etc.). Folder types can have templates, lifecycles, security profiles, naming conventions and attribute overrides.

Additionally, they can have a predefined structure (see Primed Folders below) and content rules that specify the document types, folder types and configuration object types that can be created within the folder.

Working folders are created from Folder Types and inherit the definitions from them. The Business Authority role manages the working folders.

Primed folders

Primed folders are like folder structure templates. They are pre-created structures and definitions that are used speed the creation of structure and standardise their use.

A great example would be a primed folder for projects. This would enforce the same subfolders, document types available under each and pre-create document templates within folders:

	Creating a folder from the ACME Project Structure folder type will mean that this  folder hierarchy will be created automatically
As well as the folder structure being created a skeleton Project Charter document has also been created

 

Attribute Inheritance and Attribute Management

Data entry during document creation or modification is one of the main blockers to adoption of ECM. ECSF includes the ability to inherit metadata to help in this area. Documents can inherit properties from not just the folders but also the folder hierarchy.

The Business Authority is able to specify whether attributes are to be mandatory, read only and/or hidden per folder/document type helping to enforce standards and compliance across an organisation or individually per business function.

They are also responsible for the maintaining pick list values, rather than relying on IT to make updates to these.

Creating and Managing Documents

Documents are created in the usual manner (Import, New document, Application Connectors, drag and drop, etc.) but three generic lifecycles are provided and are defined against document types:

• Standard – suitable for controlled document types
• Simple – suitable for uncontrolled document types
• Fixed – suitable for records (e.g. imported e-mails; scanned images; etc.)

The diagram below shows examples of each lifecycle type:

Retention and Archive

The final feature is some basic capabilities for retention and archiving. Support is added for additional document-level properties (review period, expiry period and disposition policy) and default settings can be inherited from the document template / folders (but can be overridden on a per-document basis).

Final Thoughts

I did focus on enterprise deployment here but it is worth pointing out that the “thin and wide” approach is perfectly legitimate with smaller implementations. It’s adopting the best practices message that is important.

Needless to say, we have learned a few things over the years with ECM implementations. As I mentioned earlier, ECSF does embody our best practices and field experiences. That’s why you may recognise some of these functions as things that you have customised in the past.

Hopefully this has given you a flavour for the main functionality the ECS framework delivers and how this can greatly improve the chances of success for your deployments.

deployment · ECSF · enterprise

I was reading the EMC Sponsored IDC 2011 Digital Universe Study, Extracting Value from Chaos that was published in late June and it’s very interesting stuff. For instance, did you know that in 2010 digital data created amounted to over 1 Zettabytes (ZB)?

I can almost hear people say ”how big is a Zettabyte?”

Well, A ZB is 1,000,000,000,000,000,000,000 bytes (or 10²¹ bytes) and in 2011 digital data is forecast to exceed 1.8ZB and grow by 50x over the next decade….

Much of this data is transient, it exists to serve a purpose and then disappears – I suppose in much the same way as spoken conversation, but stored data is still growing exponentially and over the coming years the smart organisations will see this captured data as a minefield of information, whether they are governments, financial institutions, healthcare providers or manufacturers.

The questions will be who will manage it, what will it be used for and where will this data come from?

Journey to the Cloud

Traditionally, stored data has been managed by the organisations that ‘own’ it but the report points out that although the cost of storage has plummeted dramatically since 2005, the investment per TB of data has risen steadily.

The report states that the amount of data is forecast to grow by 50x and the number of servers (physical and virtual) is likely to grow by 10x. Given this then the ‘Journey to the Cloud’ is looking more and more attractive, especially given that the number of IT professionals is only forecast to grow by 1.5x

More and more we will see organisation’s data being managed in ‘the Cloud’ and the recent cyber attacks by the now disbanded hacker group, Lulz Security will only make the journey more compelling as organisation realise that only cloud service providers have the resources to adequately secure private data.

Cloud Computing is now set to enable IT as a service. This includes in my particular sphere, Documentum as a Service as well as ‘Big Data’ as a Service, potentially with Documentum and Greenplum, jointly ‘piggybacking’ on the EMC Cloud initiatives to provide additional value added services to our customer.

Big Data and the Digital Shadow

Big Data plays very nicely into the scenario where content / data is being collected and stored all over the place and nothing has been done with it, Big Data changes all of that.

As IDC put it Big Data is not the created content nor is it the consumption. It is the analysis of all of the data surrounding it or swirling around it. The data that is created about individuals is growing at a much faster rate than the data created by individuals. IDC introduced the concept of the ‘digital shadow’ to describe this growth of data about individuals.

I personally find this an invasion of privacy but we all knowingly contribute to our digital shadow via the increasing use of social media etc. but governments and other organisations also collect more information, routinely, than is needed for the intended purpose. Much of this data is in the public domain but much is held within private repositories.

Big Data is about analysis – with so much content out there it is now possible to connect the dots.

By using fuzzy logic to analyse the myriad of data, from numerous sources and in numerous formats, it is now possible to make connections by analysing a huge data set and returning a set of results relatively quickly. The possibilities are endless, scanning all images on the web to look for certain facial characteristics, linking it with other data loosely attached to the images and to filter and form a subset of data for further analysis – this is where xCP could play a big part…

Where Documentum xCP is used for security purposes, such as linking case data to identify criminals, then the use of big data tools could be used to produce the initial data set for analysis and structuring by xCP.

It seems, therefore, that EMC has a really powerful message here. By offering Big Data, Content Management, Case Management and Cloud storage (and security) the foundations are laid for a quantum leap in extracting real value from content.

xCP

In the first post for this topic I covered a bit of the history of full-text index (see it here), what xPlore is bringing to the table and I introduced the migration options. This post will focus on the migration options and what is entailed in each.

I could have taken a leaf out of the Lawrence Maynard Book of Controversial Writing style but I think I’ll leave the Boat People out of this one….

Firstly, some quick facts about the migration:

• No additional license is required
• xPlore is compatible with Content Server 6.5 SP2 (with latest hot fixes) and above
• No client side upgrade required (5.3+ compatible)
• Zero downtime upgrades can be easily achieved

In the last post I listed the key migration options as Cold Swap, Straight Migration and Dual Mode. Let’s look at each in more detail.

A Cold Swap

By far, the simplest approach to migrating to xPlore is a straight technology swap. This approach is basically an installation of xPlore and having it create the indexes. FAST is turned off during this process.

It can be over the existing FAST hardware or on a new server but remember that if you reuse the FAST hardware you complicate your roll back option! The supported way of restoring a backup of FAST is to restore the application and the FIXML and then rebuild the indexes from the FIXML.

One of my main dislikes with FAST is that it has never supported restoring the binary indexes directly limiting both backup/restore and replication for Disaster Recovery.

So when would I go with the “Cold Swap” option?  When the repositories are small (and therefore index time is short) or an extended period of downtime for full text search is acceptable for your implementation. Remember that in extreme cases indexing could take weeks with FAST. While xPlore will perform better, that magnitude of data will still take a long time to full text index.

A Straight Migration

This twist on the migration theme uses additional hardware to run a parallel full text index but using xPlore:

New hardware is added to the infrastructure to house xPlore and an additional Index Agent. Both FAST and xPlore are running at the same time so the system is fully available while xPlore is doing its initial index build. At this point all searching is performed through FAST. The limitation is that only one set of indexing hardware can be used for searching at a given time.

Once the index build is finished the search is repointed to use xPlore. At this point FAST can be turned off and eventually decommissioned.

A system outage is required to repoint the searching from FAST to xPlore as the Content Server needs to be restarted after each switch. This typically would be about an hour but would vary depending on number of Content Servers, etc.

So when would I choose this option? When I had restrictions on the amount of downtime I could impose and I was in a budgetary/procurement position that allowed me to add additional indexing servers.

Dual Mode Indexing

This brings us to the last and perhaps most extreme of the options. Dual Mode indexing and search is similar to the “Straight Migration” configuration but also adds an additional content server and an additional WebTop server into the mix enabling both FAST and xPlore to be available on the same repository:

Both FAST and xPlore are performing full text indexing and both can be used to search (via the specific WebTop instance).

Users can be migrated over time between FAST and xPlore (again via the WebTop instances) with FAST being eventually decommissioned.

This approach is clearly the most costly but minimises migration risk and business disruption. It is most suited to those circumstances where ANY downtime of search and index is unacceptable to the user base.

Concluding note

This covers the key options for migrating from FAST to xPlore. Clearly more complicated infrastructures offer more possibilities and challenges. For example, a highly available FAST install may enable use of the second row (the second set of nodes for redundancy) to add xPlore with non-HA indexing being acceptable during the swap over. We have virtualisation options now, and so on.

If you are interested in some of these scenarios it might be time for a chat with your friendly EMC IIG Services professional……

xplore

There’s a chocolate fish in it for anyone who can tell me where the above line comes from…

Anyway, as you’ll know from my previous posts, EMC and Documentum are ‘betting the farm’ on Content Enabled Applications (Case Management) as the next wave in Content Management – this is a smart bet and many in the industry are seeing the same trend, take a look at the following blog post http://www.aiim.org/community/Discussions/xCP-and-EMC60s-big-Case-Management-Gamble

You’ll also get to take a look (by following the link) at some of the entrants for the xCP challenge.

We at Documentum World will also be running our own xCP challenge soon – whereby my team will build an xCP Proof of Concept for the best customer suggested case management application…

I’m confident that EMC won’t be ‘betting the farm’ on a ‘high card’ and I’d expect we’d be nearer to a ‘straight flush’ or at least a ‘full house’

With a bit of luck, we won’t even need that poker face..

 

xCP