Product Lifecycle Management (PLM) vendors promise their systems to be so great, they can be used by organizations from the get-go, revolutionizing how they define and manage their product data. However, that is the case only for those organizations who are willing to adapt their own internal standards and procedures for the sake of pre-implemented best practices within PLM systems. All others must rely on configuration and customization. What is the difference between them and how to make sure they don’t end up being (risk, downside, weakness?) in the future? Read on to find out.
OOTB
OOTB, or “out-of-the-box”, is the set of functionalities available to users immediately after installing a system. In case of a PLM system, OOTB means a group of pre-defined elements, such as:
- Standard user interface, with browsing and searching capabilities
- Data model (object types, their attributes/parameters)
- Lifecycles
- Workflows
- Object templates (including Product templates, complete with role and security definition)
These are, especially in the case of larger and more mature PLM systems, such as PTC Windchill, created based on certain industrial standards and best practices. They were defined jointly by their creators and some of the brightest minds from worlds’ best universities, but also actual customers, through many years of system usage and hands-on experience. Some things which initially were considered custom in the system have gradually made their way into the core product, becoming “OOTB”.
Most software vendors boast their software as being ready to handle any challenge for any company “out-of-the-box”, but very few are true to their word. Think: an office software suite, including a word processor, spreadsheet editor, presentation editor, etc. These will work similar regardless of who made them (OK, there may be some slight differences in the User Interface (UI) or the kinds of animations you can use, but the general “feeling” is the same).
In case of PLM, however, there is no “one size fits all” solution. It is very unlikely an OOTB (or “vanilla”) system can be utilized effectively within “just any” organization. Especially larger and/or older companies have their developed working methods, which have proven to be effective and should not be changed to fit the system – rather the system should be changed to fit these methods. What data and meta-data we consider important and decide to store in a PLM system also changes from organization to organization, as do roles and access control rules assigned to them. These and many more things usually need to be changed in a “vanilla” PLM system before it becomes truly usable to an organization, and this is where configuration and customization come into play.
Although these two terms sound similarly, they are in fact significantly different in meaning. Let us start by defining what these two are – in as simple terms as possible.
What is configuration?
Configuration (in a PLM system) covers all the changes you can do to a product from the User Interface perspective. PLM vendors usually include configuration tools, allowing you to change the system behavior to a limited degree. This includes such things as:
- Changes to the data model, including definition of new object types and attributes describing them
- Definition of Lifecycles and lifecycle states
- (partly) definition of workflows
- Definition of object templates (Product, Library, etc.) – including roles within containers and access control rules definition
- System behavior management through preferences
Some people also include potential modification of system property values (in case of Windchill: changing the open-text values inside .property files) as configuration, but for the sake of clarity let’s not include this into this category at this point.
In other words, configuration is a system modification that does not require access, modification, implementation, etc. of the system’s source code[1]. For this reason, many people also consider ability to configure the software (and thus configuration itself) to be an integral part of OOTB functionality.
Configurations are generally supported between system versions, so if you upgrade your PLM system, you usually don’t have to worry about upgrading configuration to fit a newer version.
[1] Yes, configuration can usually be exported from a system (for the purpose of importing it to another instance) and then it does take the form of XML or other files which may contain code, but you don’t have to actually “touch” that code: open a text editor and write anything. You just “export” it and “import”, without actually looking inside those files.
What is customization?
Customization, on the other hand, is everything above and beyond configuration. Customization is any system change which requires modification or extension of the system’s source code (i.e. implementation, development), because the desired result cannot be achieved through configuration only. In most cases, customization examples include:
- Listeners (triggers that fire a certain action/system behavior when a given event happens, for example auto-publishing on Change Notice completion, etc.)
- New user actions and wizards
- Workflows (some cases) – Windchill allows you to write code, so when you want to do some custom processing while running your workflow, you can
- System integrations – I’m sorry to say, but almost all system integrations for PLM are custom
- Some cases of advanced business reporting
- Various implementations of additional business rules
Although this does not exhaust the list of possible customizations. Through my years of working as a Windchill developer, there’s much I’ve seen people do with the system in terms of introducing new/custom features… and there’s even more of what I haven’t seen so far…
Software systems, PLM included, usually have their own lifecycle and get upgraded by their vendors from time to time. PTC Windchill is no exception here, with a roadmap detailed for a few years ahead. When upgrading your system to a newer version, you should never assume that your customization will work properly. System vendors introduce upgrades, changes and so on to their core products, which may render some customizations unnecessary, but also some portions of them can address pieces of code which no longer exists (or functions as it did earlier) in the core product – which can wreak all kinds of havoc on your PLM system. Each system upgrade with customization present should consider effort needed to verify the customization’s compatibility with the new version and (if necessary) its upgrade. For comparison, an upgrade of a “vanilla” system can sometimes be completed within hours. If complex and extensive customizations are present, it can be months, or even years (yes, I’ve seen such cases).
What is the difference between configuration and customization?
As you can see, the main difference between configuration and customization is that the first can usually be achieved via system UI, while the latter requires programmers to code new/changed functionality. Unfortunately, it’s not as simple as that.
Configuration, even if exported into a set of files (for the purpose of deploying in another system) is usually relatively easy to manage: Simply track the list of changes you did and never manually modify exported files[2].
Customization, as with most things programming, can be (and usually is) much more complex and should be managed appropriately. Otherwise, deploying it will result in a system full of bugs and errors, or even not starting at all (!), rendering it unusable and thus a big waste of money and effort.
[2] This would be the case in an ideal world. In the real world you do sometimes have to modify configuration files, which are usually XML. Still, by doing so you are not affecting the code of the core application.
How do I know whether customization is needed?
No system or solution could possibly be designed to ideally serve all customers across all industrial verticals. In many cases customization will indeed be inevitable. Even as common a case as feeding information from your PLM to your ERP system upon “Release to Manufacturing” will require customization in the form of a system integration.
As a PLM system customer, you should not be required to know all the ins and outs of PTC Windchill, Siemens Teamcenter or anything else out there. Trying to learn all the intricacies and important bits may take years, which your organization may not have.
Therefore, you should rely on two things:
- The system vendor – after all, whoever makes a system should know it best (assuming his representatives are truthful when describing what a system can and cannot do OOTB and through configuration)
- Independent partner, System Integrator, Value Added Reseller, etc. – such as Transition Technologies PSC – who can help you evaluate your needs and help you define what can
A partner should be your best asset when implementing a PLM system within your organization. Through years of working with other customers, such a partner should have gained deep understanding of tools he is working with and can not only tell you whether a system can act as you want it to, but also potentially advise on whether it’s actually a good idea to abandon its functionality and develop your own.
How should I manage customizations?
Software Development and System Operations, often referred to as DevOps, can be quite a complex topic – also for Product Lifecycle Management systems. If I went into details here, this would turn into an entire article on DevOps best practices for PLM, so I will cut it down to necessary details here:
- Use a version control system for your source code (ideally Git or equivalent)
- Use a system like Atlassian Jira or PTC Windchill RV&S (former Integrity, as an Application Lifecycle Management [ALM] system) to track development progress, tasks, issues, user stories, sprints, etc.
- Tightly integrate the two above so that no one can change anything in the repository if he’s not working on a specific ticket.
- Use automated tests for any custom code (at minimum unit tests).
- Use automated environment creation (if possible – greatly simplifies and decreases effort and time) and build deployment tools like Jenkins.
- Tightly integrate automation tools with tests, source code and the ALM system.
- Use multiple validation environments (for example: programmers code in a Dev system, testers test on a Test system, final user acceptance testing is done on a QA system – and finally, nothing is changed on production, unless part of an official release schedule, tracked, managed and validated)
I can pretty much bet that if a system uses customization, it also has configuration. In that case configuration, once exported from the development system, should also be managed as part of the process above – this will ensure an entire system deployment is coherent and smooth, and any and all issues are detected and resolved at an early phase.
Obviously, the process above is simplified… significantly. Even so (or maybe because of that), some organizations decide not to follow it and take high risk when developing PLM customizations. From what I’ve seen, this always ends in a disaster[3], so if you want to avoid being part of that disaster, please make sure your PLM service provider applies proper DevOps techniques before it’s too late.
[3] Yes, always. Sooner or later, but always.
Configuration vs customization
After reading what you’ve read so far you may think you want to steer clear of customizations of any kind: they are often complex, risky and costly. That is largely true: what can be achieved using an OOTB product with some (even much) configuration, should be done that way. After all, most PLM vendors try to incorporate as much flexibility into their products and solutions as possible, so you don’t have to customize.
However, please keep in mind that even the best PLM system will not have all the features working exactly how you’d like them to, and thus will require some modifications. If a PLM salesperson ever tries to convince you that his PLM product will fit your (and every other business) perfectly from the moment you install it, show him the door.
Is there such a thing as too much customization?
Yes, there is. I’ve seen projects with over a dozen thousand custom classes, varying from a few dozen to many thousand lines of code. It was manageable, but barely. Managing dependencies between various packages slowly became a nightmare and tracking an issue to a change in requirement and piece of code developed by a particular person was almost impossible. Testing and debugging the solution required weeks, if not months, before every release.
Then came the system upgrades, which changed the core code of the system which was customized…
(Needless to say, any hopes of upgrading that system before severely decustomizing it were abandoned.)
Nowadays, vendors release new system versions more frequently than ever. Just like with physical products, for software Product Lifecycles also shortened to a point where some versions are fully supported for only a few months. Customers must now decide whether they want to use the latest features (and upgrade frequently) or install a long-term support (LTS) version. Of course, the more frequent the upgrades, the more time needs to be spent on ensuring that configuration and (especially) customization continue to work as expected.
Not all is lost, though, if you indeed need to heavily modify your PLM system. There is a way to manage and maintain even extensive and complex customizations: DevOps. This concept, if implemented properly, greatly simplifies many processes and helps maintain high quality of a solution even if significant modifications are introduced. It does not solve all challenges, but it helps. A lot.
Can I customize a cloud-hosted PLM system?
Yes and no. Let me explain:
If you decide to purchase your PLM system as a SaaS (Software as a Service) offering, then the vendor of the system takes care of all the back-end work: setting up servers, installing and maintaining the system, performing upgrade, etc. However – you as a customer rarely (if at all) are going to get access to the actual operating system (OS) on which the PLM application is running. Since you don’t have access to the OS, you won’t be able to deploy your custom classes / code. You will have to rely on a SaaS provider for any change deployment. Some providers require lengthy and cumbersome processes to deploy even the smallest change, so select your partner carefully and ask them about their deployment procedure.
This second approach requires significantly more effort, not to mention deep knowledge of cloud solutions, especially if you want to achieve a satisfying level of automation. Luckily, this is where you can rely on your PLM partner to help you out. See for yourself how you can achieve SaaS-level automation (or more!) and peace of mind while leveraging the public Cloud to host your Windchill system, based on a real-life example from the automotive industry:
Conclusion
Although it might be easy to say that you should avoid customization at all cost, in the PLM world there is no “one size fits all.” While some organizations may indeed benefit from using an OOTB PLM system, it’s hard to expect many of them to let go of their principles and working methods – things that made these companies so great in the first place. While it is true that you should aim at minimizing customization, even large ones can be managed efficiently if a proper process is applied. Ultimately deciding whether to go with configuration or customization (or even a particular PLM product) should be an informed decision based on your organization’s true needs and requirements – in best case supported by the breadth of knowledge and experience of a trusted partner, who can later execute on the plan. Contact us!