Will “cloud” change the way we integrate PLM and ERP?

Will “cloud” change the way we integrate PLM and ERP?


Integration has a very important role in PLM implementations. PLM is intended to manage design and engineering aspects of product development. ERP is intended to manage manufacturing resources, process and inventory. Therefore PLM and ERP are complementary. Most of PLM implementations I’ve seen in my life, required PLM-ERP integration.

At the same time, PLM-ERP integration is often the most complicated part. There is high diversity in the ways manufacturing companies manage data about product, bill of materials, parts, inventory and manufacturing processes. Outcome is multiple BoMs, product and item records and the need to synchronize information.

Traditional PLM-ERP integration is complex and never done out-of-the-box. It requires detailed definitions, data mapping and variety of data synchronization techniques. The last one is usually code effort that done by service provider or IT programmers. In some situations PLM and ERP vendors are offering integration tools, but because of different reasons such as cost and complexity of these tools, integration often end up as SQL hacking into two databases of PLM and ERP. Software vendors are not appreciating this approach, but usually face the reality of large implementation complexity and just live with it. In most of these situations, vendors would not jeopardize PLM deal by preventing customers to access databases directly. The result is high cost of maintenance and problem during upgrades.

Cloud technologies are simplifying IT and deployment. But, at the same time, cloud can create an additional integration complexity. Traditional integration code, including SQL often not applicable without direct access to databases in web environment. But cloud environment is still very complex. It contains PLM, ERP and many other systems and services companies are using. Few months ago, I shared my thoughts about how to avoid cloud integration spaghetti. One of the biggest dangers is that closed data paradigms and data duplication between silos can bring well-know data spaghetti from on-premise applications to the cloud.

For the last few months, I’ve been learning about what cloud PLM companies are doing to simplify cloud PLM-ERP integration. I wanted to share some of my thoughts about it

Autodesk PLM360

PLM Connect is a complete solution portfolio provided by PLM360 integrate business systems. First of all, it applies to PLM-ERP integration, but not only. Earlier this year, at  PLM Accelerate 2015 conference in Boston, Autodesk promised to integrate PLM360 with everything. PLM360 is using Jitterbit middleware for integration.


In addition to that Autodesk seems to be inspired by IFTTT -like tools announced “evented web” integration for PLM360. Read more here.


From the side of Jitterbit, it looks similar to traditional middleware. The fact it runs on the cloud doesn’t change much. But it has nice UI for integration and mapping. Also, granularity of REST API and ease of code can potentially make PLM360 / Jitterbit environment more efficient. Evented-web integration style has advantages, but it is not clear to me how effectively it can be used to synchronize data between PLM and ERP environments.

Arena – Kenandy integration

I’ve been learning about Arena PLM integration with Kenandy ERP. My attention was caught by the following article and Arena-Kenandy partnership press release. You can get some details about the integration by navigating to the following data sheet.

I spent some time looking into specific ways integration is done. Arena and Kenandy is not using middleware style integration. At the same time, both are supporting modern web based APIs to code integration behavior. Which allows the both solution to leverage service APIs on both sides for efficient and granular data integration. Arena and Kenandy is synchornizing data by transferring XML documents.


Administration console can show you status of data synchronization.


In my view, Arena-Kenandy is a modern variant of point-to-point integration with realization using Web services API. It makes code easier, but still requires implementation of synchronization logic between systems.

Razorleaf – Clover Open Integration Platform

Companies doing implementation services for PLM usually have high sense of urgency to work on PLM-ERP integrations. It is part of their implementation schedules. My attention was caught by Razorleaf announcement yesterday about Clover Open Integration platform. Read more here – Razorleaf Introduces Clover™, a New Open Integration Platform that Supports Any-to-Any Endpoint Integration for PLM Applications. The following passage provides some high level explanation about what Clover does.

“The Clover platform is a result of our long-standing experience in creating CAD/CAM/PLM integration endpoints,” stated Eric Doubell, CEO of Razorleaf Corporation.  “We now have created an industry standard application integration platform that has a flexible architecture and can scale easily based on its endpoint applications.  This platform helps our customers retain the feature sets they have come to rely upon in their application investments and allow for a more controlled migration path forward when upgrading is a requirement.  Making up-to-date data available across applications accelerates decision-making and process efficiency across the organization.”

Razorleaf is providing services for different cloud and on premise PLM environments. Learn more here. You can see on-premise and cloud systems including Autodesk PLM360 and Jitterbit. I’m still learning about Clover technology and platform. So, stay tuned for updates.

What is my conclusion? Cloud brings some limitations to integration techniques. Very often integration was done using direct SQL-code injections and batch processing. You cannot do it anymore in cloud-based / web environment. Web based APIs can compensate it, but it requires products to support granular REST APIs for specific operations. This is something you want to be sensitive to when choosing cloud PLM vendor. Web API can make cloud-based integration easy to code and implement. However, cloud integration patterns are still the same – middleware or point-to-point integration. Cloud didn’t bring anything new here. At least from the standpoint of systems I learned. Integration remains complex and requires planning and resources during PLM implementations. A note or PLM architects and strategists. Just my thoughts…

Best, Oleg


