Posts Tagged ‘Documentum’

#MMTM16: Case management: The good, the bad and the ugly

April 27th, 2016 Comments off

People who have read my previous blogs know I have a soft spot for xCP and case management according to Documentum. The past months I have wondered why this is.

The first and easy answer is the fact that probably more that 70% of the solutions I personally have implemented for my clients, where some sort of case management implementation. The next question I asked myself was: What do you mean: case management? It was all document management! What makes it different from the other solutions? Thinking more and more about that question made it clearer where my soft spot comes from. IMG_0797_small

People who work with me will confirm: I am a bit more than a little chaotic. To be able to function it is mandatory for me, to have an easy high level overview of all the stuff that is hanging somewhere on my to-do list. Case management is (in my eyes) exactly that functionality. Give every knowledge worker their own dashboard, with what is important for them at that point in time. And what I see in my day to day encounters with end users is that demand, that thirst, for that overview from every knowledge worker.

IMG_0820_smallIt is never about one document only. It is always about a group of information items that have, at this specific point in time, a relation with each other and this relation has a certain current status, that makes it important to show to me (a knowledge worker) right now. I need to be able to drill down to the specific pieces of information and change all pieces at once, separate or in combinations. This has to do with the fact that most (but not all) knowledge workers don’t work on one large document, but on a lot of separate pieces of information that need to be handled quickly. When you are part of the quality authors of a life sciences company or managing all assets of a large power-plant (my other 30% of the solutions I implemented), having a real document centric management system, that has the focus on that specific document and its related documents, is very important and demands an EDMS like D2. All the rest of us need xCP.

In my experience, all other types of document management systems will have way more to do with case management than with real, pure document centric management: Working on pieces of information that have some sort of relation with each other during their existence.

Case management is all about a good dashboard that shows you the right information for the task/action you want to perform.

Hand drawing Content flow chart on transparent wipe board.

With TaskSpace, Documentum took the first leap into the real case management world and showed that it is way better to have a Case Management solution that is built on the foundation of an ECM system than a Case Management system solely based on a relation database. This first go at a case management solution was good, but lacked a good and consistent developing environment and a flexible and very user friendly interface. (Beside some annoying bugs in the core)

And then came xCP2. The idea is so simple, but so great that I really jumped with excitement when I found this. This is really the vision we all were hoping for from EMC-ECD (IIG at that time). This is the good in my story. The product team, who came up with this approach, should be decorated :-). Sure, the 2.0 version was far from perfect, it had too much issues and lacked some functionality to make easy deployment and testing possible, but it was clear that this is the direction that Case Management needs to go.

With the new version coming up, and the change in deployment strategy, ECD is taking the right approach to make this a very stable and easy to implement system.

IMG_0821_smallBut there is still a bad. This has to do with the fundament of information classification and the way Documentum is structured. It is easy to create a great app in xCP Designer and to make the perfect dashboard and underlying supporting pages. It is relative easy to make a workable deployment strategy to deploy new features and solve bugs without too much interference for end users. But once in production with the number of cases growing rapidly, that great dashboard becomes slow, slower, the slowest… At first, you have happy end users, who love the possibilities of designing their interface together, and the flexibility and modern look and feel you can give them. Suddenly, after a couple of months their comments are a bit more cold and distant. In the end, the solution is still good and they are happy, but you feel that the performance of their first and main screen is getting annoying.

So my hope when it comes to xCP and Momentum 2016 is that the new product team of xCP has put a lot of thought and effort in the performance improvement of the historical queries in xCP. Challenge Jeroen van Rotterdam and his baby xPlore (xDB) to make those queries super-fast. A whole xCP solution is as good as the main dashboard!!

