The ubiquitous future of PLM configustamization

October 30, 2015


Note – don’t try to Google for “configustamization”. There is no such word. I checked it already :).

Few weeks ago, I raised a question about PLM configuration and customization. You can catch up on my previous blog here. I found that “configuration vs. customization” semantics is quite dangerous and not always clear for users.

Lionel Grealou’s article – Customization vs Configuration made me think about this topic again. The article contains a table which gives you a guidance how to differentiate between Configuration, Extension and Customization. Read the article and draw your own conclusion. Honestly… I’ve got lost between variations of definitions. Sorry Lionel about that.

Here is my attempt to make a summary of 48 definitions from that table. Configuration is supported by product via some sort of user interface. Customization is everything that requires programming or altering of product code or database.

I disagree with some of conclusions. I think configuration is not always the most safe and easy way to alter product behavior. Although administration user interface is a safe pass to follow in order not to break a software, I’ve seen situations when administration tools fail and can even break a product. I can also confirm that sometimes, administration tool is a big time sucker (my best example is data modeling, data mapping and migrations). Sometimes, you can bet on code to deliver better results. The problem is not in configuration vs customization approach, but in product itself. A software product with flexibility in mind should provide a good balance between so called “configuration” and “customization”.

I can see some interesting trends related to ability of people to code these days. Code is getting easy. Tools are improving and internet provides lots of opportunities to learn. It is not unusual to see people learning to code in addition to other professional background they might have. I certainly seen it a lot among engineers working on CAD/PDM/PLM projects. Does it mean we should less worry about changing PLM product behavior using code?

Software is eating the world and some people think we might have not enough “coders” to go up to speed in the future. There are many articles about it online. My favorite one was Wired article – Should we really try to teach everyone to code? Here is my favorite passage:

Don’t teach everyone how to code. Teach them how to identify and understand needs, as well as how to visually express logic. Teach them how technology works, so they can understand the realm of possibility and then envision game-changing innovations. And then create an environment where they don’t even have to think about writing code — where building great apps is as easy as using iTunes. Just drag and drop. Once we remove the friction from building the next killer app, we’ll finally make the leap from a horse to a car. And then the innovation race will be on.

Let me back to PLM reality. Implementation is the biggest time waster in PLM. But technology is rarely a main problem to that. It is about current PLM paradigm that requires to map organizational reality to a model supported by PLM tools. Read more about it in my article – What is wrong with “analog PLM”? Majority of PLM products on the market today were created more than 15 years ago. It is long time for technology. For most of these products, “customization” means altering data model structures and accessing databases directly. I haven’t seen customers looking how to obtain source code and make changes. Maybe very large companies want that, but they are minority and vendors are taking special care of them. Coding directly into databases is a very outdated approach – most of modern architecture and technology paradigms won’t allow you to do so. Therefore, the only way to deal with configuration or customization is to work with API provided by software vendor. And this is shouldn’t be different from working with administration tools (also provided by vendor).

What is my conclusion? I think, “configuration vs. customization” debates is pure marketing. As a customer you should focus on the flexibility of PLM product and technology. Check what and how can be changed via user interface. Also check how to configure product using scripting languages – it can be a very good thing for IT administrators. Check what APIs are available and what languages are supported. Scripting languages are ubiquitous these days – you should be concerned if it doesn’t supported. So, chose the right flexible PLM technology, keep calm and ask PLM vendor to organize hackaton for people who wants to code more PLM. These folks will create a better UI for the best PLM technology in the market. Just my thoughts…

Best, Oleg

PLM: configuration v customization. Let’s sort it out..

October 6, 2015


Enterprise software customizations are painful. Remember my old post – Is PLM customization a data management Titanic? Nobody likes to customize PLM software, but all companies are doing that during implementations to some degree. You can catch up on my previous articles about that – How to eliminate PLM customization problem and How to de-customize PLM. The demand to eliminate the need to customize systems, but how is that feasible?

My earlier conclusion is that PLM vendors need to think how to make implementation cost effective and to support flexibility of PLM products and tools. It is especially important in the era of cloud computing and growing number of cloud deployments. PLM vendors will have to invest in technologies and methods to simplify deployment, flexibility and speed of implementations.

