Do We Need Files to Collaborate in PLM?

Picture 32Interesting publication came during the weekend related to the future of collaboration. According to the analytical research, 80 Per Cent of Enterprise Collaboration Platforms Will Primarily Be Based on Web 2.0 Techniques by 2013 Managing Users’ Transition from File-Orientation to Web 2.0 Approach Will Be a Major Challenge. The main point of research and/or prediction made by Gartner is related to the difference between so called – “file based” and “browser based” collaboration came mostly in wiki-style and web 2.0 like tools and future migrations between them.

I’d like to take it a bit future and analyze what implications it can provide for future collaboration in product development. On one side, most of CAD based collaboration tools are file-based. Files are remaining the most significant piece of information people are collaborating on. Files come to the collaboration in a very different way – CAD files (obvious), many CAE related ones, Excel Files with variate of information resided into these files.

On the contrary, we can see many tools that purely web based on hybrid with significant dissociation from file content. Collaborative tools in the style of Wikis, collaboration tools come out Microsoft SharePoint, various Web tools are coming more and more loudly shows their place in collaboration.

Separately, I’d like to say few words about CAD and collaboration. Tools like CATIA V6 and associated 3DLive presents a new way collaborate on single product content (mainly design, for the moment). What will happen to these tools in the future? Will it be the foundation for the future non-file collaboration tools?

So, what is my conclusion today? Collaboration tools are slowly starting to their move from the need to read “files” into the direction to focusing more on pure “content”. In my view, this move will be slow, but this is a way to go. So, may be in 2013 years we’ll see a completely new way to collaborate as it according to the Gartner prediction? Hmm… interesting.. What do you think?

Best, Oleg

Share

