Introduction
Michael Roberts:
Hello everyone, and welcome to today’s SPK and Associates blog entitled, Inside the Digital Thread: Real Stories from Integrated Engineering Teams.
My name is Michael Roberts. I’m Vice President of Sales and Marketing here at SPK and Associates.
Today, we’re going to go beyond the buzzwords to talk about what actually happens when engineering systems are disconnected, and what changes organizations can use to finally connect them.
So many engineering teams today are still dealing with siloed systems across ALM, PLM, DevOps, quality, and manufacturing. That disconnect often creates duplicate work, poor visibility, slower changes in those systems, and compliance challenges that impact the entire product development process.
But when organizations successfully create a digital thread across those systems, the impact can really be significant, from improved traceability and collaboration to faster innovation and better business outcomes.
To help us unpack this in a real-world approach today, I’m joined by two experts who have helped many organizations solve those exact challenges.
So, I’d like to introduce these two. We’ll start with Aparna. Feel free to introduce yourself.
Guest Introductions
Aparna Garg:
Hey. Hi, Michael. Hi, everyone.
I’m Aparna Garg. I work with OpsHub Technologies. OpsHub and SPK have been partners for some time, and I have been working with OpsHub for the last 17 years.
I just clocked my 17th work anniversary last week, and I’ve been doing integration for 17 years of my life. I’m happy to be here.
Michael Roberts:
Congratulations. That’s awesome. Seventeen years. That’s awesome.
Carlos, of course, you know, I’m the old dude.
Carlos:
So, you know, 17, you’re still a young couple.
I spent over 20-some years in the world of chip design and software development at Cadence, where I ran the operations group. We were an ISV. We produced software to place and route, and set up your design before you go into the fab or tape out.
So, as a developer, I was one of those folks who ran teams that were using all these tools, and we were dealing with how to get our tools to work together.
SPK brought all that on board. I’ve been working with Michael and really dug into the world of regulated spaces because Cadence was basically working with a lot of commercial companies. But now, we’re definitely focused a lot on aerospace, medical device, automotive, and again, really highlighting the need to have tools flow together.
You’re going to hear a little bit more about that today. So, I’m looking forward to talking to you guys.
Michael Roberts:
Welcome, both of you.
No two more experienced people, I think, that we could have to talk about this topic.
So, I really want to focus on real-world stories, real challenges, measurable outcomes, and I think everybody’s going to love this video at the end of the day.
Real-World Challenges with Disconnected ALM and PLM Systems
Michael Roberts:
Carlos, I want to start with you.
You work with a lot of engineering teams that are struggling with ALM and PLM. Can you share a real example of where that lack of integration caused pain, maybe delays, duplicate work, or compliance issues, and then maybe how that team turned things around once their tools were connected?
Carlos:
So, you’re asking me to bring the pain, is what I heard.
Okay. Sure.
The problem is that most engineering groups do not operate in one vendor ecosystem. One team may be managing requirements and risk in a tool like Codebeamer or some other vendor. Another team may be doing development work or testing in something like Azure DevOps, maybe connecting off to Atlassian and Jira, and having to manage that data flowing between all the different systems, your PLM, your BOM area.
The vendors, the tool vendors, understand this problem, right? A few of them have some pretty decent integrations as a starting point.
For example, PTC, which, disclaimer, we are partners with PTC as well, has a really nice integration between Codebeamer and Atlassian Jira.
With PTC, you also have the Open Services for Lifecycle Collaboration, which is the standard. So, those tools that understand OSLC often have an integration path to get you there.
That’s great, but that is a short list. Very, very quickly, you discover that those particular tools are outside that list, and it happens all the time.
At that point, you need something broader and more flexible than whatever the single vendor came up with out of the box. That’s where a great partner such as OpsHub really is invaluable to us as an implementer and validator, and as a company that helps these companies be successful.
OpsHub provides a large library of connectors across ALM, DevOps, test management, ITSM, and all these related tools. Where there’s not an existing connector, you can create one. You can have a custom connector built.
That is typically way more practical than trying to build and maintain your own one-off RESTful API integration from scratch. That’s another thing I love about that.
Another thing that is really great, and I really like about OpsHub, is that they support an on-premises deployment because a lot of our regulated customers in medical device, automotive, and aerospace are not really comfortable with the requirements and risk data, evidence data, and other compliance artifacts flowing to a SaaS integration outside the control environment. They get really nervous about that.
So, the ability to deploy the integration platform on-prem can really help remove that major barrier to adoption, and that makes all our lives easier.
Aerospace Migration Example: IBM RTC to Codebeamer
Carlos:
So, just a little bit.
We had an aerospace company that was migrating from IBM Rational Team Concert into Codebeamer. This wasn’t like a small one-week conversion. It involved a large engineering environment with many teams, and those teams could not all move together at the same time.
The legacy RTC system didn’t have a nice way to extract data out or a simple migration path into Codebeamer. Another awesome thing about OpsHub is the interim migration effort, right? How do you move data without causing disruption and maintain synchronization between both?
We were able to take advantage of OpsHub’s connection with RTC, build that into Codebeamer, and start pushing the data over. Then, we could selectively turn off those particular syncs once the teams were on board.
So again, a pain. OpsHub removed the pain on that one, which was amazing.
Azure DevOps and Codebeamer Example
Carlos:
Another one I’ll mention real quick.
We had a customer who was doing Azure DevOps for their testing, verification, and validation, and their ALM was also a PTC product in the Codebeamer space.
There wasn’t an integration from the vendor on either side. So, we were having to deal with requirements data, coverage data, and basically having to maintain that full traceability in between.
So, we had a problem.
The other part is that this happens very often: the ADO team did not want to move off. They were like, “No, we like our tool. See you.”
The other part was like, “Yeah, but we’re trying to build this digital thread. Everything needs to talk to each other.”
And they were like, “No, I think we’ll stay here.”
So, OpsHub was able to help us there because they were able to build an on-premises integration with ongoing synchronization between all the verification, validation artifacts, test plans, etc., back into Codebeamer. It tied together your requirements and risks, etc.
So, tada, you got to have your cake and eat it, too.
I’ll pass that back to you. I can keep going all day, but there are a lot of great stories that we have.
Michael Roberts:
No, that’s good. Good stories, Carlos.
I love especially the real one of, “We like ADO, and we’re not moving off of it.”
I feel like that’s a very common “cross your arms” moment. Like, welcome to enterprises when you say that. Yeah, have one change.
The Biggest Mistake Organizations Make with Integration
Michael Roberts:
All right. So, Aparna, obviously Carlos talked about how OpsHub has a huge role to play in connecting the dots between those systems.
From your perspective, what’s the biggest mistake organizations make when they’re trying to integrate those tools, and how can they avoid that?
Aparna Garg:
That’s a great question, and we see the same pattern again and again across organizations.
In fact, when Carlos was sharing his views, I noticed he used the words “pain” and “change” almost in every sentence. That is one of the biggest mistakes that teams and organizations make. They underestimate the amount of change or pain an integration can cause if it is not done right.
Integration is often taken as a one-time technical project instead of an ongoing business capability.
As a result, because it is treated as a one-time project, the only decision anchor is cheaper pricing, without prioritizing reliability, high-quality data, how much to integrate to create the digital thread across the systems, or how many extra steps an engineer or user in ADO will have to take.
So, the integration needs to be seamless.
What that looks like in the real world is the team says, “We need our Jira to talk to our PLM system,” or, “Let’s connect ServiceNow with our dev tools.”
The point-to-point connection is built with scripts and APIs because integration or digital thread is considered a very easy problem to solve. So, you know, “We can build it ourselves.”
Then data gets simplified or lost. Updates are delayed and inconsistent, and teams start second-guessing the data. They don’t trust the data they are seeing, and now that creates two problems: the integration is fragile, and the data coming through is not trustworthy.
How Teams Can Avoid Integration Mistakes
Aparna Garg:
Coming to your second part of the question, which is how teams can avoid it and how organizations can avoid it, there are three simple shifts they can make that can make a huge difference.
- Think in Terms of Data Flow, Not Tool Connections
First is thinking about integration in terms of data flow and not tool connections.
Organizations can start with the question, “What information needs to move, and how accurate and complete does it need to be on both sides or on all sides?”
They should not start with the question, “I need to connect X tool with Y tool.”
- Design the Digital Thread for High Fidelity from Day One
Second is to design the digital thread and design the integration for high fidelity from day one.
It is not enough for data to move. It has to move correctly and completely. That means making sure what users see in one system truly reflects the other system.
When the sync is reliable, teams trust the system, and that is when adoption happens.
- Design for Change from Day One
Third is to design for change from day one.
Organizations often overload users with additional steps to create the digital thread. Either they need to go into a third system to create the digital thread, or they need to manually trigger the sync.
That means training the whole team, bottom-up, on how to use the tools.
Here, one team is not ready to give away ADO. Now, we are asking that team to change their way of working.
So, the digital thread integration should be seamless.
- Treat Integration as a Shared Layer, Not a One-Off Build
Actually, one more thing. I said three, but there’s one more thing organizations can do: treat integration as a shared layer and not as a one-off build.
Integration should support multiple teams, use cases, and systems. Organizations need to centralize the logic and make it reusable rather than restarting it from scratch every time they have to integrate a new system or a new project.
The digital thread just needs to work. It should not require manual steps or a hard push. It should not require an effort.
As soon as it becomes effortless, it will work.
Michael Roberts:
You mentioned the last part about how you get adoption. If it just works, then everybody’s keen to use it, right?
You don’t have to do anything. It just works.
Aparna Garg:
It just works.
Measurable Results from Connected Digital Threads
Michael Roberts:
Okay. So now, let’s twist that.
Now we know the right way to approach it. Given the integrations that you’ve seen with clients, what measurable results do those clients typically see?
Is it faster change cycles, better traceability, or smoother audits?
How did connecting the digital thread actually change the way those engineers work day-to-day? Obviously, not having to look in different systems, but also not having to worry about it.
What are the things you’ve seen?
Aparna Garg:
Actually, if you think about it, most of the customers who come to SPK and OpsHub are already doing some form of integration. It is just not called that.
Some teams are exchanging data over email. Some teams are maintaining a spreadsheet. Some are manually updating multiple systems.
So, the real question these teams need to answer is: what changes when that same integration starts happening automatically, in real time, without someone manually maintaining spreadsheets or manually updating multiple systems?
We asked this question to many of our customers from semiconductor, defense, aerospace, government, and multiple other areas.
One common answer we hear is that they are simply more confident in what they are delivering.
They are more confident in the quality. They are more confident in the data they are auditing and reporting on.
That confidence comes from having connected, reliable data across the system because they know the data they are seeing in the system is traced and up to date. The same data is available to the other teams as well.
From there, the measurable results show up very clearly in three areas because now teams trust the data.
Outcome 1: Faster Change Cycles
Aparna Garg:
The first measurable impact or outcome is faster change cycles.
Once the integrations are in place, the data flows automatically. Teams stop waiting on each other. Change happens automatically, and everyone sees the update in real time.
Decisions happen much faster because the context is always current. Teams move from working in batches to a continuous loop.
As soon as a system architect updates the design or updates the model, it will be immediately visible to PLM. The product manager in the PLM tool will immediately see it. It will immediately go for approval, let’s say, in IBM DOORS.
Outcome 2: Complete Traceability
Aparna Garg:
The second impact is complete traceability.
Traceability is created automatically from change requests to requirements, to design, development, and testing.
The full lifecycle is always visible. The teams don’t have to ask anymore, “Can we trace this?” They already can at any point in time.
Outcome 3: Smoother Audits
Aparna Garg:
The third impact is that audits become much, much smoother.
We all must have heard, “This is year-end audit cycle. I’ll be coming home late.”
So, you know, this is how audits traditionally work: stressful, last-minute exercises. From accounting teams to auditing teams, everyone is just getting the audits right.
Full data from multiple systems, rebuild traceability, and teams would spend weeks repairing reports.
But with a connected digital thread, the data is already connected. Reports can be generated with just one click without any manual assembly.
Organizations move to being always ready instead of preparing last-minute meals with whatever ingredient is available.
Michael Roberts:
The words “last minute” are emphasized there.
Aparna Garg:
Yes. Yes. Yes.
How Integration Changes Engineers’ Day-to-Day Work
Aparna Garg:
I think before integration, engineers spend time switching between tools to get the context and updating multiple systems.
After the digital thread is connected, engineers stay in their own tool. They don’t have to go outside ADO, IBM, PTC, or any other tool.
Data comes to their system, the data they need, and they can see upstream and downstream impact instantly.
So, that is a real outcome. Engineers are not maintaining data anymore. They’re focused on engineering work.
Michael Roberts:
Which builds so much more trust, obviously, in the data when you don’t have to spend time at audit time.
I think that in and of itself should be a win, but there are obviously other areas too from the traceability component and change cycles and all that.
So, great stuff, Aparna.
OpsHub Success Story and Key Outcomes
Michael Roberts:
Carlos, last question for you.
As you obviously know, we’ve worked with OpsHub a lot in the past and with different clients. Can you walk us through a little bit of a success story where OpsHub has helped bridge multiple tools to really create that digital thread?
What were the key outcomes that proved the integration’s value? What did the customer love about it?
Carlos:
So, the aerospace company I talked a little bit about, I’ll get into that.
But I want to say the real main value is even being able to build this thread.
Once you have that, you get all those benefits, as Aparna mentioned: complete end-to-end visibility, auditability, and rapid access to real-time data.
To me, that’s stress reduction.
I don’t know how many audits you’ve sat in. I’ve sat in a few, whether it was an FDA auditor, and we’re in this war room, and they’re saying, “Show us this. Show us that.”
Everyone’s scurrying around the company. The company is in frozen mode because we don’t know. We can’t do anything. We’re doing an audit.
If your data isn’t syncing up and you can’t pull that out at your fingertips, that’s stress, right?
So, stress reduction. I’ll have to put it in there.
Higher Quality and Earlier Issue Resolution
Carlos:
Higher quality.
There’s the old adage: if you fix it early in your process, it costs X. If you fix it later, it costs X exponential. If you have to fix it when you release it to the customer, now you’re talking an order-of-magnitude cost to your company.
That’s basic.
Faster Time to Market
Carlos:
Then, time to market.
One of the things SPK really focuses on is working with engineering teams to help companies release their products to market faster. It’s a very competitive world.
With good integration with tools, you get rapid access to that data. You can course-correct more often. You often can do more sprints and turn the crank faster because everything is flowing.
So, faster time to market.
And then, of course, I’m not even going to mention AI in this meeting. Damn it, I mentioned it anyway.
Lower Resource Usage
Carlos:
Lower amount of resources used up, right?
When your teams are scurrying around trying to pull that data and stitch together all that stuff, it’s a nightmare. It just burns your cycles.
Again, I want to emphasize this is non-trivial for a regulated company like medical device.
You can’t really assemble your trace relationships easily right before an audit. It needs to be built dynamically.
OpsHub allows us to have that built in at the fingertips.
Traceability needs to be current and has to be available at any point in the lifecycle. It’s not just audits. It’s basically the different phases you have to go through.
The Complexity of Traceability in Regulated Industries
Carlos:
You start with your user needs and your intended use. That flows into product system requirements that will drive design specifications, software requirements, hardware components, parts, materials, and eventually into the product BOM that’s in your PLM.
It’s just mind-spinning, right?
Then from there, you’ve got your requirements and test cases, verification, and evidence.
Then the risk management side. In medical device, we’re dealing a lot with sourcing hazards, doing risk mitigations, and FMEA grids.
Those mitigations need to be verified and validated.
That’s a lot.
And, of course, we haven’t even talked about the DevOps side, right?
You have to be able to connect your development team, pull requests, code commits, and repos back and forth, and generate a pipeline.
So, my head is spinning just thinking of all this stuff.
Why Building Custom Integrations Internally Often Fails
Carlos:
Companies that try to assemble this on their own suffer.
Back to Aparna’s point, yes, you can build your API on your own. But if I had a nickel for every time a company said, “Oh, we’ll just build it because we’re, you know, blah, blah, blah,” six months later, they’re still mucking around with it trying to get it to work.
It’s nonsense.
At the same time, the clock is ticking, and those developers who should be working on your product are off mucking around with something else.
That’s not your core competency. It’s not how you make money.
So, seriously, you need to focus on getting this part solved and building the digital thread.
Appreciation for OpsHub
Carlos:
Again, I just want to say thank you to OpsHub because it’s relieved the stress for me.
When I go to a customer, there’s a huge amount of tools out there. I talked about Codebeamer, but there’s Jama, IBM ELM, Polarion, you name it. That’s just the ALM and PLM side.
I haven’t even talked about the GitLabs of the world and all those other pieces in that Atlassian ecosystem.
I wouldn’t know what to do if I had to start over every time with another tool and say, “Okay, we want to help you out, but we don’t have an easy way. Let’s build these things on APIs.”
We used to do that. We were one of those companies that would go off and try to make something for you and take the time to do it.
So again, I just want to thank OpsHub for being there. We’ve had a lot of great engagements together. It’s really helped the customer be successful.
So, thank you, OpsHub. Thank you, Aparna.
Aparna Garg:
Thanks a lot. Thanks a lot.
It’s always a pleasure, our pleasure, to work with you guys. All the engagements have been pretty smooth. The way you manage the projects and manage the expectations, that’s the hard part.
We can provide the solution, but managing the expectation, managing the project, and managing the requirements, that’s the most difficult part in any engagement.
So, always, always a pleasure to work together.
Carlos:
Well, look at this. I appreciate the kind words. I guess I need to send you that check now for the kind words.
I appreciate it. I talk more.
Final Takeaways
Michael Roberts:
So, one of the biggest takeaways I get from this conversation is that the digital thread is really not just about integrating tools.
It’s about getting better outcomes, better decision-making, improved collaboration, reducing risk, helping audits, and ultimately helping engineering teams move faster to get their product to market with greater confidence in the process.
So, Carlos, Aparna, thank you both for sharing your insights and experiences today.
Aparna Garg:
Thank you.
Carlos:
Thank you.
Thanks, Carlos. Thanks, Mikey.
Closing
Michael Roberts:
If your organization is struggling with disconnected systems across ALM, PLM, DevOps, quality, manufacturing, or anything else, obviously the teams at SPK and Associates and our partners at OpsHub would love to help you evaluate your current environment and identify opportunities to create a more connected digital thread.
So, thanks again for watching.
If you enjoyed this conversation, be sure to subscribe to the SPK and Associates YouTube channel for more discussions around engineering transformation, digital thread, AI, DevOps, PLM, and modern engineering practices.
We’ll see you next time.
Thank you.