Jim Brown and Stan Przybylinski, both well known analysts in PLM industry, just released a funny video and serious interview on PLM customization. Navigate here to read more. Watch the video:

It brings up a topic of a difference between customization vs. configuration. It might be confusing. Where is the border between customizations and configuration? So, I thought, it will be useful to clarify things a bit and put it in a perspective of modern technological trends and development. Both configuration and customization are aiming to alter software product behavior. At the same time, there is a difference in two approaches.


In the old days of enterprise software, customization, assuming altering of software code. Customized product was deployed by customer. It took time and was expensive. In addition to that, future releases of the product potentially becoming incompatible with customized version.

For the last 10-15 years, enterprise software (PLM software included) developed ways to customize software using API and data modeling changes. For most of PLM products the trick was to use only approved API and not to hack data model using direct SQL commands injections. That last one was a grey area. Many customers did it, but not everyone will admit that guilt.


The term configuration means that system behavior will be altered using vendor supplied configuration tools. Some systems provided more user friendly UI for administration, which became important, especially for software integrators running PLM implementations for their clients. Configuration tools are provided by vendors and, therefore, vendor is taking care of future compatibility between releases.

So, "configuration" assumes that you don’t need to write "code" to configure the system. But it can be a bit complicated. Especially when it comes to APIs. What if API is provided by vendor?

APIs – the devil is in details

Application Programming Interface (API) became popular for the last two decades. The demand for openness, integration and broader platform development made vendors to invest more in API development. Many of these APIs are used by vendors and partners for application development and… customization.

Here is the thing. APIs are getting more popular and easy to use. For the last decade, development of scripting languages like Java Scripts and others made APIs a very effective way to configure and customize system behavior. A lot of them are used for automation and integration.

Web APIs and cloud technologies

Cloud brings many challenges to enterprise software configuration and customization. Many well known techniques (especially related to SQL and database customization) cannot be used. Databases are hidden behind web and application servers. Multi-tenant cloud systems are bringing even more complexity to support database level customization.

As a result of web and cloud technologies development, there is an increased demand for two things – 1/ Robust configuration tools provided by vendors; 2/ Web based APIs. Together, API and configuration tools need to support the demand for PLM system flexibility.

What is my conclusion? It is important to understand what is behind "configuration vs. customization" semantics. Even more, it is important to align customer requirements with the level of flexibility PLM product and technology can support. The demand to provide open, flexible and configurable systems that can configured using tools and wide range of APIs. All these options should be supported by a vendor. The development of web APIs and cloud based automation tools makes both (configuration tools and APIs) important for successful PLM implementations. Just my thoughts…

Best, Oleg

Image courtesy of blackzheep at

The end of debates about out-of-the-box PLM?

September 8, 2014


PLM implementation discussions are usually brings lots of controversy. Vendors, analysts, advisers, service companies, customers are all involved into implementations. It brings different and, sometimes, conflicting interests. In my view, one of the most debated topic in PLM implementations is related to so called ability to implement “PLM Out-of-the-box”. I’m not sure who first used that term. I think, it came out of PLM vendor marketing trying to demonstrate how easy and quick PLM implementation can be done. However, since then, the debates about “PLM Out of the box” had never ended.

Two other related topics are customization and configuration. For long period of time, I didn’t differentiate much between these two terms. However, modern enterprise software lexicon (and PLM vendors are in a full compliance with that) will define “configuration” (opposite to customization) a process that doesn’t require to write a software code for PLM implementation, but only use some elements of PLM user interface to configure a system. It probably turns all PLM implementation into “customization”, since writing programming scripts (using VB scripts or JS) is a widely used practice during all PLM configurations.

But let me get back to OOTB topic. I covered PLM OOTB few times in my blog. You can navigate your browser and read PLM Out-of-the-Box: Misleading or Focusing? published almost four years ago. From my latest posts, I can recommend you to take a read of the following article – Why My PLM won’t work for you? My attention was caught by an article that looks like trying to end all debates about PLM OOTB.

