Fields marked with a * are required


Siemens PLM Teamcenter: Separating Platforms and Apps

References Cited

Siemens PLM, Product Lifecycle Management (PLM)

In the past five years, CAD applications have undergone a significant amount of change. We’ve seen the advent of Direct Modeling. The use of 2D for design has seen some serious advancements. Interoperability seems to be improving, even if incrementally. And after getting all the attention for many years, CAD seemed to have gain the spotlight for PLM… at least for a little while.

Now, however, big changes are afoot with PLM. Support of Machine-to-Machine connectivity and IoT in PLM is meteoric. Industry process driven experiences are overriding long known products. So with all that in mind, I’ve been reengaging a lot of PLM providers to understand some of these efforts in depth. That’s why I reached out to Siemens PLM.

In this post, we’ll take a look at the most fundamental change affecting Siemens PLM’s Teamcenter. It’s a big undertaking. One that should have a big impact.

Capabilities Provided

To get started, let’s take a look at the tweets I sent out immediately after my briefing with them.

OK. To get a little more specific, what’s happening here is the separation of Teamcenter into enabling functionality and application capabilities. Think of it this way: the enabling functionality is basically framework stuff. It’s functionality that, by itself, wouldn’t be interesting to an end user. It really wouldn’t be in a usable form. But all that stuff is needed to built out capabilities a user would apply in their every day work. This framework stuff includes things like objects and their characteristics. It includes schemas and base definitions. Base workflow functionality is likely there. Collaboration tools, without a context, probably live in this bucket as well. I haven’t confirmed specifics, but Siemens PLM is unlikely to share it anyway.

The other bucket is what goes into applications. It’s not clear exactly how granular these apps will be, but I fully expect them to be industry focused. So, for example, a change management workflow for Aerospace & Defense will likely look very different than that for Industry Equipment and Machinery. There might be several different apps per industry.

You read that correctly. Some of these apps will be built internally, as is logical. I expect the end user functionality that exists in Teamcenter today to move into these apps eventually. However, Siemens PLM won’t be the only company with the ability to build those apps. They will open up the platform such that other companies, like IT services firms, to build their own apps on top of the Teamcenter Platform.

Still not clear? Let me provide a example that might shed some more light on things.

First off, as a customer, you would install the latest version of Teamcenter. Once installed, that’s the version you have for the next 3 years.

Second, you might (hypothetically) deploy the Siemens PLM provided A&D change management app. This app actually gets updated every 3 months, as it might go through an early phase of expansion and enhancements. There’s no need to update your version of Teamcenter. You only update the A&D change management app. New functionality shows up in the app as its capabilities expand, but still do not change the underlying schema, database, objects and other whatnot in the underlying Teamcenter platform.

Third, you might (hypothetically) deploy an A&D configuration management app provided by Capgemini. This app gets updated every week during the first two months and then once every 6 months after that. Again, no need to touch your installation of Teamcenter for three years. New functionality shows up in the app with new versions of the app.

Commentary and Analysis

OK. Now that the concept is (hopefully) clear, what are the implications? Well, there is one advantage right off the bat.

There is always fear and loathing about going through a major upgrade of a PLM system. There are often big changes that spell doom for customizations that have tailored the PLM system to the needs of the company. But with all that need to customize moved into the app, which can updated very frequently, there is little need to update the platform frequently at all. So, that offers some stability for the IT organization.

Another important point is that the separation of the platform from the app is the ability to quickly iterate the app. New functionality can be added, and fixed, without fear of bringing down the entire PLM system for weeks. It provides more agility to Siemens PLM and their app providing partners to innovate at a faster rate. Siemens PLM, their partners nor you have to wait for the new version of Teamcenter in 18 months for that new functionality that would add a whole lot more value. Put it in the app and install it on top of the Teamcenter platform.

Why is that important?

A big problems with PLM is that it traditionally has been some inflexible in terms of its capabilities. And, interestingly enough, many organizations have realized that their needs of a PLM system can change quickly and frequently. Most cost justifications to purchase PLM systems are based on big and serious business problems. So getting stuck with a solution that really doesn’t fix that business problem is bad. In fact, it can kill your career.

Recap and Questions

Here’s the deal. PLM has had this inflexibility problem since its inception. That combined with the large amounts of money required to purchase the software and then deploy it has made it tough to realize the promise of PLM. The agility offered by this separation of platform from apps should theoretically address that concern.

Alright folks. That’s my take. What ware your thoughts? Sound off and let me know what you think.

