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.
Customization
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.
Configuration
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 FreeDigitalPhotos.net