Aras Corp. published an interview with Dr. Martin Eigner who recently joined Aras’ board of advisors. In a very short published interview Dr. Eigner dots the i’s and crosses the t’s in the debates about out-of-the-box PLM and customization. Here is a main passage I captured. It has a strong Aras marketing flavor, but to quote it is important to bring a full message:

Dr. Martin Eigner: The kernel PLM functions are very similar from all competing PDM / PLM solution providers and from functionality it’s not a big criteria to differentiate each other. The user interface, performance and customization is important. Customization is very important because I do not believe even for small customers that you can buy PLM solution out of the box. That is a dream. You have to customize it. The real differentiator of existing PDM systems is the amount of money and capacity to customize a PLM solution. So I think usability, performance, upgrade capability and how easy it is to customize and maintain the customized solution are the most important points. They have the strongest impact on the total cost of ownership. I think in all these topics [performance, usability, upgrades, and customizations] Aras is leading. There are independent tests which show the system’s performance. We did internal tests at my university and found Aras to be the easiest to customize and upgrade. That is a big difference to the competitors. Customization is the most important aspect of PLM. Out-of-the-box works for no one.

I’m not in full agreement with Dr. Eigner about the fact you have to customize every PLM implementation. However, there is one point, which I think it is very important and I liked how Dr. Eigner emphasized that. It is related to the ability to maintain a customized PLM solution. This is one of the key differentiators of something I call a sustainable PLM platform. Customized legacy PLM is data management titanic in many implementations. Companies have to spend resources to maintain the solution, which is in most situation cannot support latest version of PLM platform provided by vendor.

What is my conclusion? Sustainable PLM platform. This is should be an important element of every PLM strategy these days. Modern business environment is very dynamic. Customer are looking for an agile way to implement business solution, adopt it to a new requirements as well as to maintain existing configuration. In my view, the concept of OOTB PLM should be revised with modern open architecture approach, which can simplify configuration, customization and sustainability of existing solutions. Just my thoughts…

Best, Oleg

PLM Cloud Customization and Online Code Editors

May 8, 2014


One size doesn’t fit all. It very true especially when it comes down to PLM implementations. Once released as a toolkit, PDM / PLM systems did a long way from a system that requires special software compilation to be done for every customers to the current system with flexible data models and tools allowing to configure and customize almost everything. Flexibility (in data model and code) is one of the most demanded characteristics of modern PLM systems.

Customization is also special territory in PLM business. It brings complexity and requires special attention. PLM vendors spent lots of effort to reduce the amount customization required for PLM deployments. However, after all, every PLM implementation requires services. Part of these services is related to customer requests to develop special functionality.

Cloud brings some advantages and complexity to PLM customization-ability. Specific aspects of cloud technology and customization can be different for public and private cloud deployment. Multi-tenant architecture can apply some additional level of complexity. One of the aspects of complexity can be usage of development tools on the cloud.

TechCrunch Disrupt NY presentation by Codeanywhere caught my attention. Navigate your browser to read more Codeanywhere, The Google Docs For Developers, Rocks Startup Alley At Disrupt NY. The idea of Codeanywhere to serve as universal coding environment available on any device is compelling. Look here for more features. I specially liked the ability to manage and store code in different repositories. You can connect to your favorite 3rd party services like Dropbox, Github, Google Drive as well as move files and folders between services.


I have to say that Codeanywhere is not the only provider of coding environment in the cloud. Navigate here to see more tools available. My attention caught service called Runnable. Note, the broad support of languages and tools – C++, Java, Rails, Node.js, JQuery, PHP and more.


Cloud code environments made me think about the opportunity integration (or even embedding) of such type of development environment into cloud PLM platforms. It can provide unmatchable capability to customize PLM systems regardless on location from both sides (customer and developer). The result – low development cost, flexibility to chose the location of service providers and lower customization expenses for customers.

What is my conclusion? Cloud puts some constraints on PLM system customization. To choose special and effective tools can be a game changer for efficient customization. Risk of broad errors and complex multi-tenant constraints raises the need to create a special customization environment. At the same time, cloud is an excellent opportunity to lower the cost of PLM customization by optimizing the overall customization process and, as a result of that, lower expenses. PLM service providers can work from remote locations as well as have much simpler way to re-use customization. Just my thoughts…

Best, Oleg

