Systems Thinking Applied to Siemens Teamcenter Product Lifecycle Management (PLM) Software

Samuel Nicklaus
Master of Science in Systems Engineering
Weber State University
Ogden, Utah

Abstract

This paper applies systems thinking principles from the Blanchard textbook to analyze Siemens Teamcenter Product Lifecycle Management (PLM) Software through the examination of system boundaries, analytic versus synthetic thinking modes, and discussing open and closed systems. This paper explores Teamcenter as an open system, identifying factors that influence behavior.

Index Terms—Systems thinking, Product Lifecycle Management (PLM), Teamcenter, system boundaries, synthetic thinking, open systems

I. INTRODUCTION

Siemens Teamcenter is a enterprise Product Lifecycle Management (PLM) system that integrates features like data management, workflow automation, CAD integration, and change management through software. This paper will examine Teamcenter through three different systems thinking lenses: boundary definition, analytic vs synthetic thinking, and open vs closed system modeling.

II. SYSTEM BOUNDARY AND INTERDEPENDENCE

A. SYSTEM BOUNDARY

Establishing clear system boundaries is important for understanding Teamcenter's scope and interfaces. The system boundary helps distinguish what functions and data reside within the PLM system vs what exists in an external environment. To establish clear system boundaries, below is an overview of some of the inputs, outputs, and environment of the Teamcenter PLM system.

Inputs represent information from external sources. These are considered inputs because they originate outside Teamcenter's system but are still needed for operation. Some examples of inputs include the following:

• CAD models or specifications from design tools (form external engineering software)
• Change requests from engineering, or other teams
• Supplier part data that are from external vendor systems
• Requirements information from an external system

Outputs are information that Teamcenter generates and delivers to stakeholders. These are outputs because Teamcenter generates/produces them for use by external systems or stakeholders. Some examples of common outputs include the following:

• Product configuration defining approved designs
• Bill of Materials (BOMs) which specify assemblies
• Manufacturing instructions for the shop floor
• Various reports that give metrics to key stakeholders

The Environment contain the external systems or factors that interact with Teamcenter but are outside its boundary. These systems influence Teamcenters behavior while also remaining outside of its control. Some examples of common environment elements include the following:

• CAD tools (ex: NX, CATIA) creating part models
• Any external databases that contain important information such as compliance requirements
• Active Directory that manages user identities and org structure (this would be used for user provisioning inside the Teamcenter environment)

B. COMPONENT RELATIONSHIPS

A single relationship exists between two components based on their attributes, where "each component in a relationship provides something that the other component needs so that it can contribute to the system's function" [p. 4]. Blanchard identifies three relationship types: first-order (functionally necessary), second-order (synergistic), and redundancy relationships. Below are examples of three critical relationships between Teamcenter system components.

Example First-Order Relationship: A part workflow to the Teamcenter data repository

An example of a first order relationship would be a part workflow with the Teamcenter database repository. The workflow backend has to retrieve key information from that database like the state of the item in the workflow, user assignments, approval history, and any other metadata to help determine routing logic and next steps. Conversely, the database repo requires the workflow to provide information like audit trail entries and lock/unlock instructions (sometimes called release flags) to maintain the integrity of the data.

This is an example of a first-order relationship because it is functionally necessary to both components. Neither can fully function without the other.

Example Second-Order Relationship: Search Indexing Service to Access Control Module (ACM)

An example of a second-order relationship would be the relationship between the Search Indexing Service (also called the SOLR search) and the Access Control Module of the system. The search indexing service allows for quick search queries across all the information in Teamcenter, while the access control module is used to enforce security policies on those searches (Eg: what users can see what information in the system). Together, they create a fully functioning secure search. This relationship adds to system performance by having the advantages of both speed and security at the same time.

This is an example of a second-order relationship because the combination of systems delivers additional performance vs what either component achieves independently.

Example Redundancy Relationship: Primary Application Server to Standby Application Servers

The third and final example has to do with a redundancy relationship, in this case we are talking about the relationship between a primary application server and a standby one. Blanchard speaks to this relationship as "when duplicate components are present for the purpose of assuring continuation of the system function in case of component failure" [p. 4]. Teamcenter allows the option to deploy multiple instances of itself across multiple servers, allowing for redundancy. This means if one application server fails due to a hardware, software, or network issue, the load-balancer automatically redirects the user session to the backup server instance. Note that while users might experience brief interruptions, overall system function continues as normal.
C. Component Optimization Degrading System Performance