Digital TransformationAnd then came the ugly. Don’t be alarmed ECD, this time it is nothing you need to change :-). The ugly is all about the fight between the top 5 big IT companies who like to annoy each other by downgrading the support for the others fundament. It started with Apple who did not like Microsoft Silverlight or Adobe’s Flash. The arrogance to just not support it, shows how big their ego is. But that was only the beginning. Now a lot of browser-companies don’t like Oracle and push to the limits to make the use of Java in your back-end web-application difficult or even impossible (Chrome). And last but not least Microsoft, who is doing so great in trying to be friends with everybody now that Nadella is behind the steering-wheel, still needs to show the strength to the others. JavaScript is the most common used front-end languages to create a dynamic webpage. It is the new standard for web development and the only easy way to fulfil the UX demands of the new user. But why should that be of any concern to Microsoft or Mozilla? Sure it is easy to shout about security issues and all, but in the end it is just budget that makes it not possible to make JavaScript run very fast. To see the difference in performance of an xCP application between IE10 and Firefox and Chrome is frightening. Even the new Microsoft Edge is still lacking compared to the others and we see no improvement in JavaScript speed in the new versions of Firefox. So the ugly is only something we can hope will improve but is for sure a challenge we consultants need to be aware of when implementing the next great Case Management solution in xCP.

EMC Elect is getting ready for EMCW-Momentum 2015

April 25th, 2015 Comments off

It is less than 10 days until I fly to Vegas again. Ready for a week of knowledge sharing and showing the world the wonders of SPA4D and LoBConnect. It will be different from the previous years. A number of reasons:

1) We have two very cool products. We see how happy our customers are already reacting to them, but are excited how the Momentum crowd will respond.

2) I cannot wait to finally see a glimpse of all the new things of ECD: What will the new Capital Projects UI look like? Is the 3th gen platform getting the traction it deserves? Is LSQM ready for the next step and will the multi tenant solution for Life Science be a good competitor for Veeva? What about xCP and a rules engine? D2 and xCP, you see they are more and more growing to each other, but when will they become one, now or never or anything in between?

3) Being EMC Elect. I don’t know if anything will be different, but I feel obligated to write a blog per day to give my ideas and thoughts.

Please drop by our booth and share your thoughts. I’m always in for a good discussion.

What you tell me in Vegas, might end up in my blog 🙂

Social Welfare at the ECM Workplace

January 19th, 2015 Comments off

A few months ago, Linda gave birth to her son Luca. Linda is the wife of Stephan, a colleague of mine. Curious as he is, Luca was premature when he decided that it was time to see the light of day. That by itself wasn’t any problem at all. The world was ready for him.

The birth of Luca triggered me to share a story that I tell my customers in the early days of a document management project. By now you are wondering why the birth of Luca trigger this story.

Here in the Netherlands, we have a social welfare system in place that kicks in at the early days of a pregnancy. Not only is the health of both mother and her child monitored, but the system also ensures a safe home is in place for the new born. It may sound overanxious, but one of the checks they do is to see if you have a cradle for the baby. That same social welfare system functions as a lifeline throughout your entire life until you shall come to your grave in ripe old age.

That lifeline provides the guidance, the procedures, the policies and the actions to fall back upon during your life. It’s the blueprint of the minimal life. You can still live your live to the max the way you want it, as long as you don’t underperform and drop below the minimum that the lifeline provides. It also takes into account the stages that you pass in your life. You may become a parent yourself, which gives you access to child support. You may develop a partial disability to work, which provides access to special compensation benefits. And even a basic pension is provided when you reach the age of 65+.

For us humans, the Social Welfare system provides the lower limit blueprint of our life from Cradle to Grave.

If you’ve read my previous post (Diversity at the ECM Workplace) about Connecting People to the Enterprise, you will understand that bringing and keeping your users on board requires an ECM solution that is easy to use but still honours the enterprise needs. One aspect that you need to facilitate is what I call the Social Welfare for the ECM Workplace.

Cradle to Grave is the concept that implements core information management functions, which become a lifeline throughout the entire life of your documents.

If I create a new document, the system needs to be ready for that. It needs to support the cradle. This can be done if the lifeline supports me with e.g. content types, templates, managed metadata and rule-based storage. In these early days in the life of the document, it needs the lifeline to understand whether it is going to be a contract based on the English language template. We stick more labels on the document to classify it and together that allows a document management solution to decide where the cradle should be located.

