The 2011 Momentum has reached its end. In 12 months from now, we’ll meet again in Vienna.

When we do meet in Vienna, the Documentum world will have changed. Documentum D7 and xCP 2.0 will be generally available. C6’s D2 (maybe even X3) will be the configurable alternative to Webtop. EMC OnDemand will be running for many months all over the world. Developers, partners, deliver vApp solutions to run in both the private and hybrid cloud. Next to it will be SharePoint and Office 2013. Both running on premise and in the cloud (Office 365 or otherwise).

Off course, still a lot can happen in between, but let’s assume that nothing does.

What are partners going to do with this knowledge? What will the customer do with this knowledge?

Will they change their way forward? Will they behave like any mother and father to-be, when they learn that they are pregnant of a beautiful baby in 9 months from now? Will they start preparing for the delivery of this new-born?

I think partners will. For successful partners, adopting to change is part of their DNA.

But what will the customer do? Will she change and if so how?
I believe she will. I believe she has to.

The ECM world is changing rapidly. The business never stopped changing. Competition continues to find ways to close gaps and take leads. Not less important, demands from new joiners in your company are rapidly changing. It’s nearing the point that you want to work with them rather than that they want to work for you.

However, how she’ll change will depend upon her current state related to her ECM vision and ambition.

Several scenarios are possible and include common scenarios like “Continue as is”, or “Technical ‘as-is’ upgrade”.

One particular scenario that could happen is the scenario what I would like to call “re-think & re-do”.

The “re-think & re-do” scenario is an appealing scenario. It can be a game changer. It applies lessons learned, leverages new functionality, and re-implements the requirements in the new target environment.

The soccer analogy of “re-think & re-do”

There is a great analogy to be made with sports. Especially team sports. Let’s take soccer.

Winning the National league, the European Champions League, and the World Cup for Teams are goals for the top teams. Many want it, few get it.

The easy road of buying 25 of the best players doesn’t get you there. Many tried, none succeeded(1).
Building a winning team is a carefully designed growth path that takes effort and time.

On this route, every now and then a player gets injured for a longer time, leading to adjustments in the process. Patches are applied.
Sometimes players get better offers elsewhere and new players have to be bought or incorporated from youth teams, the labs. Sort of a Service Pack is applied.
And then success is there. The team is on a winning streak.

After some time the successes diminish. Competing teams catch up. The common game-play changes. The players on the team are over the hill, nearing their sports technical end of life.
At this point the team manager has to make decisions.

A common decision is that they accept the absence on the prime stage for a year and rebuild the team from scratch.

Where in the previous period, patches and service packs have been used to continue, this time a new major release is needed.

You see this happening in many of the Olympic team-sports (field hockey, volleyball) in the post-Olympic year. The next World Championships are typically 2 years away, the next Olympics 4 years. Enough time to re-do the team and go for success at the next major event.

The good thing about building a new team, a new major release for future success, is that it allows the team manager to apply the lessons learned from the previews period (re-think) as well as to recover from unwanted side effects that come with patches and service packs (re-do).

The lessons learned can be in many different forms. As an example:

• The game-play may have shifted from physical to tactical and thus new requirements apply.
• The common positioning on the midfield may have changed from 3 players on one line to 4 that are positioned in a diamond shape. In essence the functional team design is changed.

Also the side effects come in different forms with examples like:

• Due to the absence of left-footed wingers, a right-footed player has become the left-winger.
• The youngster, replacing a player that has left, is not performing consistently.

Taking these lessons learned as well as side effects into account, a new design is created to succeed in future success and the new journey begins.

The EMC reality

The process illustrated above for soccer, can be applied to Enterprise Content Management solutions like Documentum. There too, patches and service packs are applied until you reach the point where you have to re-think what to do with a next major release.

Given the announced release of Documentum 7 / xCP 2, the adoption of C6’s D2 user interface, the availability of Documentum in the Cloud (OnDemand), and also the omnipresence of SharePoint fits, the point of re-think and re-do has arrived. The time is here and now. Too much is and will change to continue as if it’s still the same.

This is a far from easy task and is highly dependent on the unique settings of the customer.

