Archive

Posts Tagged ‘D2’

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.

xD

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.

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.

D2, a hammer, but is everything a nail?

November 7th, 2012 Comments off

As Informed Consulting we believe in the individual employee that needs to be connected to the enterprise.
The individual has become important and will increasingly become more important.
Today employees are a mixture of people that grew up without PC’s and people for whom always on-line is like breathing: you can’t do without.
Our live has changed. Our expectations of the organisations have changed. Bring your own device. Choose your own tool.

From the needs of the enterprise this looks completely different.
Control. Compliance. Structure. Successful ECM solutions typically meet these two needs roughly halfway.

Meeting both needs halfway needs more than just the good old Documentum Content Server and Webtop. We see the combination of SharePoint and Documentum — connected through SDF — as a common solution.
But what if — right or wrong — the customer doesn’t want SharePoint in their IT landscape? Is D2 a product that could fill that gap? Can we SharePointize D2?

Yesterday was election day in the USA so the applicable answer is: Yes we can!
But like these elections, it’s a close call.

More importantly, it depends on the context of your collaboration.
If it is just document handling and providing ‘info’ widgets next to it, there is a significant overlap between SharePoint and D2. Later, when D2 will add full 2–way communication in the widgets, it will even get closer.
If your collaboration is also around discussions, contact lists, meeting agenda’s, and all those (sort of) content-less objects, it becomes a different story.

The question then becomes: will you create all those missing features somehow in a Documentum back-end? I think — although technically possible — you shouldn’t. Once you have a hammer, not everything is a nail.

To avoid this pitfall, you must think carefully before you act. Ideally, even before you choose the solution!
D2 to some extend reminds me of the late 80’s with interfaces on top of databases.
We’ve come a long way since and learned some lessons.
One is to do your application analyses very well. Get all requirements. Make your use cases. Do your interaction designs. Then choose your solution.

Approach of the new xCP2

November 6th, 2012 Comments off

The two interface types EMC Documentum really put their focus on are D2 and xCP.
In this blog I will give my first impression about the paradigm of xCP.

The first technical thing you see is that although the interfaces are very similar D2 and xCP are based on different JavaScript standards.

xCP relies on eclipse and uses a lot of the concepts that are well known in eclipse. (a Java development platform). The focus of the configuration is still the same as the old version: you create forms (pages) per action of objects that will be shown based on the step in the business process or independent actions performed by the user. New in this is the business object concept. In the old xCP you created containers (often folder) to store information about the items that are managed in the solution (like a contract or a client). Now the whole new xCP really has a business object that is defined as a object that does not have to be within the archiving structure. This really separates the business operational logic with the archiving structure.

An other important change is the concept of the interface. In TaskSpace the interface was standard and you could set some properties (if you want to avoid any WDK development) to show a different logo and color. In xCP2 you define an application master page just as you do in PowerPoint. Way more flexible.

Last but not least you see the use of relations between business objects. Already a basic Documentum functionality but never used in xCP.

My first impression is simply put VERY IMPRESSED. As my vision is that Documentum should be the repository for enterprise important documents that need to be controlled on an enterprise level, you need a tool that gives you the possibility to demand ease of use but structured and control. xCP 2.0 gives you just that.

Cannot wait to play with it on some serious projects.

D2 Application Building

November 6th, 2012 Comments off

At Momentum 2012 in Vienna there are 3 numbers that pull the attraction: 2, 4 and 7.
Although the target is still the New Normal (Peter Hinsen), the user that mixes work and private in a 24/7 (see the numbers…) economy, it refers to the 3 major products of EMC. It’s xCP 2.0, D2 4.0 and Captiva 7.

Side note: for those that linked 7 to the new Documentum stack, which has reached version 7.0, I must admit that it is tempting to do so. However, that stack sits underneath xCP and D2 and I believe that it will be a matter of time before it becomes irrelevant for the normal user.

From the 3, D2 is the one that is of particular interest. With version 4.0 being available (4.1 is due early next year), demo’s, the tutorial and the hands-on lab all show one thing: this is the foundation for all user-interfaces to come. It will be very simple and tempting to configure a Webtop clone using D2 or in the future, replace e.g. TaskSpace with the paradigm of D2.

The question is: should you configure that Webtop clone in D2 or not?

I believe you should not. D2 is the tool-set that allows you to configure whatever (within limitations) interface you need. Or better put: the interface the new user needs. The business user.

All of a sudden we’re no longer tweaking an interface (Webtop) to meet the business user half way. No, were creating a specific interface for a group of business users to do their work. Doing so also means that it can no longer be the average Documentum consultant — you know that technical guy or girl that eat and drinks DFS, Content Types, ACL’s — but you do need to bring a different consultant to the table.

You will need a skilled user experience consultant to sit with the business user and have her working towards an interaction design for the solution. Only then you’ll be able to deliver the solutions that the business needs. At Informed Consulting we’re glad to have that expertise already at hand. It’s more common in a SharePoint world and for us as a C3P partner that is EMC’s go-to-partner for SDF — SharePoint Documentum Framework — we’ve seen the challenge of creating a bridge between the business and IT tools. We’ve seen the risk of creating a language barrier by putting the Documentum guru next to the business guru. We’ve seen that creating a design document is not enough. Most business user find it hard to visualize from words. It goes without saying that a picture paints a thousand words.

It’s here were the user experience consultant steps in. Not only for retrieving better requirements, but also for creating mock-ups, screen layouts and other visuals to validate that the needs of the business are fully understood before we’re starting to configure the application.

So, to tame the beast of D2, take care of your application analysis first.