Share This Post

  • Jonathan_Scott

    Oleg, very nice article, and thank you for noticing Razorleaf’s new Clover platform. As you described, there is not much new in the world of integration – “point-to-point” and “middleware” are still the main two strategies.

    From my perspective, what can help simplify integrations is a deeper understanding of the relevant data. It is hard for some legacy tools to participate as middleware in PDM/PLM integration scenarios because a lot of coding must be done to deal with complex behaviors like history, security context, and product structures.

    I think there is something to be gained when the integration platform has a richer vocabulary for PLM concepts. This is one of the things we are trying to bring to the table with Clover, because we feel it is needed by companies today.

  • beyondplm

    Jonathan, thanks for your comment! You are right – legacy systems are hard to integrate and most of PLM tools today with very small exception like PLM360 were developed 15-25 years ago. Even Arena was developed back in 2000. The complexity of data is another reason why is it hard. But I have to mention one more reason – absence of strong business case. It doesn’t mean, there is no support or need for integration. But value created by integration cannot be captured. Even more often easy integration between enterprise (or legacy and new tool) can go against business interests of some vendors. I’ve seen many examples when decision about software replacement was taken because of complexity and cost of legacy systems integration. This is might a topic for a separate blog post. Let me think about it :). Best, Oleg

  • Olaf Schmidt

    I have the impression that in Germany “Cloud” is a NO-GO at the moment. Companies hold their data close to the chest and do not trust or are allowed to let their data leave the company’s servers, let alone the country (by using a cloud service, which servers might be located anywhere)
    Is the situation different in the United States?

    best regards

  • beyondplm

    Olaf, thanks for your comment! From what I know, Europe (and specifically Germany) is more conservative with regards to usage of cloud software. There are specific regulation and requirements. Companies are moving towards cloud software, but not as fast as in U.S.

  • Jonathan_Scott

    Oleg, value calculation for software projects is notoriously tricky, I agree. In the case of the financial value of PDM/PLM-ERP integrations, I have seen some straightforward calculations though. For example, we deployed a one-way BOM synchronization tool from SmarTeam to JDEdwards for a client who paid for the project by reassigning two clerks who spent all day converting BOMs on 2D drawings to Excel, routing the Excel for markup, and then entering the Excel into ERP (by hand). The project paid off in salary savings in under 1 year, so the value was clear. Of course, not every case is so clear, but I think integrations can have clearly defined value when data sync is being done by hand.

  • beyondplm

    Jonathan, I agree- if you can come with such case, the value is obvious. However, you speak about integration services, which is a bit different from selling software for integration. The cost software is high and each and every use case can be a bit different. So, to capture an obvious value of special integration software is tricky. At the same time, for PLM and ERP products, integration module value is not clear (especially because service provider like Razorleaf can do the job :)).

  • Jonathan_Scott

    Oleg, I disagree that integration services are different from selling integration software. In my view the customer has a problem that is costing them $X. If someone (service provider, software vendor, combination of those, etc.) can offer to solve that problem for less than $X, the decision is clear. So I don’t see much difference between services and an off-the-shelf package (except calculating the TCO of those solutions is not always simple).

    However, I still agree with you that in many cases the value of integration projects and software is not obvious and is difficult to calculate. When I connect CRM to PLM to multiple ERPs, which department wins? How does it impact day-to-day efficiency? These are not simple questions, even though all stakeholders may agree that this integration is “helpful”.

  • beyondplm

    Jonathan, you are right for the situation when you can define $X. The challenges is that there are multiple ways to deliver integration and define its cost.

    One option is to deliver integration as a service from service provider like Razorleaf. You can use API available for PLM, CRM, ERP or just go and write code which integrates with database. The cost of this solution will be 100% defined by service provider.

    Alternative, is to use “PLM integration software” provided by vendor. Then solution cost will be combined from license + services (I assume, there is no out-of-the-box integration). It is not obvious to me that the second will cost less for customer. And service provider will get less service revenues.

    Would you (as a service provider) prefer not to sell integration software license from PLM vendor and just provide integration as a service offering?

  • Jonathan_Scott

    Oleg, I think a third option is to use internal resources to connect systems using “PLM Integration Software”. Of course, there is an “internal” services cost here as well. In all cases it is important to calculate total cost carefully because you are right that it is not obvious which model can be the least expensive.

    The calculation of total cost leads directly to your question about my preference as a service provider – to provide services on top of integration software or to provide fully custom solution. In my view, it is better to leverage existing tools (PLM integration software) than to write new connectors every time, even if that seems to imply lower revenue for my company. Despite that economic disincentive, I think it is the right choice for the customer (when the choice exists).

  • beyondplm

    Why would you agree to lower the revenue for service provider? Btw, in the past, it was not obviously the solution with lowest TCO. It might be different in cloud environment, where options to develop point-to-point custom integration by service providers could be limited.

  • thendral

    Thanks for sharing the details and explanations..I want more information from your side..I Am working in Erp Development Companies In Indiashould you need for any other clarification please call in this number.044-6565 6523.

  • beyondplm

    thanks for your comment!

  • Late to the party here, but this is less about conservatism and more about nationalism. The majority of cloud offerings are from US companies, it should be no surprise Europe would be willing to hand the keys to their data, so to speak, to companies with interest in the US and influence by the US government. Imagine if it was reversed, if Amazon for example was a German company. Think the US would embrace that technology as quickly?

  • beyondplm

    Ed, I would call it regulation. Governments are beyond corporations. So, EU regulation sets rules. As far as I know cloud software companies (most of them) are trying to follow, otherwise they just cannot sell in EU.

  • Thanks for sharing.. Keep Updating..Post your nearest city events and festivals in campus.events website. Online Event Registration websites | campus events

  • Pingback: new blog: Will #cloud change the way we integrate #PLM and #ERP? b ... | managed cloud hosting()