Tag Archive for: PLM

PLM

One of the best parts of my role at Jama Software® is working with firms and people with different sizes and products, and services. I enjoy learning about their goals and challenges. I really enjoy geeking out and digging into processes and associated tools to identify areas for improvement.  One question I get asked often is something like “I have PLM, why do I need Jama Connect?” 

It is a fair question, so let’s dig in. 

It may be helpful to define Product Lifecycle Management. Instead of using the definitions from the major PLM players (Aras, Siemens, PTC, Dassault) I am using a couple of internet sources – because the internet is always right. Wikipedia and Investopedia define PLM respectively as:  

  • The process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise. Ref Wikipedia 
  • The handling of a good as it moves through the typical stages of its product life: development and introduction, growth, maturity/stability, and decline. Ref Investopedia 

Seems solid. But notice it does not say anything about a PLM tool. That is because PLM is a collection of processes first and THEN software tools enable and operationalize those processes. Everyone gets hung up on the tool which is a mistake. Build a solid process and then assemble the best of breed tools to compliment your processes.  

Let’s illustrate this with an example. As I write this looking out the window I realize I need to mow my lawn tonight. The process of mowing the lawn is really broken down into lower level processes that I can choose the best tools for me to perform the needed processes. Since I’m a bit of a geek I had to make a chart to illustrate this.    

Jama Connect and PLM

Each low-level process can be accomplished with a number of tools. I highlighted the options I use in red. For my needs these are best of breed. I care about speed and general cleanliness, so I use a riding mower and a backpack blower and I mow once per week.  If I wanted a golf course quality lawn I’d mow three times per week and use the old school rotary mowers as seen at the golf course. The bottom line is that you pick the tools that best accomplish your processes and their goals.   

Single Source of Truth 

By assembling the best of breed tools, you are able to ensure your team is able to operate in the manner YOU need to. But what about my data, you may ask.  I don’t want to have data in three different systems. Absolutely correct. You want a single source of truth!    

Lionel Grealou, a Digital Transformation evangelist that I follow discussed this topic in his blog, noting that “SSoT is often mistaken for a single database or repository for all data; rather it implies an intelligent enterprise data model constructed for optimum data integration and control across multiple sources, avoiding duplication and redundancy.” 

That is an important distinction. We are advocating for a single SOURCE of truth as opposed to a single database of truth. This means that there is a single master of a given set of data. Using modern software platforms that have robust AND OPEN APIs (or through integration hub providers) it is a straightforward task to connect different platforms (and their databases) into your PLM process. 

Taking this approach ensures that data is authored and managed in a single location and shared to all those that need it. Users do not need to know where it came from they just know it gets to the right person, at the right time, in the right format.   

Forming a Digital Thread 

Let us unpack that a bit further. Using my lawn mowing example, if I have a requirement to mow my land in one hour. Those requirements may decompose into the width of my mower (50”) and the horsepower of the motor (22 HP). Those requirements can be passed to the systems engineering and mechanical design teams for their design tasks. The 50” geometric requirement will directly feed the mechanical design. The horsepower requirement will drive the system design and may result in reusing an engine or designing a new one. Again, I made a rudimentary illustration that I think explains itself.   

Jama Connect and PLM

The takeaway here is that we can connect our people and processes. When we do, we support their needs by allowing them to utilize the tools that best fit their needs. This should yield efficiencies and positively impact the form’s bottom line.   

The other outcome is that by connecting data, not only do we have a single source of truth, but we have also created traceability throughout our processes and data. The fancy new term for that is digital thread.  You can learn more about the digital thread by reading this blog, written by Jama Software’s CEO. 

As a note – I would be remiss if I did not note that I realize that I have glossed over the specifics of data models, storage, and APIs in play here. They are important, however, for the purposes of this discussion they are not necessary.  

Best in Breed for the Win 

Returning back to our question. In response, I’ll typically ask what PLM system they are referring to. I’ll also follow up with how they are using it – most PLM users only use their PLM systems for PDM. Next, I’ll need to understand if they have licenses to the PLM systems requirements package (if there is one), if they have the capability to customize the system, etc.  Some PLM systems have bolt on RM applications that still need to be connected to integrate data.  The answer is often a blank stare followed by a complaint about their PLM system.   

