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