That lifeline also provides the guidance, the procedures, the policies and the actions to fall back upon during the life of the document. It will pass stages depending on the life it lives. In the infant stages you’ll see typical states like draft, and for review. In the adolescent stage the document will go up for approval, and get approved. While the document matures, it can use the supporting processes to move between these states and stages. At some point in time it might become a reference document to others which alters the access permissions as well as its information classification. Some documents will move from classified to unclassified, from internal use only to publicly available.

Like all of us, there comes a time when also the document will retire. It will be withdrawn from active service but is still available in some archived format with again changed access permissions and information classification. It may also move into a new storage location.

For managed information, laws, rules and regulations determine the length of the pension. There is no fixed rule for this, just like nobody knows how many years one is given to enjoy the old age. The harsh reality is, that it won’t last for ever. For managed information the grave implies that the information is deleted from the ECM solution or moved from the system to preserve its historical value elsewhere.

Depending on your requirements and circumstances, you determine what that lower limit is and which ‘social benefits’ you provide your users.
For managed information, Social Welfare for the ECM Workplace provides the lower limit blueprint of the life of that information from Cradle to Grave.

So, why did the birth of Luca trigger this? Because of the parallel between the Dutch Social Welfare System and the Cradle to Grave. You don’t want a fixed path for your newly born and nor should it be a one-off approach for your documents if you want to keep your users connected with your enterprise needs. But the opposite is also true. You don’t want uncontrolled chaos in both situations. It should be predictable and acknowledging that new documents get created and deleted and need to be managed in between. From Cradle to Grave.

Like the concepts of Diversity and Cradle to Grave matches perfectly in real life, as do they match perfectly in our ECM world. Take a look at if you want to learn more about how we can help connect SharePoint collaboration functionality to the enterprise control of Documentum. Or watch our blog for more articles on enterprise information management.

Diversity at the ECM Workplace

November 10th, 2014 Comments off

Just the other day I was driving home from the office reflecting back at events that happened in the last few days and weeks. As always driving home is one of those precious moments where I can sit back and reflect. Sitting in the car in traffic, it finally dawned to me.

For a couple of days already I was trying to put finger on something that bothered me. I had been working on multiple engagements over the last few weeks. Some only related to EMC Documentum. Some only to Microsoft SharePoint and some included both. All were in different industries. If you wouldn’t know better, there was nothing they had in common. But there was.
Read more…

EMC World-Momentum 2014 – The final view

May 15th, 2014 Comments off

Sitting in a plane going back home after four long days of bathing in the Documentum information, discussion and fun I’m ready to make up a final view of the vision of the IIG team the challenges and opportunitees I see and whatever more was there.

First of, I have to thank the EMC and IIG marketing teams for organizing a very good venue. Overall all went more than smooze and only getting in and out of ballroom A with 12.000 people demanded a little patience. The party at TAO and the Imaging Dragons are not easily forgotten.

The fact that (almost) all sessions for us Documentum geeks were on one level, the perfectly located Momentum lounge in the middle and the seperated area in the solution pavilon made it almost as the Core freaks were not there :-).

Now about the content. Read more…

Improving the DIA EDM Reference Model

November 18th, 2013 Comments off

EMC, by means of its Information Intelligence Group (IIG), has provided new solutions for Life Science. The solutions are based upon their Documentum D2 flagship.
Currently 2 solutions are out on the market: eTMF for managing Trial Master File and LSQM for managing Quality and Manufacturing.

Both eTMF and LSQM rely on their Life Science Core Document Framework (CDF), a data model for managing information in the Life Science domains.
This CDF is a core part of both solutions, like a data model is in any solution.
And like any other solution, success in using the solutions relies heavily on the fit of the data model.
To guarantee success, EMC has adopted the DIA EDM Reference Model to manage life science documentation in the Regulatory, Quality, Non-Clinical, and Clinical domains.

If you’re not working in the Life Science industry you might wonder: who is DIA and what is their EDM Reference Model?
Read more…

The integration of D2 and xCP

November 12th, 2013 Comments off

