Archive for the ‘D2’ Category

Day 4 and 3 before it begins

May 3rd, 2015 Comments off

Yesterday I missed the opportunity to write my blog. Packing was on the menu for the evening. The past few days I could take those 30 minutes to write my blog, but now I had to make sure all items for our booth where packed and ready.

Two laptops, a hub, a lot of flyers and some nice give-aways. Thought I was ready but then I remembered, I needed to finish the last tests of our Office 365 demo with SPA4D and our SharePoint LSQM integration solution. The first is easy. I have given this demo probably 50 times now and all with great success. Our integration with LSQM is a different matter. We are just releasing this together with the Live Science team of EMC – EDC.

The business case is simple but perfect: within a pharma company, a large group of users need to read the SOP’s and other important documents. This needs to be in the audit trail. This TBR (To Be Read) is a very basic function within Life Science. Normally the user needs a full LSQM license and needs to be trained how to operate it. That is not easy, as they might use the system only 2-6 times a year. On the other side, most of these users use SharePoint, they like it, understand it and are fine working with it. So the task is simple: create the TBR function with SPA4D and the answer is perfect. A simple task for users to perform and after the sign-off, a record in the audit trail is added for this action.

But that was the easy business case. What is much more interesting is the ability to service all partners in the life science ecosystem of a company. More and more pharma companies are just managing the process and out-sourcing a lot of work to partner companies. These partner companies come in different sizes and shapes, but also both in very tight or very loose relationships. But for almost all of these companies it is mandatory that they need to be able to read, comment and sometimes edit or create regulatory documents. This demand calls for a set of options a company can select from.

1) if the partner is fully trusted and you have a full working relationship, you might want that partner to have direct access to a subset of documents within Documentum. This needs to be a much simpler interface with preferably a lot cheaper cost-base as these users might change frequently. The interface should be simple and easy to use. The access needs to be possible within the extranet of the pharma company or via a cloud based solution like Office365.

2) if you work on a less frequent bases or less intensive manner with the partner, you might decide that the partner does not need to have full access to the site, but only read only access to a part of the site and should be able to submit documents to be added to your quality system. Again this should be a cost effective interface and simple to use. Because of the more limited relationship it should suffice that only the high level actions from the partner are captured in the audit trail, but versions and revisions should be fully available.

3) if it is a one-time or incidental partner, the partner should only get a copy of the relevant document(s) and should have a communication that is very controlled when documents are added to the system.

And this all makes together:SPA4LSQM-Partner eXchange (PX).

Within the easy to use SharePoint Interface you can decide what level of trust you give to a certain partner and configure the level of access to your QM solution. Trusted partners will get access to the full browse app-part of SPA4D to manage the documents they are entitled to and partners with less of a relationship will get only read-only access to Documentum and can submit documents via a process within a normal SharePoint library without having direct access to Documentum. If you want to make the integration even more loosely coupled you could share the documents with the partner via OneDrive for Business and not even give the partner access to the SharePoint environment, but still control the documents.

All very powerful and very good to demo.  So finally at 1.30 am all was tested and I was ready to go. Now I’m sitting in a Delta plane for the last hour before we touchdown in Vegas after a long, long flight. Hope to see you and let me impress you with a good demo of SPA4LSQM or join us in the raffle for a very nice toy.

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…

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.

Meanwhile at #MMTMDevCon – The EMC Developer Conference

November 14th, 2012 2 comments

Last week Vienna was the place for the annual Momentum conference, the place where the European Documentum community gathers to exchange news and views and to get the latest on what EMC has been doing and is planning for the IIG products. In Vienna a whole list of product announcements where made, most notably the release of Documentum 7.0, xCP 2.0 and Captiva 7.0.

Now this week nerds techies people from around the world gather in Pleasanton for the Momentum Developer Conference, right next to the EMC IIG headquarters. This is where a lot of technical details of all the new products are going to be revealed and where developers can actually get their hands on in lab sessions. The first 2 days of keynotes and presentations where very interesting. Now I am ready to get my hands dirty tomorrow.

I had 2 main questions for this conference:

  1. What are the differentiators between D2 and xCP2. When should my clients use the former and when the latter?
  2. What are the migration options to the new products?

Here is what I gathered so far.

When should you use D2 and when xCP2 ?

D2 4.0 is the User Interface that focuses on configuration instead of coding. Everything plus your grandma’s rocking chair can be modelled using the D2 configuration interface. The downside for some clients is that D2 cannot be extended with custom code. You have to make do with what is in the D2 box. There are simple consequences. For instance eRoom or CenterStage like collaboration functionality is not possible in D2 4.0, as is Records Management and Brava! viewer integration will be added in 4.1. Also in 4.1 or 4.2 all ‘specialized interfaces’ such as CenterStage, eRoom and Media Workspace will be incorporated into D2.