pic credit – and runnable

Six dimensions to customize PLM

April 24, 2014


Ask two engineers about how to make stuff and you get at least three opinions about possible ways to do so. To find consensus in engineering, product development and manufacturing is hard. From my experience engineers and software developers is the group with largest diversity of opinions and custom requirements. I’ve learned it hard way implementing and developing PDM / PLM software. Large manufacturing companies are better organized and leaning towards well-established business processes and polices. PLM vendors are using so-called "business transformation" approach to implement PLM for large manufacturers. It proved to be efficient for many companies (not only largest OEMs, but also smaller companies). However, the TCO of existing solutions is still too high. It is very hard to convince small company to implement PLM. In addition to that, smaller companies are less influenced by corporate hierarchy, business processes and IT system governance. I put some of my thoughts about that here – Why PLM stuck to provide solutions for SME?

Software vendors and service providers are facing the problem how to customize PLM for large and diverse set of requirements. Software toolkit was the first way to solve customization problem. Only very large customers accepted toolkit approach. It was complicated and costly. The next answer provided by PDM / PLM vendors was flexible data modeling and configuration. Most of modern PDM / PLM software suites are providing set of configuration tools to do that. Nevertheless, PLM implementation is still long process taking weeks or months. In many situations, it still requires some customization to be done.

Vendors need to find another way to customize PLM system. Current customization approach is mostly focused on a company – industry, size, processes. It made me think about another way to customize the system by focusing on a specific user in a company. I can see some of these ideas in role-based and out-of-the-box approach in developing of enterprise systems. However, I can see it different by stepping down from holistic company-wide customization towards specific user-oriented goals. In other words, company was the customer before. Now, it is about individual users.

Below, I summarized six dimensions of customization that can help to identify customization directions.

1- Who. This is very similar to role-based approach. It can help to identify specific key people and their everyday needs. List their functions and pains. What is specifically different for each of them. How to personalize apps / service for every individual.

2- What. This dimension speaks about specific function. How to customize the system to a very specific operation. What do customers do differently with the system. Go to the level of person (not department)

3- Where. This is a dimension that helps you think about customized locations. How is your system different for every place. How customer can do the work everywhere and how is that different. How to provide system wherever customer wants.

4- When. There are two major aspects here – how to make system available 24×7 and how to make system available instantly (by eliminating long implementation cycles and preparation).

5- Why. One of the most critical customization factors. Why user needs your system? How to provide ROI and make system stick? How to add more value for every specific user and not "in general" for the company.

6- How. This dimension is about customization factors responsible for how to delivery the product to different customers. What delivery forms to use. How my customers are different and how to satisfy customers in every way.

What is my conclusion? Today, company policies, business practices and organizational structure are factors that impact the way PLM vendors are customizing their software. Nothing wrong with that approach. Future customization can move from holistic "company" wide customization towards specific "customer" (read – user) needs. PLM software should be more personal and, by doing that, to attach to specific user functions in a very unique way – to provide value, be available everywhere, anytime and in any form. This is a future for truly customizable PLM software. Just my thoughts…

Best, Oleg

How to eliminate PLM customization problems?

March 28, 2014


I’m following strategic visions of the major PLM vendors 2014+ publication by Jim Brown – well known analyst and my blogging buddy for last few years. It started as a publication covering Autodesk, Dassault, PTC, Siemens (vendors listed alphabetically). Last week, Jim expanded his PLM vision publications by adding Aras Innovator to the list. Navigate here to read about Aras 2014+ vision. Aras is well known by their Enterprise Open Source strategy. One of the interesting differentiation I captured in Jim’s article is related to Aras’ strategy to break rules of PLM customization. Here is the passage:

Aras has decided to break the rules [of PLM customization]. They aim to become the PLM company that defies the conundrum, allowing manufacturers to customize their software and still upgrade to future releases without major disruption. They can do this because customers can update the data schema, business rules, workflows, and forms without jeopardizing the integrity of the system. How does this work? Aras’ XML-based, model-oriented approach coupled with their willingness to provide customers with the business flexibility and tools to make it feasible. Aras has effectively morphed themselves into a PLM Platform with solid core functionality with a built in ability to be extended by customers and partners. To put this strategy into action, they have told me they are “putting their money where their mouth is.” They now include upgrade services as a part of their subscription service. I haven’t seen that from anyone else anywhere, particularly while encouraging people to enhance and modify the package. This is a clear differentiator and makes Aras unique in the PLM market.