Most people who follow what EMC has been doing with Documentum know that the product currently supports 2 separate application layers: D2 and xCP. They come from different backgrounds, with D2 being more aimed at document centric applications and xCP aimed at case management applications. As they evolve, they are starting to overlap more and more. With the next release, D2 will add more workflow capability and extensibility and xCP will add more document management functionality. If this continues, how will future customers be able to choose between the 2 products?
The answer is, you won’t have to since they are gradually merging.

Even last year, when xCP2 first came out, there were already whispers that over time xCP and D2 will merge and become 1 product. This merge will take a few years, since the two products are built on different technology layers. D2 uses Google Web Toolkit (GXT), xCP uses ExtJS. D2 uses SOAP services, xCP uses REST services. These are major technology differences that make merging these products a long an difficult process.


Let’s look into the future for a bit. I wonder what a product that merges D2 with xCP would be like.
Let’s call this new future product xD (excelerated Documentum). What will this product be? What will convince customers to upgrade to xD?

I think that EMC will create xD with the stongest parts from D2 and xCP:

  • It will have a run time configuration layer taken from D2.
  • It will also have the strong build time configuration taken from xCP.

Creating a merged runtime

To make that combination work, a new runtime will be needed that supports both the D2 and the xCP functionality.
This is where the major technology choices will need to be made. Will it use the Google Web Toolkit, or ExtJS? Will Soap or REST services be used? Time will tell, but currently my money is on ExtJS with REST.
If my guess is right, that would mean that some of the great D2 functions will need to be ported to the ExtJS/REST runtime:

  • auto naming, auto linking
  • lifecycle functionality with state based authorization
  • C2 annotation/mark-up and O2 Office integration

Configuring Applications

Once all of the functionality is available in one runtime engine, the configuration tools can be added on top.
There will be build time configuration with xCP Designer and run time configuration with the D2 configuration matrix. So what things will be configured using each tool?
A paradigm that would work for me, would be that the build time configuration tool could be used to create a sort of template app. A set of types, rules and processes that define an application.
The run time tool can then be used to fill in the run time details to create 1, or more xD applications using the template app.

What things would be configurable at run time?

  • Users, roles, authorization for objects and functions
  • Picklists
  • Document content templates
  • User interface pages and workspaces with widgets that have been configured build-time
  • UI widgets that integrate external data
  • Search experience
  • Viewer and Office integrations
  • Reports

What to configure build time?

  • Object types, relations and aspects
  • Lifecycles and processes
  • UI widgets and page fragments
  • Business events
  • Full-text indexing
  • Content transformation
  • Back-end external system integrations

An application platform that could do all that would be very flexible and I would love to use it to build awesome applications for my customers.

EMC can you make xD happen please?

To D2 or to xCP, that is the Question

November 12th, 2013 Comments off

Now the Momentum Developer Conference is over for some weeks, it’s time to look back and see what we’ve learned.
I chose to follow the D2 track this time and since I’ve already done a project with xCP2, that gives me the opportunity to compare the two products.

The question many people are asking is which product to use for what. It seems to me that the long term answer to that may be very different from the short term, since both products are converging and are bound to be merged in some way in a couple of years. I have some thoughts on that, but I’ll save that for a later post.

So, when you want to build a Documentum application today, what product do you use? D2 or xCP?
Given what I’ve learned this week, I would say the choice depends mostly on the core functionality that you need. We all know since last year that xCP 2 has a very powerfull design tool that will let you build almost any application UI and gives you many options to integrate that with your current, or external applications. Now that I’ve seen what D2 4.1 can do, I realize that the same goes for D2. It also offers a composable UI that can be extended with custom functionality and integrated with other applications.

So the main differentiator between D2 and xCP is not the UI, but the underlaying OOTB functionality.
The functionality that D2 offers is most geared toward Document Centric Applications (or old-school ECM if you will). It has lots of features in that area, such as Auto-naming, Auto-linking, Documentum lifecycles, Virtual documents, etc..
xCP on the other hand has been created with Case Management Applications in mind. It has features such as Business objects, Stateless processes and Discovered metadata.

So there it is. My simplification of the current situation: If your application is mainly about documents, you should consider D2, if it has a case or data object focus, consider xCP2. That will give you the most usefull OOTB functionality.
Having said that, there are other things to take into account when selecting a product, such as the OS and database platforms you are using and other technical and organization details, so take my view as a pointer, but not as the whole truth and the only truth.

