+34 934 547 873 info@wincom-plm.com


We recently completed a feasibility study on how to upgrade a PDMLink system with a major customization. Here are some extracts of that report, it is clear the over time many systems, even with the best intentions, degrade and become less an asset and more a liability. When we start to customize our systems we do not think of what it might become in 5 or 10 years, at Wincom, “Cost of Ownership” is a constant and ever pressing concern.

So the question is how do we recover a system, especially to allow us to upgrade the customizations to later versions of PDMLink?

Here some key concepts that came out from our study of the upgrade from 9.1 to 10.x

System Stack

Key Strategy Points

  • Limit risk, this will not be a rewrite of the code of the system
  • Take advantage of the new R10 features
  • Make some limited tactical improvement to the system
  • Map a upgrade plan with a clear time line and effort

Upgrade Stategy

One clear objective of the client is to limit the risk of the upgrade. This is due to the complexity of the system and the difficultly of re-testing and so the minimum changes to the system the better.

The final stategy was an As-is upgrade with the application of the system using the Wincom Component Architecture.

As-Is Code Upgrade

As we have seen the code in the customizations is complex and highly interconnected; we could refactor the code to reduce this complexity but this will introduce the risk of creating errors within the system. A major refactor will also prevent the merging of changes that will happen in the core code during the upgrade, forcing us to introduce an early and extended code freeze


We have concluded that code upgrade must follow the rules above however this does not exclude the possibility of componentizing the code and this is exactly what is proposed. From an analysis of the code is has been seen that components can be identified. A component is defined as separated features and functions that can be upgraded, tested and installed as a single entity. There is a clear a number of these in the system and code review shows these are possible to identify, however there must be some clear stages to this componentization strategy.

We define three types of component that will exist in the final system

Application  A component that has a real meaning to the users, will include a user interface
Interface A component involved in the communication between systems either import, export or both
Technical A supporting component primarily used to hold shared resource between other components
  • We can upgrade in stages
  • We can work on more than on part of the customization at once
  • We can manage the project risk
  • We can estimate the project better
  • We can we sure of our progress
  • We can retire components
Component Overlay Procedure

The key concepts we have introduce thus far, are an As-Is strategy for the code and to introduce a component architecture. The component architecture will be defined gradually and be in part driven by the existing code structure. However there is a clear objective to create a base technical architecture upon which to build the application and interface components.

The overlay strategy follows four steps

  • Snapshot the current system
  • Create the base configuration component
  • Component definition
  • Create the application and interface components




But will it work? to answer that question we took an example applicaiton and interface component and applied the proposed stategy.

The first stage of the feasibility study was to create the configuration and utilities components. These are technical support components that are required to support the majority of other components. The separation of these components was clean and there was no significant issues. One major interface to TeamCenter and another significant UI were componentized and upgraded.

Overall the feasibility study achieved it’s goal of identifying and qualifying the risks involved in the upgrade project. It is clear that the majority of the upgrade is technically feasible and there are only two major potential risk areas. However these do not pose a significant threat the project and even in the worse case scenario would not significant extra cost to the final project.


The road map for the application upgrade can be highly made in a non-sequential manner. After each component is identified it can be given to a developer to upgrade and the testing and validation may also be achieved independently.


We can at a high level defined two technical teams that are required for the upgrade to be successful, for this roadmap we define these as follows

Application Team This team is close to the users and application and has no visibility of code. They perform the validation and integration of the components.
Upgrade Team Effectively the developers responsible for creating the component, performing changes to upgrade the code to R10.x and doing code verification. This team does not need to be on-site.

The testing of each component must be done both during development on a clean data set and then on a clone of the real client database. We use standard software testing terminology to distinguish these test stages of verification and validation.

Methodology Description
Verification The upgrade team testing the code does what they expect. Often we use the phrase “Are we building it right?”
Validation The application team testing the code does what they expect. Often we use the phrase “Are we building the right thing?”
Integration Testing The final validation of the complete set of components working together. Some integration tests may be performed on a subset of components. This will be the responsibility of the application team.

An example of the concept for the validation testing environment

Technical Project Plan

The technical project plan does not specify a time line, it specifies the sequence of steps that must be performed to upgrade the application. It does not include any steps related to the infrastructure upgrade.

The structure of the plan is shown below, is shows some major steps such as this feasibility study which are pre-requisites for the rest of the process, however once the upgrade of the components is started these can be done in parallel by one or more developers



The upgrade of the a complex custom application can be achieved with an external upgrade team with minimal interaction with the client during the code upgrade. The feasibility of upgrade has been proven and can be achieved in a predictable time scale with minimal risk. There is a need for an on-site application team that will have responsibility for validation and integration.