WCM to WCS Migration

Times are a changin’• Today’s Web is not the Web of 2005.

• Web sites are built differently• Web Content is “authored” differently• Web sites are assembled by a team made up

of diverse skills

• There are many Web Content Use cases where the AVM provides no advantage over the Core Repository.

• The Core Repository has gotten the lions share of attention over the past few years.

• Many of the compelling features of the AVM have been added to the Core Repository.

• As of Alfresco 4.0 the AVM is being deprecated.

Document Management

Records Management

Web Content Services

Enterprise Collaboration

Open Source Platform

A Fundamental Shift

Alfresco is an Enterprise Content Management System….

Web Content is enterprise content.

Web Content Services provides a means for making content available on the web in a scalable fashion.

Do I have to change?• Option 1: Continue with the Status Quo

• If you are running Alfresco 3.x and using the AVM, your solution will continue to be supported until Alfresco 5 is released.

• Option 2: Upgrade to Alfresco Enterprise 4, and continue using AVM• If you are an existing Alfresco Enterprise AVM customer, you may upgrade to

Alfresco Enterprise 4 and you will continue to be supported with AVM until Alfresco 6 is released.

• Option 3: Upgrade to Alfresco Enterprise 4 and switch to the core repository with one of our Web Content Services approaches

You can only delay change for so long. Plan now to minimize the downside and take full advantage of the upside.

What are Web Content Services?Supporting a diverse set of web content use cases

• Alfresco’s Web Content Services are a set of open content services that deliver web-ready content to today’s content-rich web applications, portals and social media sites

• Alfresco Web Content Services are built on the three following components• A Core Alfresco Repository (Authoring Tier) that handles process, workflow,

record keeping, auditing, transformations and the content creation process.• A CMIS Compatible web tier repository, suited to dynamically deliver content to any