Share This Post

  • Martijn Dullaart

    If you look at the developments surrounding for instance Google Wave, this is indeed the way towards we are moving. But I also think it really depends on usability. CAD files tend to be very large (depending on the design) and if we move towards content instead of files this also means that having a very fast network/intranet/internet is a must have.
    So I agree we are moving slowly towards content oriented focus, which will be driven by the usability of the service.

  • Martijn, thanks for this comment! Content orientation is cool and, in my view, can be more productive (compared to file-way). I’m playing around GW last few weeks too and this is promising. Best, Oleg

  • The key will be where the pain point may lie for the different user types of the systems in question.

    As someone who is both content creator and publisher for a blog (e.g. like you, Oleg), the simple move from a traditional HTML-based site to one that is database driven generates immediate appreciation for moving away from individual files.

    Rather than have to manage discrete pieces of content, a blog (aka content management system) provides a layer of abstraction allowing the creator to effectively ‘forget’ about it. All of a sudden, you get to (for all intent and purpose) forget about content -management- and focus on -creation- instead.

    This very notion has been the subject of just about every 3D/PLM solution the market’s ever seen. We’ve all seen the decry the benefits of ‘focus on your design, not on the tool’ or some such.

    While PLM solutions make the individual file management increasingly transparent for users, it’s still something they at least need to be aware of. As the systems move to more database focused solutions users will increasingly enjoy the -true- nature of content-focus that any blogger already does today.

    This is interesting because I do recall my own company, perhaps 10 years ago, debating using a database-centric paradigm (love that word). The effort (it’d actually had a fair amount of resource put into it) was eventually cancelled. While infrastructure issues were a concern (CPU, storage, architecture, networking, etc.), a major concern was how to still support a file-based solution. For instance, imagine your software (e.g. BobCAD) is used by both BigCo and LittleCo. How do you support BigCo, using your software as a client to a database, exporting files for LittleCo can consume using the same client?

    I have no doubt what direction we’ll end up heading. But the need to ‘s p a n’ the traverse, providing dual support (whatever that means) for an extended period is likely going to prove as big a challenge as the simple move to a database model itself.

  • Roberto Barale

    File and DB are the most important object to store data.
    Into the CAD world major player are still using files to store main elementary objects.
    DBs are used merging together all other type of relations between complex CAD objects.
    Both DBs and files are objects allowing end user to clearly identify elements of his work.
    DB generates some issues compared to files and obviously give a lot of advantages.
    DB allow managing very complex relation between CAD objects (BOM, PBS, FBS, Impact analysis…)
    File flavour simplicity of data exchange between company and single users.
    DB allows adopting sophisticated security rules.
    … and more and more …
    So new approaches avoiding to store CAD data (and not only) into files are very powerful because enable the management of complex objects on the same platform (web or not) by communities who are single users or company users, inside a company or distributed around the world.
    I don’t want examine the infrastructure requirements to put in place such a solution, I prefer suggest some general remarks and questions due to this new approach:
    1. files are simple object with a very clear ownership
    2. Inside a community of users belonging to a company which are the ownership concerning complex data?
    3. How to regulate access and data contribution on complex objects?
    4. What about the complexity of partners, co designers, join venture?
    Who is the owner of the data?
    What is the data? Files? Relations? Attributes? How to isolate a single data if it still exist?
    How to manage intellectual property security?
    5. For big companies, merging and separating depending on policy and monetary aspects, what about complex data organized into complex system?
    How will be possible to protect or separate data and related intellectual property?
    So coming back to a more simple point of view, file based systems are more simple to manage not only from a technical but also from a political point of view, so this could be one of the reasons why the new approaches are growing slowly.

  • JT, Thank you for your insight! What you are saying about dual-solution is right. I’d call it “transition-phase”. I have to say that lately I found max understanding of such hybrid solutions in what SharePoint 2010 is doing. They prob. understood importance of Office files and therefore are trying to keep all balanced. On the other side, my point was about “collaboration”, and this is somewhat people mislead with overall data management. You can still manage your files, but collaboration services will be content-based. Does it make sense to you? Best, Oleg

  • Roberto, Thank you very much for your comment! Agree, if you are trying to “manage data”, these are very valid questions you need to ask – ownership, storage, access, complexity of relationships etc. But, I’m trying to get it to the point when “collaboration” will be possible. Since, collaboration brings value. You can still own and manage your files as you want, but to have environment supports you to work with other people, this is somewhat that will be more and more disconnected from file storage to streamline process people communicate. In addition it make a lot of sense when you think about multiple level to get into this – devices, phones etc. Does it make sense? Best, Oleg

  • Hello Roberto,

    Good comments. I’m not able to agree with your closing comment though. In my various experiences I have found managing collections of files to be nothing but a royal pain. In contrast, managing data in singular databases (even if it’s a db whose object ‘are’ discrete files) far easier. A dbase generally makes it easier to administer complex (often politically-driven) access privileges at different levels of granularity.

    This is actually one area where centralized dbase-driven content administration is a boon. For instance…you may want to give someone full access to a design for analytical purposes. The analyst needs black-box type I/O, but they don’t need to see inside necessarily. In a file based world this requires either different file versions, sophisticated data compartmentalization, or creation of abstracts (a few examples). In a dbase, you can simply have a single design instance, yet administratively control what is transparent…or not.

    Moving back to the simplistic level, a dbase allows a single point of containment, that can be designed to support whatever level of accessibility is desired. Individual files always end up being, again in my experience, a collection of unruly things to manage–at some point.

    It is, to be sure, and interesting topical path that Oleg has set before us:)

  • Hello Oleg,

    To you last reply, you raise a good point. I believe about the only way you can have device-agnostic support is via a database (centralized) driven solution. Consider engineering annotations being done via iPhone. Rather than download a DWG to an iPhone to do annotations, you could much more effectively login to a server and manipulate it to do the work. Client-side, a user (discounting need to download a file) might never need know the difference.

    🙂

  • Martijn Dullaart

    Hi Oleg, I was thinking a bit more about this subject…
    If we move from file to content we also move much more towards a context oriented interaction. In a file we usually have much more data than is needed for the purpose of the action the collaborating party needs to perform. So in that sense we also move to a more context oriented form of providing data/content.
    That also means that you do not agree on a format of a file so much as that you need to agree on the context. Which I personally think is very good development, because this will be much more specific to the need of that collaboration agreement.

  • I am very interested in Roberto’s numbered list. In theory, software companies moving toward a database-centric data store for CAD data will store information in a granular fashion. To J.T.’s example, the analyst will only need geometry and material information to perform his/her function, and will therefore not receive all of the dbase records related to parameterization, kinematics, or other content. In such a world where the database records have reached their most atomic state (cannot logically be broken into smaller pieces), will security management become a nightmare?

    In today’s PDM world, we are challenged with maintaining complex project-based security and object-based security structures. If we further subdivide that so that we are managing individual CAD features, or individual calculations, I fear we will have satisfied some and encumbered others. Add on top of this the rate at which we are generating new information, and it makes me wonder if this new potential level of granularity will be helpful or if it will be unnecessary “noise”.

    Aside from that detailed point, I am excited about the possibilities for collaboration when we can stop worrying about false boundaries (like who has the file open in writable mode). I think we’re going to have to do a lot of work to make that world possible and transparent (like today’s CMS systems do).

  • Collaboration involves sharing of information (content) that may be made available as files (various formats), as application content or as a service. Such availability has to be subject to clear responsibilities and rights (access and change). The distinction between files, web-services and other technologies is not critical and the environment is likely to be mixed for many years to come. The problem stems from overlaps in content between sources (files, systems, services) and their effective independence. The key need is to manage a cohesive set of information for the collaboration and, where different sources remain important, to maintain the relationships between information from those sources. The relationships between sources include, for example, tracing and versioning relationships and are needed to handle change properly.

    One real value of the growth of Web 2.0 technologies is to increase the level of capture of implicit relationships between content. Currently these relationships are sometimes artefacts of processes that are lost when moved beyond one enterprise (PLM) and sometimes only held in the other important source, people’s memory.

    In summary, collaboration requires a focus on information which is independent of the technology. Thus the answer to your question is yes – as long as files are a source of necessary information. I am just not sure it is the right question. It is the information that counts, much more than the form/wrapper it comes in. One way to get information independence from technology that works across organizations is to use content standards such as PLCS [ISO 10303-239].

  • JT, you are right in your example with iPhone. Database (or any other centralized content-level) approach will give you an advantages vs. multiple file solution. Best, Oleg

  • JT, another comment on your conversation with Roberto – There is an advantage of database, no doubts. But most of today’s tools are file-oriented. How do you see connection between these two layers? Best, Oleg

  • Martijn, You are right! Content/Context take you out of file-related dispute. All systems need to support content to collaborate on… Regards, Oleg

  • Jonathan, I’m pretty much share your excitement. I’m sure we are slowly moving away from file orientation toward content/web orientation. If you think more, it will brings additional security. No files- no things that can be stolen. Try to still gmail… you just cannot. Best, Oleg

  • Nigel, Thanks for your comment! CAD/PDM/PLM industry is trying to consolidate around “A FORMAT” that can be shared by everybody for years. However it seems like not feasible target. I think DOD standards (which I believe pushed forward PLCS works you mentioned) had a significant impact. But still, I think, development of web 2.0- like collaboration tools based on contextual collaboration have an advantage vs. file-based work. Just my thoughts… Oleg

  • Hello Oleg, et al.,

    Numerous valuable insights being shared. Good stuff.

    To your question, how do I see a connection between file/dbase layers…ties into the thought I had after reading Nigel’s own comment.

    While they are all we had and have, files are artificial contructs forming barriers to the true exchange of information. The more transparent the barriers become, the better. After all, this whole discussion thread isn’t even about the -content- itself, rather about the constraints (files/formats) we’ve placed around them.

    The relationship? The ‘file’ will remain necessary for a long time. If only as a means of transferring encapsulated data from a provider (e.g. OEM) to a service provider (e.g. supplier). It may be something as simple as needing the file as a container of info for a machine tool.

    I envision being able to tag information in a dbase and, selectively, being able to export it to a file. Working through the details here would be cumbersome. In a simple example: individual objects, whether they’re a conveyor or a 2 point line, will need to have logic enabling them to know “if ‘I’ am selected for export, then ‘these other’ objects need to go for the ride.” This logic will be governed by the mix of constraints we’ve discussed earlier: permissions, role, task, etc.

    Of course, there also needs to be a mechanism for effectively tracking data for possible reintegration at some future point. Initially, it may be easiest to only allow for export of data. But a fully-functioning system will require bi-directional capability.

    Individually, many of these things have been tested and used in production already. Pulling it all together, particularly with a centralized orientation, is where the next generation of real fun begins:) !

  • JT, Thanks! Good discussion. The idea about centralize orientation is interesting and (not a surprise) not new. Tagging is way to simplify things. At least it works in consumer oriented application and helping to collaboration between individuals. Best, Oleg

  • Loic Mouchard

    Hi Oleg,

    it seams everyone in the discussion wants to stop dealing with files. Let’s try to see if they are needed…

    I really think a centralized approach (without file) can provide efficiency during the different phases, but the aim is a product, and intermediate aims are I think documents that describe the product in its phase.
    In that extend, we could imagine that a solution could combine a DB part deal with the “drafts” or the current content of the product; with a file based approach, that masters the results of the work.

    Furthemore, I hope I can in the future continue to work without been always linked to a centralized system; and to deal with manageable content that concern me. In that perspective I am quite afraid with the duality between the real complexity of a centralized solution (let’s say DB), and the simplified way to present it (everything accessible for everyone anytime, etc.)

  • Loic’s comment seems to be aimed at the needs of a single enterprise but the original question was about collaboration. This can be between functions or across enterprise boundaries. Once a product project involves collaboration between enterprises there will be multiple centralized solutions and a requirement to synchronise between them.

    Recognising this, some of our (Eurostep) customers are now have the business objective to be good at cross-enterprise collaboration and are using a standards based information hub that allows them to use their in-house tools (including PLM and ERP) while receiving/publishing information to their partners. Transfer mechanisms to and from the hub include file exchange (many formats from .xls to STEP to native) and web services – whatever is needed for each partner. As I said in my comment above, the focus shifts to the information needed, rather than the file or format.

  • Nigel, Luic, Thanks for articulating well the problem I see. We hate both – complexity of centralized systems and our will to stop dealing with files. Looks like a perfect time to see what are alternatives…. In my view, content oriented systems (not necessarily having central database) could be a potential answer. Best, Oleg

  • Je vais terminer dе lire tout ça ɗans la semaine

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll