Siemens PLM Teamcenter - Separating Platforms and Apps

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.

https://twitter.com/ChadKJackson/status/488727015474741248

https://twitter.com/ChadKJackson/status/488727069040201728

https://twitter.com/ChadKJackson/status/488727119464103936

https://twitter.com/ChadKJackson/status/488727197050343426

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.

https://twitter.com/ChadKJackson/status/488727240209739776

https://twitter.com/ChadKJackson/status/488727275957800960

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.

https://twitter.com/ChadKJackson/status/488727329405812736

https://twitter.com/ChadKJackson/status/488727382291804163 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.

https://twitter.com/ChadKJackson/status/488727420120231936

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.