PDMLINK Performance - # Objects per Folder

All,

I am migrating from Pro/INTRALINK to PDMLink 9.1 M010.

Today was my first day on a migrated ILINK 3.4 to 9.1 environment. Not nearly as painful as I thought it would be, probably because we were introduced to it slowly, with structured, electronic releasing being the first brick int he edifice. And because I participated in beta testing and validation for a month before. And because we got some actual formal training on the system. That said, it's an enormous jump from the more or less freewheeling days of ILINK, a big psychological and cultural shift that may be a lot more annoying than having to "search for data".

I am being told that for performance reasons, the target PDMLink environment needs to be limited to 3000 objects per folder, an object being defined as an iteration. The target PDMLink environment will be very large and many users worldwide, most being in the US.

I'm far from an expert on this, but the limitation seems at once far fetched and yet possible, given the following major differences with ILINK:

1. ILINK used "checkin" as a backup and vaulting strategy; PDML, by contrast, has several levels of storage, the main one being a "local" cache where most of the iterating will take place, then another "remote" cache where changes are uploaded. Check in is reserved for the releasing scenario where you are done with your changes. So, check in not only stores a final iteration of the documents but releases it to be routed for signature. In this much more limited, restricted file storage scenario, many orders of magnitude fewer iterations will make it into "common space" folders.
2. ILINK used "checkout" as a way to get a drawing, assembly and all its components into a workspace; any number of people could thus "check out" to download the same data. PDML, by contrast, checks out ONLY the files to be revised and covered by CN for releasing and these limited files it locks in "common space" against anyone else checking out. In this much more disciplined, restricted scenario, far fewer files will be check out and checked in, again, reducing the number of iterations. In this scenario, the number of iterations might be 2-3 times the number of drawings released per month, plus R&D stuff, but we're still probably talking about your 50-80k divided by 100.
3. What is said about such restrictions may be build dependent, so, as PDML is now up to M60 (loaded here over the weekend), the currency of what you were told ought to be confirmed from a knowledgeable source.

The proposed solution is to automatically create numbered folders under each product based upon object count. The proposed solution basically does away with using the folder structure to structure the data. This will require the users to search for their data rather than browse CS for it. As you can imagine, this will make migration very difficult and is guaranteed to make my users a ** little ** annoyed.

One of the big deals in PDML is a "business object" based product structure plus many built in techniques for configuration management. And that product structure, embodied in the WTpart, is independent of the folder structure, across the organization. Old habits are hard to break, but a large organization ought to get used to NOT browsing a very likely enormous data base. And PDML is optimized for searching (separate indexing server), sorting, table views, personal, complex, custom seaches, work flow reports, status reports, role reports and a host of others. The use of all of these sophisticated tools requires a mind set much different from the grazing one. People who are stuck in such a rut will be irritated by MANY things in PDML. Pay them no mind. Give them a quiet corner with a drafting board, some paper and a pencil. Let them fill out their days, comforted in the illusion that they are all geniuses and artists, in the manner of Da Vinci.

David Janes