Case: Database Caching

An example of how optimizing one component could degrade total system performance is the typical CS problem of database caching. On one hand, implementing caching improves query (search) performance by storing frequent results in faster memory. However, if you cache data too aggressively, individuals who use the search could encounter outdated versions, which could cause incorrect results (AKA degrading system performance by producing incorrect information). The cache timeout is used to optimize database efficiency, but causes a degradation of accurate results.

III. ANALYTIC VS SYNTHETIC THINKING

A. The Analytic Approach

In this example, my Teamcenter implementation team received complaints about overall system performance, so the team decomposed the problem into component parts. Members of the team split out to solve various issues related to performance which resulted in faster query times, reduced network latency, and an overall more responsive UI. Though, after deploying these changes to production, users reported little to no change, and in fact, some aspects of the application actually became slower than before. I think this is a good example of where we as engineers focused too much on metrics/the parts of the application we can measure vs the actual user experience (the whole).

B. The Synthetic Approach

The purpose of synthetic thinking is to examine system purpose in the context of the larger enterprise. Teamcenter enables engineering collaboration across the entire engineering lifecycle, while faster system performance is great, this exercise revealed the actual constraint. As it turns out, engineers were waiting additional time for part approvals due to the way our workflows processed parts. A single engineering change triggered multiple workflow interactions that took far longer than any performance gain we made by improving CPU, Memory, or network load. The redesign of the initial workflow fixed this performance issue. We restructured it to reduce interactions between the part data and the workflow.

C. Reconsidered Assumptions

Our initial approach assumed performance was additive, meaning that we thought components operated independently and that Teamcenter, for the most part, was an isolated system. Synthetic thinking would've shifted our focus more on overall system performance rather than the performance of individual metrics or components. We should've initially focused more on why the system was feeling slow, rather than trying to broadly increase performance across the board. Synthetic thinking focuses on overall system performance rather than individual component efficiency as well as measured business outcomes instead of performance metrics that might not lead to real world performance gains.

IV. OPEN VS CLOSED SYSTEM FRAMING

A. System Classification

Teamcenter is an open system. Blanchard defines open systems as those that "allow information, energy, and matter to cross its boundaries [and] interact with their environment" [p. 8]. Teamcenter exchanges information with many external systems, and is adaptable based on factors such as regulatory changes.

B. Environmental Factor: Regulatory Compliance

Defense contractors using Teamcenter must comply with Department of Defense (DOD) regulations for safeguarding covered defense information or controlled unclassified information (CUI). When additional requirements for data protection are introduced, Teamcenter implementations require modifications for features like access control segregation or additional audit log retention. These changes originate entirely outside the system boundary, but alter the entire system architecture and operational behavior.

C. Impact of Ignoring Environmental Factors

Analyzing Teamcenter performance or security purely within the system boundary ignores that DOD compliance requirements fundamentally shape system architecture from the beginning. For example, a team optimizing for data access speeds without considering access control segregation might implement shared caching that violates CUI isolation requirements. Similarly, database archiving strategies focused solely on storage costs could delete audit logs before the proper regulatory date, which would create a compliance violation. The system boundary must extend to include regulatory constraints because these external factors impose (non-negotiable) design constraints that take priority over other deliverables.

V. CONCLUSION

This paper applied systems thinking principles to Siemens Teamcenter PLM software by examining system boundaries, thinking modes, and environmental interactions. The boundary analysis identified first-order, second-order, and redundancy relationships between components. The analytic versus synthetic comparison showed how my team's component level performance improvements failed to address the actual constraint workflow processing. Finally, classifying Teamcenter as an open system highlighted how DOD regulatory compliance requirements fundamentally shape system architecture, showing that ignoring environmental factors could lead to compliance violations. These analyses demonstrate that successful PLM implementations require modern systems thinking strategies that consider the system as a whole rather than isolated component optimization.

REFERENCES

[1] Benjamin S Blanchard and W J Fabrycky, Systems Engineering and Analysis, 5th ed. Harlow, Essex, Pearson, 2014.