It takes time. It takes careful considerations. It needs a free spirit to not limit yourself to budget, resource, calendar, or any other constraint yet. It takes guts in a budget constraint business to acknowledge that maybe with the new facilities, something better, cheaper, more flexible, and more future proof is possible and that now is the time to find out. It requires expertise to take it to the extreme on paper and see what it brings, to think out of the box.

Because even finding out requires budget, some arguments to help you build the business case are given below.

• EMC OnDemand

• Supported by certified professionals on behalf of EMC; No need to invest in company resources.
• Off premise in the cloud or locked down ‘all-in’ box on premise; No need to purchase hardware.
• Sizing for average load with on demand resource expansion to handle peak loads; no need to invest in hardware that can cope with peak loads that occur only once a week.
• Optimum module architecture through xMS, the requirement-based configuration descriptions that are used to generated the required virtual servers.

• SharePoint

• SharePoint is the users choice for collaboration and “work in progress” content management.
  Leverages the dominance of MS Office on the desktop and the user acceptance that comes with it.
• SharePoint doesn’t (yet) provide the appropriate means to cover all enterprise needs, but SDF⁽²⁾ is there to rescue. SDF, the SharePoint – Documentum Framework provides optimal bi-directional integration with Documentum to cover the enterprise needs.

• C6’s D2

• Reduce cost of customizations of Webtop by leveraging the configurable user interface that D2 delivers.
• Replace Webtop with a much more tailored and applicable interface for those users that need functionality that is not provided through SharePoint or xCP applications.
• Increase user acceptance with the appealing skinnable interface that D2 provides.

• Documentum D7 / xCP2

• Leverage the new deployment model that uses vApps.
• Leverage the ability to reverse patches if the outcome has unwanted side-effects
• Leverage the vast amount of documented functional patterns and solutions to build xCP applications.
• Leverage the growing number of xCelerators to reduce implementation time and effort.

• Non-technical

• Replace old school designs and include lessons learned of the current implementation.
• Start supporting the Knowledge Worker; Make it goal-driven and reduce the rigidness of traditional workflows.
• Prevent the typical chaos that uncontrolled, non-governed SharePoint environments tend to create.
• Take a controlled route towards the cloud by using on premise cloud technology.

Conclusion

I believe it’s here and now that you have the opportunity to re-think what your Documentum centric solutions add to your business and re-do them using Documentum & xCP through EMC OnDemand and integrate them with SharePoint through SDF.

If the signs are right, we’re expecting a beautiful baby somewhere in the late summer of 2012.
But, we have to work for that. It will not come easy.

The above mentioned arguments are not meant to be complete or generically applicable; further discussion is needed to incorporate the specifics of your organisation.
That first step is yours. I’m sure you can do it!

Ed Steenhoek
ECM Solution Principal

1. While writing this post, I was thinking about Manchester City. A soccer team where huge investments have been made in recent years but yet without success. However, after reviewing this post, it dawned to me that it is also applicable to Oracle. Oracle has been purchasing ECM technologies and companies but still doesn’t deliver a clear package that delivers success on its own – that is without cross selling from e.g. Siebel or the Oracle RDBMS – that matches the investments made.
2. Implementing SDF requires a specialism that is provided through EMC Professional Services or directly from selected partners. Informed Consulting is proud to be that partner for EMEA.

New blogpost @ #infcon on what to do with #MMTM11 knowledge on #Documentum, #D2 and #EMCOnDemand the comming 9 months. http://t.co/jJHSlpTp

7 November 2011 10:59 via EchofonReplyRetweetFavorite

@EdSteenhoek

Ed Steenhoek

Retweeted by @sinnema313, @keesvanbemmel, @Insidedctm and @SanderHendriks

RT @EdSteenhoek: New blogpost on what to do with #MMTM11 knowledge on #Documentum #D2 #EMCOnDemand the coming 9 months. http://t.co/e5bG0e7X

7 November 2011 21:16 via TweetDeckReplyRetweetFavorite

@macgirlsweden

Alexandra Larsson

Like the analogies - RT @EdSteenhoek @ #infcon on what to do with #MMTM11 knowledge on #Documentum, #D2 and #EMCOnDemand the coming 9 months