PLM customization is a tricky deal. Honestly, nobody is dreaming to make PLM implementation with zero customization effort. It all starts from flexible data modeling, which imply certain level of data customization. Time ago, I posted – Is PLM customization a data management Titanic? Earlier this year, I’ve been discussing options and reasons on How to de-customize PLM? The story of PLM customization is tightly related to PLM system flexibility data modeling. Typically, every PLM implementation contains some portion of customization that usually done by service organization and/or internal IT department. Lifecycle rules, data import, workflows, integration with other enterprise systems – this is only a very short list of customizations done during PLM deployment. Another huge aspect of customization is related to system upgrades. That one is actually mentioned by Jim Brown in his Aras’ review.

So, is there a way to solve customization problem? In my view, the answer is – it depends. In my view, you cannot eliminate specific implementation activities. Adding of new features and infrastructure technologies (eg. RDBMS) will require certain upgrade activity to happen. However, if you are selling services, the interest will be to optimize this work. Cloud vendors have similar incentive to optimize infrastructure upgrades and maintenance, otherwise operational cost will go up. So, smart technology can optimize cost and customization efforts.

What is my conclusion? Business and technology are going together. To have good business incentive to optimize technologies is always helpful and can put pressure on development organization to optimize cost of infrastructure upgrades. Service based offering (open source and cloud) are two great examples where business interests of vendors and customers are going at the same direction. Just my thoughts…

Best, Oleg

How to Decustomize PLM?

December 24, 2013


Customization is one of the most favorite topics in PLM. Back 20-30 years ago, product data management (PDM) was born as a toolkit. Earlier PDM implementations took months and required deep changes in PDM system code and behaviors. It was leading to a growing complexity of implementation, highly sophisticated implementation skills and time. What is even more important and dangerous it was a reason many PDM/PLM implementations stuck in the back and failed to upgrade to newer versions of PLM software. I expressed it in one of my old articles – Is PLM Customization a Data Management Titanic? My guess back in 2010 was that future flexibility of data management technologies should make future customization and updates easier.

Customization problem exists in other domains of enterprise software. I found an interesting example of how extensive customization can damage enterprise software deployment and implementations. CMSWire article 6 Predictions for SharePoint, Office 365 in 2014 speaks about adoption of SharePoint 2013. One of the prediction speaks about SharePoint customization or actually… decustomization. I found this passage interesting:

We’ve heard Microsoft strongly suggest not to customize SharePoint, that branding doesn’t improve user experience or make processes better. That migration to new versions is easier without a lot of customization. The new SharePoint 2013 app model is also a strong pointer from Microsoft to keep SharePoint as out of the box as possible and focus on using Apps for additional customizations.

I think this is a good thing. Many of the challenges we see with migration projects are the result of branding and customizations — some of which may not have been necessary. Part of the reason SharePoint has been customized in the past is that developers are learning to use the platform and trying new things. The new App model reduces much of this, putting the testing and learning outside of SharePoint directly.

It made me think again about PLM implementation and customization projects. For the last decade, PLM vendors put a lot of efforts in developing of out-of-the-box offerings and strategies. Marketing used different names for this activity – from "express solutions" to "industry offerings". In my view, the result was somewhat mixed – it simplified PDM implementations and some smaller PLM deployment. At the same time, many even relatively smaller PLM implementations are still far from go simple way. In my view, the best confirmation to that is growing interest in acquiring service and consulting companies by PLM vendors. The last one was Siemens PLM acquiring TESIS PLMWare focuses on PLM integrations.

What is my conclusion? Decustomization of PLM will be one of the most important elements in the future PLM infrastructure improvements. To make implementation cost effective and to support future cloud deployments, PLM vendors will have to invest in technologies and methods to simplify deployment, flexibility and speed of implementations. Just my thoughts…

Best, Oleg


Get every new post delivered to your Inbox.

Join 290 other followers