Then there is xCP 2.0. You may not gather this from the name, but this is a completely new product that goes way beyond anything that was offered with xCP 1.x. It offers a completely new way of building applications on Documentum and ties into the new D7 features, such as the Business Objects, the event model, stateless processes and xMS deployment. xCP Designer is a new unified developer IDE that replaces all 6 tools that were needed to build something for xCP 1.
xCP2 also focuses on configuration in stead of coding. The difference being that xCP has build-time configuration and D2 has run-time configuration.
xCP2 also has well defined extension points, that you can use if you need customization.

As far as the UI goes, both D2 and xCP2 produce modern looking flexible user experiences, based on HTML5 and JavaScript. Both offer UI widgets that can be used to compose role based user interfaces. The functionality offered in D2 is more geared towards Content centric applications and the focus of xCP2 is more toward Process or Case centric applications, but that is not a great differentiator. Going forward, the choice will become even more difficult, as there is talk of supporting D2 configuration in xCP and visa versa and there is even talk of the 2 UI’s merging completely into 1 unified UI.

So what to advice to clients that are looking for an improved UI? There are clear cases where D2 is not appropriate. The word is still out on the other cases. If D2 can fully support your use case, why not use it? But then again, why not use xCP?

What are migration options ?

Migration is my other area of interest this week. It turns out that there is a fairly clear migration strategy that most customers can follow. It requires a phased approach.

  1. Upgrade your client UI to version 6.7SP2. This is needed because 6.7SP2 clients are certified against D7 server as well as older servers (6.5, 6.6 and 6.7). This will give you a working system with a 6.7SP2 client working with the server that is still on the version that you were on.
  2. Now you can upgrade the server to D7. The 6.7SP2 clients will work with that server. It is advised to do the upgrade by creating a clone environment first and then performing the upgrade on the clone. This gives you the opportunity to upgrade the server HW and OS and has the advantage that the old server can keep running while you do the upgrade.
  3. Now you can upgrade the clients to D2, xCP, or Webtop 7.0. This may not need to be a big-bang conversion. You can go over 1 application at a time and may even select a different UI for each application that you have, though using more than 1 product may present a challenge on the license front. Webtop is still there but is not being developed. When you do go over to D2 or xCP2, you should redesign your whole application because the interfaces are so different and you would just miss out on most of the fun if you try to rebuild your Webtop as-is in one of the new UI’s.

More to come, stay tuned…

Your new interface in …? D2? xCP? Both?

November 7th, 2012 Comments off

Going through the Retention Policy Services class at Momentum 2012 in Vienna, I could not keep from thinking of a new interface. Why? I’ve seen so much of D2 and xCP during the past days that the new user interfaces and the new way of solution building, have become to norm for me. Although brand new, this is what customers expected for a long time.

Going through the class I realized that such is not an easy thing. It’s all integrated into Webtop. Not being a records manager, I can be wrong, but it seems as if there is a mismatch between how the tool is designed and the way records management is organized. It seems tool driven rather than process driven. Just for the sake of this blog, let’s assume that my feeling is spot on.

The question is: how would one recreate this? Using D2? Using xCP? Using both?

The easy answer is: it depends. It depends on goals, objectives, budget, time, resources… Foremost it depends on the business requirements and use cases.

Recreating the RPS interface should be driven from the requirements that tell us what the user needs to have in order to do his work. One of the constraints however will be that recreating a user interface should not lead to large changes to the back-end. Only then we will be successful given the time and money spent by the companies to implement a records management solution and in some cases have that validated.

Won’t we do that, we would end up with a clone of the current interface in D2. Possible, but in my opinion a missed opportunity.

Strangely (is it?) enough I believe the answer should be 2 separate solutions. One for the average user and one for the records manager.

The one for the average user is needed because he works with documents and needs to apply a policy every now and then or promote a document to a record. Yet, I hope most of this is done automatically. In those cases that human intervention is needed, the functionality will be available through D2 solutions that exists for that average user. Not an RPS solution.

The other one is needed for the records manager. Records Management is a structured process with unstructured data. Such processes are to be implemented through xCP.

The question that is addressed above is a typical question for all current user interfaces/solutions that rely on Webtop. What will be the replacement? Something in D2? Something in xCP? Something in both? There is no single answer. Each case must be validated on its own. And unlike the above, factors like time, resources and money may do influence that choice. I strongly advice however, to make the choice first without looking into these 3 spoilers. Make sure that you take the conscious decision to cut corners for time, resource of money sake.

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.

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.