To run various business units in various places, the concurrent engineering process is inevitable. But parent company should have control over the data & its lifecycle. In this scenario, whether it is good to go with Cache server setup or Multi-site collaboration?
Solved! Go to Solution.
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Do your due diligence when determining whether to implement a multi-site or cache-site architecture. I have supported a multi-site for a few years now implementing data model changes, upgrades, cache servers etc. We find ourselves in a unique situation since our multi-sites vary in age and complexity and a few years ago data models. Many, many, headaches have occurred when deploying changes because of anomalies amongst multi-sites. For us, this has resulted frequent (NEW) issues when moving from sandbox > validation > production. The lesson has been learned and we’ll be taking a different approach before the next major TC upgrade.
When discussing the cache option, it is imperative to understand how the data will be used across the Teamcenter architecture. Sites I administer occasionally share or collaborate data, however the majority (80%-90%) remains at the owning site. One case for a multi-site would be Heavy collaboration, in a global cache structure this would be a burden at the user level (dependent upon many network variables). On top of our multi-site setup we recently implemented a cache server. The Improvements in file open time were significant, but at the cost of longer open times at other global sites. A trade-off mitigated because of minimal data share.
The biggest takeaway here is to spend the time up front to determine what is required and will be required before going either direction. We hope to consolidate our multi-site and move to a cache-site structure, as Randy mentioned, not an undertaking for the faint of heart.