Cache setup vs multi-site collabartion

[ArunPLM]

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? 

[RandyEllsworth · Accepted solution]

It depends. There are several factors to consider...
1. Administration. Multisite requires separate Teamcenter installations that are identical. Organization changes at one site need to be propagated to all sites to preserve data integrity - like owning user. Then there is the whole replication issue and management which is highly admin intensive.
2. Shared Data. How much data do the sites share? Multisite is designed to be loosely integrated. A good example are sites where the business units share common parts but rarely share product design. This is because of replication and transferring ownership between sites to obtain "author" rights. Replicas are read-only.
3. Consolidation. Site consolidation is not a lightweight task. Once you figure out that multiple sites is too hard to manage and licensing gets complicated maintaining separate files then you have to perform a site consolidation to merge the two sites into a single site. The sitcon toolset is not for the feint of heart and requires a special key from Siemens which can only be obtained by attending class for certification.

The bottom line is that multisite is an expensive option that should be avoided unless absolutely necessary. Today's 4tier environment is highly latency tolerant and much easier to manage. Everyone working in the same database is much easier to control and share data. Workflows don't have to cross sites. Etc. A good FMS Cache server or Store and Forward volume and FMS Master design is usually the best approach.

[CParker]

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.