web tier framework (e.g. Drupal, Liferay, CrafterRivet or your own custom App.

• File System Transfer Receiver that delivers static assets.

• These three components are connected via Transfer Services.

Differences Between our WCS and WCM implementations• The AVM provides three features that have no equivalent in the

Core Repository• Sandboxes• Multi Asset Versioning• Snapshots and Roll Back.

• The Core Repository has a number of features that are not available in the AVM• Support for Rules• More sophisticated Access Control• CMIS Support• More complete functionality in a number of area including search,

workflow, APIs, modeling, metadata extraction and content transformation.

Impact of the WCM and WCS differences• The WCS web tier has all of the functionality that is

available in the WCM web tier.• The additional and expanded features in the DM based

authoring tier should provide improvements for content authors.

• The features that are not available in the Core Repository are useful for a small and shrinking set of use cases.

Characteristics of Sites that the AVM was designed for.• Sites that were versioned and released for deployment as a

complete unit.• Sites where page changes included a large number of

assets whose changes needed to be grouped together.• Sites that deploy code (theming or operational) and content

together.Sites that have these characteristics will need to be reviewed

soon to determine the path forward.

Characteristics of Emerging Use Cases

• Content items have fewer interdependencies.• Content on the same site may come from different sources.• Content may be targeted to multiple sources.• Content may appear on the web as a small part of a larger

lifecycle.These characteristics to not require the deprecated WCM

features.

So is there Life After the AVM?

Yes….. But….

Projects with a heavy dependency on the AVM will need to be re-engineered, re-architected and will undergo process

change.

Projects that naturally lend themselves to Web Content Services will still need a fair amount of renovation.

There will be benefits but they do not come for free

Some examples of Issues to contend with• The content modeling is different.• The user interface uses a different framework• Deployment tools are different

The Problem with the old Web Forms

• Web Forms defined the UI and the Content model together.

• The constraint validation is done at the UI layer and not at

the Repo layer.• This makes it difficult to validate ingested content

• Similar to the way many lighter weight CMSs approach

creating types – easy for quick definition of a content type

and it’s capture form.

• Low entry threshold, inflexible to go beyond what this is

initially designed for.

Conversion Example Content Model<?xml version="1.0"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema” xmlns:trn="http://www.alfresco.org/training" xmlns:alf="http://www.alfresco.org" targetNamespace="http://www.alfresco.org/training" elementFormDefault="qualified">

<xs:element name="article"><xs:complexType><xs:sequence><xs:element name="title" type="xs:normalizedString" /><xs:element name="teaser" type="xs:normalizedString" /><xs:element name="publish_date" type="xs:date" minOccurs="0" /><xs:element name="is_feature" type="xs:boolean” minOccurs="0" /><xs:element name="body" type="xs:string" /><xs:element name="related_links" minOccurs="0" maxOccurs="10"><xs:complexType><xs:sequence> <xs:element name="link_text" type="xs:normalizedString" /> <xs:element name="link" type="xs:anyURI" /></xs:sequence></xs:complexType></xs:element></xs:sequence></xs:complexType></xs:element>

</xs:schema>

XSD to Content Model• DM can model anything that the XSD can model

• Cardinality can be handled with required and multiple and perhaps a constraint where needed.

• Inter-content relationships can be handled with nodeRefs (versioned) or Relationships (not versioned).

• Complex Metadata Types can be an issue.• Bundle the value in a serialized version of the composite property• Have a set of parallel multi-valued properties.• Use child objects• Altering the Data Dictionary to support proper composite properties

is quite ambitious• Unified Modeling Scheme for all content

• Rather than XSD which was not designed to content modeling, we have a modeling language that is tailored to the Repository.

Web Form XSD to Forms SDK

• Like the Web Form XSD, the Share based Forms will pick reasonable default UI components for a piece of content

• Both have OOTB Widgets• Both allow for custom widgets

• Web Forms uses Dojo• Forms SDK uses YUI

• Developers can also use widgets in UIs build on other Frameworks.• The Repository enforces data integrity with constraints and what not• Developers can write Helper webscripts to populate pickers and

select lists

Changes in Deployment

• The deployment tools are similar.• But….. there are some differences• If you have extended any of the deployment tools you will

need to revisit some of the code.

This is a non Trivial Migration

• Risk vs Reward• There is a definite cost to conversion• There are benefits in performance, clarity of development process,

flexibility.• High Level Generic Conversion Process

• Assessment and Vision• Brainstorming/White Boarding/Protoyping/POC/Enablement• Develop Credible Plan• Execute

• Partner Products• Lot’s of opportunities to solve problems based upon use cases• Some partners already have solutions based upon their experience• Opportunity for Alfresco/Partner collaboration here.

High Level Generic Conversion Process

Walking Through the process

Assessment and Vision• Analysis of the current use case.

• Does the current process work?• Are there improvements that can be made• Are there features that are left out that will hinder adoption• Is this important enough to renovate?• Can this be absorbed into another process?• Should this be completely re-engineered

• Build a Technical Inventory of things that need conversion• forms • models • ui widgets • transformations • workflows • deployment schemes

• Usability Analysis • Distinct Roles/User profiles • Key "cannot live without" features• Processes that could be streamlined

Brainstorming and White Boarding

• Familiarizing the Project on the conversion process (as it relates to Alfresco)

• Have a whiteboading/brainstorming session• Discuss competing strategies• Talk about potentially expensive tasks• Bucket features into (Must, Should, Can, Won’t)• Talk about Actors• Re-engineering Opptys.

Prototyping and Enablement

• Identify a representative set of items that could be done quickly and represent go/no go items

• Identify items that will allow the development team to gain some insights in to the process.

Develop Credible Plan

•Review the lessons learned in the prototyping session.

•Understand the areas of technical risk.

•Talk to the stake holders.

•Discuss any changes that the business users might incur

•Identify the resources that will be needed

•Consider getting help from a partner or consulting.

Execute

• Armed with a well thought out plan, you will be prepared to execute.

• Plans notwithstanding, you will most likely be in uncharted waters.

• Don’t be surprised if there are bumps in the road.

Conclusions

• Moving to Web Content Services will become necessary at some point

• In general there is much to gain from the process• It is a non trivial process• Be prepared to commit resources to it.