Ok. So forget trying to shoehorn requirements management and systems engineering into your old PLM system. Why not take the modern approach and utilize a model-based SaaS platform like Jama Connect for your systems engineering and pass the data to your PLM system?   

Industry analyst, Oleg Shilovitsky from BeyondPLM has weighed in on this topic, stating:    

The PLM paradigm is shifting from central to decentralized. The paradigm of connected digital services is also a departure from isolated SQL-based architectures running in a single company. The data is connected, web services keep all the history and provide access to a distributed version of truth. Such modern architecture is also continuously updated, which makes the problem of system upgrades a thing in the past and irrelevant as everyone is running on the same version of the same software. Furthermore, the cost of systems can be optimized and SaaS systems can serve small and medium-size companies with the same efficiency as large ones.  

Hmmm…  Accessible data with optimized web services with configuration management and cost efficiency. Sounds like a winner to me!   

Yes, Jama Connect is Compatible with Your PLM 

Putting all of this together is a matter of making the connections I suggested in the data flow image above. In my simplistic example, we could use REST API capability and federation to ensure a SSOT. Jama Connect data (requirements, system architecture, etc.) would be stored in Aras Innovator as federated data to be usable by the detailed design, mfg, and quality teams – yet not be editable since it is owned by Jama Connect. The test data (i.e. data files) would the reverse, federated back to Jama Connect to support the validation and testing processes but owned by Aras.   

Obviously, this is a simple example. There are details in play like how much you have customized your environment, but the basic idea remains the same: Use best in class platforms and connect the data to those that need it.   

If you would enjoy talking further, please drop me a line and we can get together, I’m always happy to talk shop!  dewing@jamasoftware.com.   



When I joined Jama as CEO earlier this year, I was excited to become part of a team that was passionate about our customers and solving their problems. The companies we get to work with are a major reason I wanted to join Jama to begin with — it’s an honor and a thrill to partner with them as they build products that will change their industries and the economy. I know I’m not alone in that enthusiasm: As I met individually with every employee during my first three months on the job, over and over again “our customers” was a top reason people cited for coming to work here.

Market Forces

Our customers span an array of critical industries — aerospace, financial and consulting services, medical devices, government, semiconductor, consumer electronics and automotive, to name a few. I’ve now had the privilege of meeting with dozens of them, and I’ve consistently heard them describe the following market forces in play:

The new generation of smart, connected products is increasing competition.

For the first time ever, when consumers buy something new, whether a phone, a thermostat or a car, they expect its capabilities to improve over time. They expect new features over the lifetime of the product, automatic fixes where there were previously recalls, and unprecedented options for customization. With each release of Jama, we’re rolling out new features and improvements that focus on enabling innovation for our customers. We invested in building our REST API to add more even customization and extend the functionality of our solution.

Increasing complexity and new regulation add new challenges.

Development cycles are more complicated than before, requiring close coordination of hardware and software teams, often using different tools and methodologies. Connected products introduce new security risks, often into industries that were previously immune to regulatory compliance. As software becomes an increasingly critical component of new cars, the automotive industry has responded with new compliance regulations such as ISO26262, and so have we. This year we achieved ISO 26262 fit-for-purpose certification by TÜV SÜD to give our customers confidence as they navigate the path to compliance in their product development process.

Systems development teams require a purpose-built product development platform and must take a continuous engineering approach to create products for the modern world.

ALM was built for software, PLM was built for hardware, but today’s product teams require a unified set of capabilities. Teams need contextual, ongoing collaboration and a single source of truth for their data and requirements. In June, we released Jama 8, kicking off a series of releases that will build on our core traceability and collaboration features. We’re also investing in our product ecosystem with the launch of our Partner Alliance Program, working with best-of-breed solution providers to better serve our customers.

At face value, these challenges are daunting. But we get to see our customers overcome them each day through disciplined, modern management of their development processes, which lets them better capitalize on industry trends. As they work to deliver the life- and economy-critical products that are going to change the way we live, we’re glad to be their partners and are eager to foster their success every step of the way.