Configuration Based PLM Implementation

Presently configuration based Software development is highly desirable and demanded by client. PLM products are coming with high level configuration with the aim of reducing the solution cost to client. But in most of cases in PLM domain client have some way or other unique feature which can’t be satisfied with configuration and some customization required to be done. Client prefers to have custom solution developed so that future changes can be incorporated through configuration rather than new implementation and the solution can be reused in similar requirement situation. This can reduce the future cost to them. In this blog I will discuss different way of configuration in Teamcenter and balancing between configurations driven development. As overloaded configuration based implemented may kill the real benefits and increase cost of development and maintenance.

Configuration Driven Implementation:
Configuration driven implementation can be define as development which can incorporate future change of requirement through change in some property or attribute define in a system. Basically it can be said that change can be done without changing the code. So configuration driven implantation laid its foundation at requirement itself, as the constraint of requirement define how much configuration approach can be taken. If the requirement is too specific and unique than configuration approach may be not a good idea. But if requirement is generic enough that configuration driven approach can be taken. For example if requirement presently is to process some logic for specific part type only but it future other part type can also have same business process. Also while doing design of configuration approach it should also be taken in to account whether there is any possibility of change in requirement. For example rarely any Organization changes there Change Management process once develop. Making this solution, too much configuration based may not be sound approach. Also other factor is reusability, usually for example Workflow Handler can be written in such a way that it driven by argument and can be reusable for similar case but with different business object type and status. To summarize this are the three factor which define for going for Configuration approach.

1) Requirement is generic or too specific.
2) Expected change in future.
3) Reusability of implementation.

Configuration based approach in Teamcenter:
In teamcenter you can drive configuration based approach through various means. The main tool which is also use in Product provided Configuration is Preferences. Preferences are internal Teamcenter environment variables store in database. Teamcenter provide various API both at server and client side to access those preferences. One of the advantages of preference based approach is that Teamcenter provide different level of preference control based on Site, Group, role and use. Also access control for edit for preferences is also defined. Hence different configuration can be wisely used . Second approach usually is through Configuration file. We define set of property in specific format which is read by code during runtime. The config file usually help in specific location usually in tcdata directory. This approach has its limitation as specific code to be developed to read and understand the config file. Also it not store in Teamcenter environment. Third approach is used for Workflow Handler development which can be configured by providing argument and its value while designing the Workflow. This approach widely used for making Handler behavior generic enough to be driven by argument. For example Handler can check state of target object type. The object type can be defined in argument.
To summarize different approach Configuration driven implementation in Teamcenter usually can be categorize in three types.

1) Preference based approach.
2) Configuration File based approach.
3) Argument based approach.

Usually implementation is driven by mixed of the above, but most prefer way should be preference based approach.