Top 5 API Mistakes in PLM Software

Top 5 API Mistakes in PLM Software

In any enterprise software, there is a point of time we are asking the following question – “what APIs are supported?” We anticipate the need of API in order be configure, customize, tailor, change, adapt, etc. Use any marketing wants, in the end you’ll need an API to be able to make the software finally works in the way you want. APIs provided by software define a level of flexibility, and this is one of the important characteristics you need to take into account.

The “10 common mistakes by API providers” article on ReadWriteCloud made me think about mistakes vendors are making when designing and providing APIs. I decided to put my top 5 lists of typical problems I’ve seen in APIs for CAD, PDM, PLM software. I believe, this list is not unique in CAD/PLM and may represent some general trends as well.

1. Complexity of data and API structures
The simplicity of API is one of the most important characteristics. When it comes to complex products like CAD or PLM, a very typical problem is a high level of complications in API functions, dependencies and data structures. The level of knowledge required to work with API is growing enormously and the potential for bugs and mistakes is growing too.

2. Late availability compared to software release
This one is representing a painful situation when APIs becomes available only in the “next version” of product. Normally, it represents a lack of maturity in product functions. It often happens in a situation when a vendor is releasing a new version and anticipate function changes in the next version.

3. Inconsistency with core product functions
Another very painful situation when a product from a user standpoint behaves differently compared to API. It normally happens when development organization is inconsistent with regards to planned functions and API. The involvement of different teams of developers , separation of user-functions and API-development may cause these situations.

4. Not Stable APIs and Lack of Backward compatibility
When you customize software for customer or develop your own application you want to minimize potential problems when new version of software is coming to a market. An ability of software to support a stable set of APIs between releases is a very important characteristic. Not stable API can jeopardize a new version deployment or a new release of your software. This is a very complicated issue causes a lot of problems.

5. Lack of tests
There are software vendors consider developers a cheap workforce to debug a new software. I can see a higer probability to see an API problem, compared to user function in the same product. It can be prevented, in my view, via increased usage of own software API for internal development. In addition, it often happens when API considered as an “addition to software” and developed separately from core functions.

There is one more thing. Availability of API. I didn’t put it in the list for several reasons. Sometimes, CAD/PLM vendors are making decision to protect some aspects of their software by restricting APIs. This practice more related to business strategy and cannot be considered as “API mistake”. This is another problem that often happens and needs to be taken into the account.

What is my conclusion? The amount of revenues in the market of engineering software related to services, and customization is very high. For different segments, it approaches 50% and even more. APIs is a core fuel behind these revenues. Consistent, stable and simple API is an important characteristic of every successful product in this market. Just my opinion.

Best, Oleg


Share This Post

  • So true.

  • beyondplm

    Alex, thanks! Agree, sometimes is so painful. Best, Oleg

  • Loic

    Hi Oleg,
    a simple mind. API are often the keys for starting customisation of a solution. Sould the design of a PLM solution start from the design of the API?

    Do you think it would be possibe to design a PLM solution that suppost data-model, and only provide API to self-implement the processes ?
    The provider of such a solution would propose his own implementation of processes, of visualisation, as well as other entreprises could do…

  • Paul

    If PLM vendors wrote their software to be API (SOA) driven from the start then the consistency would be there. Unfortunately, most of the big PLM software suites (Teamcenter, Enovia, whatever PTC call it this week) are actually pretty old under the skin and have had web ‘stuff’ grafted on – but you don’t need to scratch too hard to see the unfriendly underpinnings.

    Plus – lets be honest – why would they expose nice neat APIs? Then you can do your own development without their help….

  • beyondplm

    Loic, thanks for sharing your thoughts! I think, the idea of data+model+API=PLM system isn’t new. About 10-15 years ago, PDM systems were designed as a toolkit combined of these components. However, in my view, it is not good for many reasons. It assumes users need to take a very long implementation cycle and handle it (or ask SI organization to do so). I believe PLM tools need to provide a good balance between flexibility (including API and ability to be configured) and pre-defined functionality. Just my thoughts… Best, Oleg

  • beyondplm

    Paul, thanks for commenting! I think, you made right analyzes. When systems passed over multiple changes and updates, the underline API can be so different from external functionalities. The second topic is pure business, in my view – to provide or not APIs. Each vendor needs to decide it based on their business model. Just my thoughts.. Best, Oleg