Take care. Talk soon. Thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required


  • Great post.

    I am wondering how granular apps based on the platform is different than what @jim_techclarity:disqus was debating against you in the Tech4PD series. This post as well as your previous post seems very similar to an “integrated suite” which uses a granular approach to provide their apps/functionality. With this platform which acts as the information backbone there would be no need to exchange” information via standards (IGES, STEP, etc.) as long as it is in the same environment.

    My questions:
    1. Siemens PLM Teamcenter strategy does seem to be an “Integrated Suite” implemented using a granular app and platform strategy, do you agree?

    2. Are you in support of this architecture or are you just reporting on it?

    3. Have your thoughts on granularity evolved since the Tech4PD episodes or is the platform (even it is just a file format) always part of your

    • Hey Denis. I’ll try to answer some of your questions.

      Jim and I were debating which made the most ‘impact’, integration or granularity. My argument, then and now, is that without granularity, the more extraneous roles in product development won’t participate in a model-based fashion. For example, a purchasing agent isn’t willing to open the 3D model in a CAD application. However, they could use a smaller, slimmer app that lets them pull measure critical dimensions. Examples like this continue on and on. I still think that is a critical point.

      What’s happening more recently is that a lot of software providers in this space are realizing each extraneous role needs their own set of functionality to participate in product development processes. However, they’re not just creating them willy-nilly. They are integrating all of them to that design data underneath. PTC is / has done that with Creo. Dassault is starting to do that across ENOVIA, CATIA, SIMULIA, EXALEAD and more. Siemens PLM is doing that with Teamcenter, as noted in this particular post.

      In general, I favor granularity as a first step. Then I favor integration across granular apps. So I not only support this move by Siemens PLM, but I also support Dassault’s and PTC’s moves here as well.

      Hope that helps.

  • A Chase Turner

    Teamcenter is nothing like Apple’s IOS ecosystem, in terms of supporting rapidly iterative customer-driven innovation on the IOS and OSX platform.

    Although Teamcenter took a positive step forward in 2008 to expose the Teamcenter platform via SOA, the heritage of UGS’s 2-tier PLM engine meant that weaving new industry specific business logic within the platform was a complicated effort — due in part with forward references from the core parts of the 2-tier PLM engine to industry verticals. WORSE, when there was an overlap of business function across verticals, substantial Teamcenter development talent was directed to the tuning on the client AND backend platform to ensure proper execution of that particular combination of verticals.

    Where are the specifics of Teamcenter’s future architectural changes that avoids that tedious and complicated weaving of customer business logic with Teamcenter core platform? And note: Teamcenter promotes *too many* client GUIs — multiple Thin clients, Eclipse-heavy rich client, X11, MSFT Native clients — HOW are those divergent client-side APIs refined such that they all will support rapid innovation by customers with a “stable” Teamcenter platform?

    Apple’s IOS ecosystem is built on a substantial, 25+ year framework refined in the art of “delegated” APIs to more clearly isolate core platform changes from third-party code developers. Teamcenter’s SOA is sagging under the accretion of many APIs, each of which requires specific tuning with every long-cycle platform release.

    There are too many Teamcenter clients, too much complexity adding customer-specific features in the Teamcenter platform, and no “delegated” API framework designs in Teamcenter proven over three major releases to convince me customers will be rewarded with a stable PLM client and server platform.

    Show me specifics of Teamcenter’s future innovation — with client and platform code and not PowerPoint slides — that illustrate what is truly novel and noteworthy here.

    • Chase, thanks for your comments.

      If you’ll notice, the post was written in the future tense. This is not as Teamcenter exists today. Overall, the idea that Teamcenter can act as a platform and apps can be built on it is the direction Siemens PLM is moving, regardless of the technical details underneath. The comparison to Apple’s iOS is an analogy, not mean to be taken literally in terms of development details.

      Since you posted with such technical detail, I was curious about your background. On LinkedIn, I saw that you worked for Siemens PLM until 2010. Obviously, it sounds like you disagreed with some of the Teamcenter strategy up to that point. Perhaps in the past four years, Siemens PLM has developed this strategy and has made some progress by which you are not aware.

      Thanks again for commenting. Take care. Talk soon.

      • A Chase Turner

        Chad — thanks for your reply here. We both have time to revisit this thread in four years time — as that would allow Teamcenter platform to have undergone 1 major release to reconcile the power point of today with the reality of what they delivered by then.