What you think? Feel free to let me know.

The power of EMC OnDemand

November 7th, 2012 Comments off

One of the hot topics this Momentum Vienna is the OnDemand. The new cloud offering of EMC. This blog is not about how great OnDemand is (but I assure you, it is!), this blog is about the reason why a consultancy firm like Informed Consulting, who makes money with third line application support on Documentum, should and is promoting OnDemand.

It is not an easy thing to sell internally. On average a third line support deal for a medium size Documentum solution is between 30k and 150k. When you use OnDemand most of these hours will be part of the full OnDemand deal and that will be done by EMC not us.

So why even mention this to a client? The answer is simple, I like the best for my clients.

Yes, I know for sure there are not better skills engineers than the Informed Consulting support staff and yes giving your Documentum support to Informed Consulting will minimize your frustration with your end users as response times go up and downtime goes down. (and that is a proven statement, over and over again!)

Yes, this is good money and yes, we love to do it

But here is the final clue: Documentum is build on an entire set of components, from OS to database, from JBoss server to Lucene search, from firewall to SAN storage (and you can continue this list for way way to long).

So, even if you have your app support managed by the best, the rest of the stack might be managed by the best, but not by a team that is dedicated to do Documentum support or more precise support on one of the components focussed on optimization for Documentum.

Our conclusion on OnDemand is: we rather do a new project and add new functionality than make money doing app support.
Also: a happy customer will add more to their Documentum environment than a customer which has frequent performance issues or downtime.

Programming versus configuration and D2

November 7th, 2012 Comments off

It seems a simple question. Do I code something or do I configure it. A normal no-brainer.
Configuration always wins.

Or is there a reason why configuration might be wrong?

Let me make myself very clear. When you can avoid programming it is always and will always be the best way. But it does not mean that configuration is always the answer to solve the problem.

This is probably something I have to explain and that is what this blog is about.

First I will try to explain the basics:

  • support for configuration is to create an interface that is very easy to use, so that users without any technical experience, but who know what the end-users need, can use their knowledge to make customizations in the application to make it fit the demands.
  • as a configuration demands a standard way to deploy the customization, the configuration approach will help define a controlled change process that makes making changes or even upgrades a less riskfull process.
  • last but not least, configuration gives you the ability to see real time what the customizations in the system are. Behind the scene there might be a lot of code, but the configuration-set should be a non technical representation of all of these lines of code and thereby give that easy overview of the way the system actually works.

Now I come to the new EMC Documentum D2.
First I want to make clear that I love the end result. The end-user interface is flexible and gives a lot of options to fulfill the end-users demands. Having played with the new configuration interface and tried to create two property screens for two object types I’m strugling with the points above.

  • Easy to use interface: a basic config screen in D2 has at least 3 rows of buttons in different locations, that you might use to make a customization. Every screen has at least 4 area’s where you might see or change something in the property-screen. Beside these items on one page there are multiple tabs for this one property page. Sure I understand that D2 wants to deliver a lot of options to customize a property-screen as clients are demanding this flexibility, but where do you stop with adding options in one screen?  Did someone with real user experience (so don’t let someone like me design it…) look at how you should position the different options ?
  • Deployment. As the basic concept is based on the context (or roles) and the functions they can perform and this is managed in one or more matrix table(s), which do not dynamically highlight the row and column your working on, it is really a gamble to know if you selected the correct cell (especially for an almost blind man like me). Even worse, when a role change is mandatory this will mean a full change of the whole configuration
  • And last but not least, an overview of the customizations done. You are able to export the matrices but getting and overview of what will happen with a property-screen based on a set of property values, will force you to open the configuration-page for the property-screen and look in a number of tabs and different regions within the pages and try to understand the impact of all changes.

So configuration versus programming: always configuration, but configuration can also be way to much. I think that it is mandatory to redesign the user-interface of D2 config and create a more wizard like approach that structures and maybe limits to possibilities of configuration. The current solution will probably lead to the same chaos that to much programming will do.