7 November 2011 23:05 via webReplyRetweetFavorite

@ecmguru

Johnny Gee

The Momentum 2011 Perspective on EMC Documentum in Q3/2012 - http://t.co/jFpP1jAU - Nice post from @edsteenhoek. Mind you I hope Citeh fail.

7 November 2011 23:52 via Tweet ButtonReplyRetweetFavorite

@leecsmith

leecsmith

RT @edsteenhoek. The Momentum 2011 Perspective on EMC Documentum in Q3/2012 http://t.co/6trMmhUx Good abstract of the event

8 November 2011 0:18 via webReplyRetweetFavorite

@luisfersang

Luis Fdez-Sanguino

#MMTM11 Perspective on Documentum in Q3/2012 http://t.co/XU3j5As8 Gr8 sports analogy esp. as applies to Oracle (see comments) #ecm

8 November 2011 20:16 via HootSuiteReplyRetweetFavorite

@JerrySilver

Jerry Silver

Retweeded by @PieWords

@leecsmith @edsteenhoek think you have both forgotten the FA cup. I think that counts as success! Good post otherwise.....

8 November 2011 21:24 via EchofonReplyRetweetFavorite

@mike_woodbridge

Mike Woodbridge

or any other

On a current project we’re integrating Documentum 6.5 and SharePoint 2010 through the EMC product EDRSMS 6.6, which is short for EMC Documentum Repository Services for Microsoft SharePoint. A mouthful, in the project we just call it Repository Services.

As part of the project, we’ve been educating the client project members on how this integration works. In this blog post, we’ll share some of that. That includes thoughts on how to make it work in a global implementation of SharePoint that is connected to a central instance of Documentum.

In itself that is not such a rare situation. Typically, the Documentum content server is implemented after careful considerations in a central location and additional measures can be taken to speed things up on the global hubs. One of them can be using Branch Office Caching Servers (BOCS). The problem is that BOCS can’t be used as part of the Repository Services solution. This doesn’t make sense in the typical usage scenario: SharePoint users work in and with SharePoint and somewhere down deep, data is not stored in a SharePoint Content Database (as part of the SQL server instance or cluster) but cached and partially forwarded into Documentum. More on this later.

With SharePoint the stories varies a little more. Some say it grows organically from a departmental implementation to corporate level. Some start with a central corporate instance and spin out to all regions. The stories about well thought designs on farms, site collections, and content types somehow don’t hit the surface that I see. Maybe I’m looking in the wrong direction. Then again, from talking to colleagues, project members and others in the Documentum-SharePoint playground, it appears as if this is an after-thought that is getting more and more attention. Well the point is that when you start using Repository Services, you better think beforehand!

Why do you have to think carefully about the SharePoint farms when using Repository Services?

Imagine that you need content from SharePoint that has been journaled (meaning: moved) into Documentum and is no longer directly available to SharePoint. Repository Services takes care of retrieving that content from Documentum and making it available to SharePoint. It does so by putting it in a temporary cache. This temporary cache is a location in the file system that only exists at farm level.

Meaning: for the whole farm, there is just one (1).

Now imagine a farm located in New York with also users in Sydney, Bangalore, London and Chicago. They probably don’t care since they’re on the global high performance network between these hubs. Imagine users in Wellington (NZ), Vancouver and Madrid. They might not be such happy users because their content needs to come from down town New York even if that content is only created and used by them.

Of course, more factors apply, but the key is: think about multiple farms when contents needs to travel around the global where users are only working on it in a single country or region.

Why do you have to think carefully about the SharePoint Site Collections when using Repository Services?

There are two simple reasons:

1. The current version of Repository Services is granular up the level of a Site Collection. This means that either a complete Site Collection is under control of Repository Services or not. The effect is that even if you only need the content of one single site to be journaled into Documentum, all content from the Site Collection is moved out of the SharePoint Content Database. The content that you don’t need to be journaled into Documentum is kept in the Performance Cache, a location in the file system.
2. There is only a single Performance Cache for each Site Collection

