Is PLM too Complex to Mashup?

 I was amazed to discover that there is almost no reference to PLM systems using Mashup technologies. So, what is wrong with Mashups? My impression was this is a very successful technology since Mashup usage is growing in multiple vertical industries. Starting with Google Maps, Mashups show their power through their ability to combine data coming from multiple sources. So, why don’t PLM systems understand this value?

 My initial assumption takes me back to PLM content management. PLM absolutely dislikes the ability of foreign systems to touch and manipulate content – design, bill of materials etc. The core perception is that this content is complex and cannot be simply extracted from a PLM system. At the same time, most of the successful Mashup technologies are based on their ability to take data from multiple systems and merge them together – in other words “mash” them “up”.

 So, what we can do to improve this?  How can we popularize PLM content? – by allowing multiple functions in PLM software to extract content such as models and drawings,  Bill of Materials etc., and make them available in formats and representations that can mash-them-up to something people will actually use. I can find multiple use cases for this such as mash-up design information with CRM systems – to see what parts of a design are most problematic in customer reports. I’m sure you will be able to find more applications and use cases for such Mashups…

 What is a Mashup? – ZDNet

 Let me know if you have experience with Mashups and have found them useful…


Share This Post

  • Love it Oleg. I wish more people were thinking like you. I have a small amount of experience trying to create mash-ups and looking at how data is used in the mash-ups online.

    Biggest problem I see on the PLM side is how the data is… presented? I guess. Web apps use XML and javasript to run a lot of the mashup code. I’m not familiar enough with how every PLM/CAD/CAM system is built in order to say it’s possible with some and not others, but until there’s some commonality that lends itself to being able to mash the meta together and render it within different programs (preferably web platforms) it’s going to be to a while till we get there.

    What programs do you see being the leaders for bringing mashup tech into CAD/PLM?

  • Hi Josh, thanks for your comment. In my view it’s all about PLM content availability. Today you can either extract some neutral files (like PDF, and you lose big portion of information) or use technological stuff (like Web Services) which is not simple. So, in my view this space is mix of vendor resistance and technological complexity for the moment. Need to watch it in the future. Regards-Oleg.

  • Isn’t PLM already a mashup? For example isn’t a BOM a mashup? As well a part (at the PLM level) is a mashup. A part is represented as a set of files, attributes and other stuff.

    That said Josh is onto the real isssue. If PLM is going to be a Social Product Development platform then it will need to embrace open concepts. Have you looked at ARAS and their Open Source PLM? I wonder if they have made progress relative to mashups?

    Oleg what would be interesting is if you explored in another post the types of datasets that would be valuable to mash and in what use cases. Although we are somewhat far away from this today Vuuch could be seen as a mashable dataset. Vuuch knows which discussions are linked to which parts and therefore we know which people discuss which parts. One thing you will see us do is provide a humanized view of a part, meaning we will render a view of a part based on who and have a weight rendered in some way based on volume of discussions.

  • Hi Chris,
    I will try to split your comments on separate parts, since I have feeling they need to be addressed differently.

    As per you question “Isn’t PLM already a mashup?”, the answer is probably “yes”, in the case you are talking high-level, almost marketing talk. Every time you put information from different role-based silos, you can call it mashup. But from pure technological standpoint mashup technology considered web technology allows to mix (mash-up) data mostly on client side that comes from different web sites (or servers if you will). Since PLM is not single applications I’d not call it “mashup” technically. Also, typical mashup have no control on data (data comes from other sources) and this is a little bit different in PLM.

    About Openness. I think you are right, PLM need to be more open, but this is not about Open Source first. Open source is mostly about business model in my view. You can have Open Source PLM, but still continue to develop closed formats to exchange BOM or CAD models. But will be interesting to talk to Aras guys about it. I’d expect them to comment here.

    About datasets. I think industry developed already many datasets and formats. Starting from STEP PLM XML, PDX and others. More or less talking about the same data. But I will think about what can push openness to make it more easy. May be ability to support available Mashup platforms (i.e. Yahoo Pipes and others)…

    And and Vuuch. Looks like if you will expose design discussion in the way people can mashup this information with other data, it can be very beneficial.


  • Pingback: PLM 2.0: Technology or Facelift? « Daily PLM Think Tank Blog()

  • Not to beat a dead horse, but the discussion recently about adding 3D into RSS (ala what GeoRSS has done for the mapping folks) would seem to be a required starting point for getting true mashups going. As mentioned, 3D PDF is useful to a degree but not the magic bullet for a true mashup, which implies you’re bringing data together from multiple services. There’s also a GeoJSON specification that has eased creation of mapping related mashups — perhaps a 3DJSON exercise might be worthwhile as well to grease the 3D mashup wheel. But what is needed is a platform for 3d ala what google maps is for mapping upon which to build these mashups, any ideas where that might come from?


  • Dale, you raised valid point. This is second side of the problem. First – how to get content to mashup? Second what to use for mashup context? 3D environment is definitely one of the candidates. The debates will be if this environment is good for all people or, in another words, if 3D is universal language we can use. There are some other candidates as well. Regards. Oleg.

  • It didn’t dawn on me till now but Seemage or 3DVIA Composer is a mashup tool. You can collect 3D from multiple sources and combine it, but you can also add any meta data you want and then extend all this as you desire within Composer. Some of this you do from the UI but some needs to be done through XML.

    What makes this work so well is the open XML model they have.

  • Chris, I like you found similarity with ability of Seemage to combine data. On the logical level it make a lot of sense. On the technological level, this is still product that was developed with specific understanding of CAD formats and it’s depends on ability to get this data out. It’s not simple to mashup PLM (or whatever you call it) content using standard mashup technologies. Have you tried to use Yahoo Pipes and PopFly? or even Google Map? regards,Oleg.

  • I get it that it is not really mashup compliant… but as far as I can see it is the closest PLM has. Maybe using the Composer API you could build a prototype of something that would be more compliant?

  • chriss, agree. But in this case I stuck with fact composer produce files. And this is not web based sources of data… so, I cannot build web/online apps.

  • but you can do all this via the web with composer… at least for a prototype.

  • chris, probably I have lack of knowledge in Composer architecture. How I make it available via http?

  • Hi Chris,

    I was also thinking about Composer as an implementation of mashup technology.

    I’m still trying to understand the full landscape of the mashup world.

    In the Google maps mashup world, most mashups seem to overlay info onto google maps. It makes a nice base to build on. In the case of PLM, certainly geometry would be one possible base view to overlay on, but what would other be?

    Would something like make a good base for mashups?


  • Tom, I’m struggle with one fundamental problem in viewing Composer-like stuff as mashup. It’s not web and it’s going to create “another package of data”. So, on fundamental level, this is different from web mashups. But may be CAD/PDM/PLM/ need to be different. There are some folks that trying to re-define mashup for enterprise and claim this is more “data mashup”, compared to traditional web-client stuff. Regards. Oleg

  • I’ll respond to the question about Aras and Open Source. Oleg is correct that much of what Aras has done is about the business model.

    The other item not mentioned is the community that is building around the product, and the contributions of code from customers, partners, and users. One industry analyst I talked with a while back suggested that one of the measures of Open Source success is how much the community gives back. Aras has had a fair amount of code returned, and it can be viewed here:

    I don’t want to hijack this mashup discussion, if there is interest in persuing this thread, perhaps we can take it elsewhere.

    Oleg, would you entertain a blog on Open Source?

    Best Regards


    Oleg >>>> Guys! I have open source in the pipeline >>> I will move this comment there as soon as I will post >>>> Thanks, Tom!

  • Please don’t accuse me of over selling a DS tool but I think Composer is a very good example. Looking at the defintion, assuming wikipedia is accurate you will see it meets most of the criteria, and I said prototype…

    Definition states:
    1 WEB application – All Composer data can be presented via the web.
    2 Combines data – Absolutely.
    3 Easy, fast, and done throuhgh open API – Yes, unless DS has cahnged the license model.
    4 Create a new distinct enduser application – Again yes, you just need to decide what you want to do…

    What would be interesting is to concieve something you think users would find useful and then have the Composer gus try and put it together.

    A simple example would be the ability to navigate the PS (in the tree or in the graphics window), select a component and get a reorder code. OH and only have things you can buy selectable… Once selected what if the user wanted to get installation instructions, have a link to an overview of how to install the purchased item or nearby service centers.

    This is something VERY VERY simple to do in Composer.

  • Chris,
    with such point of view, I can say 3DLive is also mashup tool. Run over the web, combines/federate data, federate data with API and… create new distinct apps . It will be interesting to play around Composer and see how API can work on the Web.

    But in both examples – composer and 3DLive I have problem at the point application creation. The Composer and 3DLive apps conceptually works like mashup, but from technological standpoint far away from Web 2.0 – tightly dependent on their own data model, content aggregation happens inside of special application, there is no individual content (all is connected inside of application), no concept of resource and don’t use REST/XML as basic standards.

    In your example of PS navigation – what do you mean by “select component and get a reorder code”?

  • Yes I agree about 3dlive.

    Select a part in a tree or graphically and get information about how to reorder. Could be based on your location or any other info.

    Maybe I just cant think of one but mashups I think of certainly rely on their own data model. A user of something mashed up is not defining the data model.

    Composer is compliant with 2.0 because it is 100% XML! And it does not force any predefined datamodel.

  • thanks Chris. I will plan to play with Composer model and XML output to see what I can get out of there. You are actually continue to sell it quite well :)… ! – Oleg.

  • Take a look at what Arena has done with it’s mash-up/integration with Skype as well as the content databases at IHS. In both cases these are independent cloud platforms integrated with standard interfaces to access the other tools in the PLM environment. In the case of Skype, it includes presence detection and the ability to instantly form a group call or chat within defined groups (e.g. ECO change board)

  • Hi Mark, Thanks for comment! IHS is very interesting example in my view. What I knew is that Arena supported mashup of content from IHS components catalog. In my view it was sort of federation of IHS catalog information in Arena. Do you know examples where Arena data/content used to build applications in mashup style? Thanks! Oleg.

  • Pingback: PLM: Hug Your Data or Federate? « Daily PLM Think Tank Blog()

  • Pingback: Five Online Technologies for PLM in 2010 « Daily PLM Think Tank Blog()

  • bpmintro

    I approached your blog through this link:

    Since I am searching info about creating this link between the two with BPM methodology and technology, I also found your blog as a great source of ideas and opinions (comments as well..)
    I was curious to hear your opinion about Cordys solutions. For example:

    But my real concern is defining/designing the business process between Product Development Management and Supply Chain Management.
    There are reference models but I guess that in order to execute it you still have to define it with the people themselves…
    How do you suggest to approach it from the user view before the IT implementation?



  • Daphna, Thanks for your comment and link to Cordys. I know this company a little. I think Agile PLM is presenting is an interesting case. However, the devil is in details. To integrate multiple PLM systems is a very complicated case. I’d be interested to see it working and learn details.
    With regards to Product Development and Supply chain – I think the biggest problem is visibility and proliferation of data between multiple organizations and systems. The overall picture is very complicated. Companies are continuously spending a huge amount of money to make a data conversion.
    Best, Oleg