Again, imagine the global usage scenario as explained before. SharePoint allows you to have multiple Content Databases and with some careful tweaking, you can force a Site Collection to be stored in a particular Content Database. As part of a SQL Server cluster, you could bring the content near the user by creating regional Content Databases.

With Repository Services, the content is not stored in the regional Content Database but in the Performance Cache of the Site Collection, a location in the file system that can be anywhere on the globe.

The key is, that like creating multiple farms, you have to consider using multiple Site Collections and decide which sites – and thus which user population – becomes part of which Site Collection. Creating regional Site Collections, allows you to have a regional Performance Cache and keep the content as close to the user as possible.

Another key consideration: put content that can live on its own, and doesn’t need to be under control of repository Services, in a separate Site Collection.

This may have some implications on the user experience (user have to work with distinct Site Collections) but you also may not be too keen on large volumes of content in the Performance Cache that will never be journaled into Documentum.

It’s not a matter of right or wrong. It’s a matter of taking a well thought decision.

Why do you have to think carefully about the SharePoint content types

By definition (MSDN), a content type is a reusable collection of metadata (columns), workflow, behavior, and other settings for a category of items or documents in a Microsoft SharePoint Foundation 2010 list or document library. Content types enable you to manage the settings for a category of information in a centralized, reusable way.

When working with Repository Services, the metadata bit is what we’re looking for.

This may sound trivial, but way too often, modifications to a document library in SharePoint, are not based on the definition of content types. As part of good practice in Document Management, you first think about the information (attributes, properties, metadata – you name it) you need to know about content as part of your data model, before you think about how it is presented in your presentation layer, in this case a SharePoint document library.

Key is, to think from a document management mindset.

As said, with Repository Services, content is journaled into Documentum. This is done via Journaling rules. These rules select content based on… metadata values! So, even though all content of a Site Collection, is moved into the Performance Cache, only the content that is selected through a Journaling rule, is moved into Documentum. It goes without saying that the more metadata is available to select from, the more granular content can be selected for journaling.

Next to the actual content, a convenience copy of the metadata in XML format is also stored in Documentum. Although this is just a copy (changes are not propagated back into SharePoint), it can be used for further actions inside Documentum. Think of a scenario where you need to put content under Records Management. The basic metadata that resides as attributes on the Documentum doctype for this journaled content is limited and maybe not enough to make the proper RM decisions.

Key is to consider the usage of the content way beyond it has left SharePoint and reflect those requirements in the SharePoint content type.

In summary.

Using Repository Services to bridge the SharePoint and Documentum worlds can give you great user experience (SharePoint) and great document management (Documentum). It can also give you headaches if you forget about document management core values and information architecture design.

And if you have such a headache… there is aspirin available.

or any other

P04 has been released for the stack product versions:

• Documentum 6.6
• Documentum 6.5SP3
• Documentum 6.5SP2
• Documentum 6.5SP4 (For WebPublisher and Digital Asset Manager only)
• xPlore 1.0

This cumulative patch contains all approved Hot Fixes since the last patch release.

In general, patch releases are fully compatible with all other releases within the same version family. All platform combinations certified for base releases will be carried forward to Patch releases.

or any other

First gotcha:

Logon with the account you’ll be running your server with. Preferable not Administrator!

Immediately followed by the second gotcha:

Change the computer name to something unique.

Starting with the same base image results in multiple VMware images using the same computer name in the same network. That does not work.

Next a first tip:

Change the IP address to a fixed address.

Since the starting Windows 2003 server image uses DHCP to always get a free IP address, this needs to be fixed now. Changing the dynamically received IP address into a fixed address has proven to be successful so far.
Having a fixed address saves a lot of headaches afterwards when logging on over an RDP session.

Next double-checked the required software. Is Java installed? Is the .Net framework (version 2+) installed? They should be and are, but it has become a habit.

Next gotcha:

Make sure there are no spaces in the folder that contains the installer

Don’t know why EMC included this restriction in a Windows-only installer but they did.

Time to start the installer documentumSetup.exe. It will ask you for the password of your current account and allows you to specify some custom options or run with all password values in default.

Second tip:

Always go for a custom set of password values.

This allows you to specify custom passwords for many things. Most likely you will never need them.
But if you do, now you know them . Although this is not backed with evidence, there is that generic fear that someday you need it.

About 15 minutes later you’ve installed a developer Content Server, WebTop, DA, Retention Policy Services Admin. And of course, Composer is there as well.

Before doing anything else it is time for disaster prevention: shut-down and backup the image. Since reproducing this image is a matter of minutes rather than days, one zip file stored on the server and one on backup storage will do.
Only when this has been completed successfully, next steps like installing WebPublisher or DAM, can be started.

But before we do, we bookmark two additional URL’s that are part of a default Developer Edition Install.
JBoss comes with an administration console at http://localhost:9080/web-console/ and a JMX management console at http://localhost:9080/jmx-console/.  They both use the default ‘admin’ user to gain access. The password is a little bit more tricky…

A final gotcha:

If you changed the password according to my second tip, the admin password for JBoss is that password.

If you did not use custom passwords, the password is the one documented in the installation guide.

or any other

The platform is a wrapper around a set of existing Documentum modules and used to be called the Case Management Framework. The latter is however ‘just’ a solution build on top of the platform.

One of the ‘assets’ of the platform is a one-click installer for the Windows OS. In this article, I will discuss their asset in more depth because it has potential, lacks still many things but foremost can be a quality impulse to core Documentum.

There is analogy with the Documentum Developer Edition. Also a one-click installer. It delivers a Content Server with Webtop, the Administrator and Retention Policy Services. If you need more, like I needed WebPublisher and PageBuilder, you have to add that yourself  This requires unpacking the wp.war file, changing some properties, copying the unpacked war to the application server (because – according to the documentation – available hot-deployment of the re-packed wp.war just didn’t take off) and restarting the application server.

It also includes the execution of a WebPublisher server components installer.

The configuration of the one-click installer for the developer edition can be enhanced to also install an additional DocApp or DAR, Unfortunately adding an additional war file is not included. Anyway, I had to read to several documents to get to a working development edition including WebPublisher.

The question that comes to mind is: Can the one-click installer be enhanced with out-of-the-box the (optional) installation of modules (like WP, DAM, BPS/TaskSpace or Records Manager) in order to create a win-win situation from development up to production?

The win on Documentum side comes from them being the one to decide on how the modules are to be configured for installation By doing so they create a solid base that will reduce their support effort significantly. If someone should know how the Documentum modules must be installed in order to work together, it’s EMC. Also, from sales perspective this is a benefit.

If you’re in the Documentum business you probably can share horror stories of errors in the base configuration that caused instability and ghost incidents.

This is what can be avoided with a one-click installer.

The win for the customer comes from both reduced maintenance effort as well as increased stability. Also a reduced time to market comes to mind but also reproducibility of the installation over multiple environments.

Today the one-click installer is not at that point but it can get there with some enhancements. The major enhancements that are needed are:

• include all available modules as options
• include the ability to install against an existing RDBMS
• include the ability to install against an existing application server for the clients
• include the ability to install on any supported operating system
• include the ability to install multiple consent servers
• include the ability to re-run the installer to at least add modules in war or dar format.

None of these are impossible. They do take some testing once the brain-work has been done.

It must be understood that this will exclude some rare but possible mixtures. For those manual adoption must be possible against the price of “being on your own” or the price of a consulting effort. Ideally this would show in the maintenance fee.

Once we’ve reached this milestone, it becomes a small step towards a full install of all modules and unlocking functionality by supplying license keys. A model used by Adobe on their LiveCycle platform with success. Those of you familiar with installing new applications into a controlled production environment know that having all modules already installed, saves a huge amount of time. Time that can be used to be faster to market. Combine that with the speed of solution delivery on the xCP platform and the customer will have a noticeable shorter IT cycle compared to traditional Documentum projects.

Bottom line: If only EMC would enhance the one-click installer into a full product installation, it would make customers and partners more than happy!

Today both the one-click installer for developers as well as xCP are good enough for development, PoC’s or demonstrations. For installations into test, acceptance and production environments or on non-Windows, they are not yet suited.

or any other