---
title: "Transitioning from Monolithic to Microservices"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/lmv8w16lc1"
content: auto-caption transcript, proper-noun corrected
---

# Transitioning from Monolithic to Microservices

*Ketryx webinar — transcript of the recorded session.*

[▶ Watch the recording](https://fast.wistia.net/embed/iframe/lmv8w16lc1)

---

So really excited to talk to you all today about using a system of systems approach to building medical devices and managing a regulated SDLC. In software, these this is this term is a microservice architecture, which I'm sure many of y'all are familiar with. And we're gonna discuss several aspects of this, today. And I'll I'll get into that a little bit more when we go through the agenda. But first, we'll do some introductions.

Here we go. So my name is Jake Stell. I am the vice president of client operations here at Ketryx. My main job is to make sure that our customers are happy and successful with our product. My background in this is that I went to MIT for graduate school.

I have an MS in systems engineering and an MBA in operations management. While I was at MIT, I did a co op at Amazon where I worked in one of their automated fulfillment centers, helping them to do process, optimization for their their robot system. It used to be called Kiva systems, now it's called Amazon robotics. And then after I graduated from MIT, I went to work at Amgen. And I was at Amgen for about five years where I served in various operational roles in manufacturing and in quality.

And then my last role at Amgen, I worked as a product manager, with a group that built machine learning and mechanistic models for optimizing various aspects of Amgen's process development function. Yolani, do you wanna introduce yourself really quickly? Sure. Good morning, everyone. It's great to be here with you today.

My name is Yolani Dela Porte, and I'm the director of client operations, serving on Jake's team as well. I have more than a decade's experience working in technology for health care and life sciences. And some of the previous roles that I've, held included working with Iterative Health, a company that does AI for gastroenterology, and I've also worked with Northwell Health System, where we use AI for population health. I also hold the MBA from MIT Sloan. It's great to be with you today, and I'm looking forward to spending the next hour with you.

Thanks, Yolani. So really quickly to summarize what we're going to discuss today. I wanted us to start with talking about the why of system of systems. And so what we're going to do is you're gonna see that we've bookended this talk with this why question. And then as well as at the end, we'll discuss a case study of a successful microservice architecture.

And this case study is from one of our customers, and we'll actually begin by talking about their specific application and why they felt like it was important to transition from a more monolithic way of developing their product to a microservice paradigm. Then we'll have a little bit of educational material talking about what is system of systems, where it comes from, and why it's valuable to think about. Then we'll get into the nitty gritty of what the benefits and challenges of managing a system of systems approaches and what this looks like in the medical device field. And we'll also touch very briefly on how system of systems supports a PCCP for doing AIML. And then we'll finally get into the Ketryx demonstration, which Yolani is going to run, which gives you an example of how you can use tooling to reduce some of the costs of managing your product in a system of systems type way.

And one of the so talking briefly about our customer, Heartflow, which is the subject of the case study that we're gonna discuss at the end of this webinar. Heartflow is a CMD company that was founded in twenty ten. They have an amazing product. What it allows cardiologists to do is to analyze patient data from relatively noninvasive techniques to tell them things about how probable it is that a cost that a that a patient is going to go through a cardiac event. Prior to Heartflow's product being developed and products like it, there were significantly more invasive procedures that needed to be done in order to detect these things and that were also kind of expensive and time consuming and were like, it was a harder question for a physician to weigh about whether they actually wanted to use those procedures.

But HeartFlow can take the input of a CT scan and give a cardiologist really good insight as to whether that patient needs much stronger interventions to prevent them from having a cardiac event. Their product saves patients' lives every year, and they are an amazing customer to work with. And I'm excited to tell you about their use case. And I think the core thing to know is that one of the primary reasons that they bought our product is because we support doing this system of systems type approach. And I think it's worth dwelling on why they thought it was important to, go through the process of shifting from this more monolithic method to this more microservice effort.

There's this great study by McKinsey that talks about code reusability, which is one of the core benefits of a system to systems approach. And there are two primary conclusions from that report. The first is that code reuse can significantly reduce the amount of defects in a deployed product. I think the the core takeaway from this graph is that as you move from ten percent to twenty percent of reuse leverage, there's actually a thirty seven percent reduction in the residual defect density in the product. And so the the takeaway from this is reuse is a huge driver of improvement quality for the products that that use that technique.

Interestingly, reuse also drives better adherence to cycle time and schedules. So another output of this study is that about sixty nine percent of all medical device, projects that were studied here were overran their schedule. And one of the key differences between the projects that were delivered on time hold on just a second. Let me use my indicator here. One of the core differences between those projects that were delivered on time is that the on time projects on average used twenty two percent more code reuse than the late projects.

And so this is a significant driver of being able to bring projects in on time. So there's there's these dual benefits of not only improving the quality, but also performing but also improving the operational performance of a group of people developing these complex products. Cycle forward. So where does what is system of systems, and where does it come from? The the concept of system of systems originated from systems theory, which was developed by a group of biologists in the nineteen thirties to help them understand really complicated phenomena.

The the core idea is that if you're looking at a system that's under study and you want to grasp it better, one technique that you can use is you can divide it up into a set of components that are also sometimes confusingly called systems, which is where the system of systems name comes from. And you can study each of those individual components and then the interactions between the components to be able to understand the entire system better. And the core technique here is encapsulating complexity. It's about where you draw the boundaries around, the system such that it makes sense for one individual to understand that one piece and then how you put those pieces together to make up a whole. That type of thinking rapidly became really valuable to technologists.

So as technological systems became more and more complicated as the century wore on, this type of thinking not only got applied to studying and understanding systems, but also building systems. And it's become a very common paradigm across many different industries. You can see this in aerospace, automotive, infrastructure, and it's the way that we like to think about it is a very common design pattern in industries where you have a complex high reliability, safety critical product that you need to produce and deliver. And, of course, as software has advanced, this technique has also been usefully applied to all types of different software systems. I think the the best example that I can think of is like AWS.

AWS is a map a massive microservice architecture with different teams working on different aspects of it and deploying different products. And the core benefits of using a systems of systems approach are the following. So one, it encapsulates complexity. It allows you to divide up a system into a lot of, like, mutually understandable parts. And not only does it allow reasoning about the system to be easier, the the core thing for complicated organizations is it allows it allows different groups to work on different pieces of the product in parallel and then bring them together to make up the entire product itself.

The other another benefit is that it enables component reuse. This kind of gets to some of the benefits that we talked about earlier in the, in the presentation where having that reuse allows you to manage smaller blocks of code that get combined together. And because you're spending more time and effort on managing small blocks of code that get reused in several places, the quality of it goes up and the development of it can be faster. It also enables versioning different parts of the system at different rates, which allows for really rapid adaptation. And this is the the PCCP use case, which I will discuss in a lot more detail on the next slide, why this is valuable for that.

And the final thing is that it leaves hooks. It allows you to expand the system and think about expanding the system in a much more robust way. If you're working with a monolith, it can be challenging to understand where you want to change, the product to be able to enable a new feature or to be able to enable new capabilities. With a microservice architecture, it can make a lot more sense. Maybe you're just gonna add a new service or maybe you wanna tweak this particular service to be able to deliver that feature.

Because we're we're primary talk primarily talking about medical devices today, it's valuable to dwell here, briefly on the PCCP and AI guidance that the FDA has released in twenty twenty three and twenty twenty four. The reason why we're talking about this is that the the regulatory strategy of applying a PCCP to a regulated, software as a medical device system is that you can kind of encapsulate through the systems and systems approach the part of the system that you want to be able to version at a much faster rate than others. So if you have an application where you have an interface and an AI, or machine learning algorithm that is supplying insights to a patient to that interface, you probably want the PCCP to be focused on the machine learning algorithm itself. So you have the set of acceptance criteria. You have the procedure that you're you're going to use to follow, and it allows you to be really precise about the strategy that you're gonna use to just version that part of the system.

Because, of course, you're gonna wanna version that, to that algorithm at a much faster rate than you otherwise would with an interface or especially a hardware component of that product. So let's let's talk a little bit about how we would, like, theoretically, how we would apply this approach to a medical device, and then Yolani will go into a lot more detail when we actually get to the demo itself. So in this example, we have two products that are serving here. I'm sorry. And y'all cannot see my cursor, and I'm just here we go.

So we have a product that serves two, two two personas. And one of them is the one of them is this product system that consists of a software system and an electrical subsystem. You could think about this as a wearable, for example. And the software system relies on a set of services that provide where the data is stored, how these systems integrate between software system a and software system b, and the machine learning algorithm that supplies insights to both of the software systems. Those systems themselves interact with their personas to provide them with the separate insights that they need for whatever the intended use of this product is.

And if cycle forward give me just a second. And to translate this into something that might be more familiar, let's take one subsection of this and look at how the v model interacts with this, this product. So you're gonna see on this page that we have a v model that consists of two subs two systems. You have the product system itself, which is here, and you have the software subsystem a. In the product system, we have use case and system requirements.

And these requirements describe at a high level both the intended use and kind of the constraints of the overall product that consists of both the software subsystem and the electrical subsystem. This product system also includes a set of system validation and system verification tests that ensure that the product as a whole is operating according to its intended use. As we descend down the v model, we pass into the software subsystem, which has its own encapsulated v model that has a set of requirements that describe what the software subs subsystem is intended to do, the software specifications, and then the actual product itself, the code, with also the attendance set of tests that go along with this to ensure that this subsystem is operating according to both its requirements and its specifications. And the key interface here is ensuring that you can manage the traceability between the system requirements themselves and the software system requirements so that as you both descend and then ascend the v model, you are everything is consistent going across the the boundary. Out.

So nothing is for free, and it's worthwhile for us to dwell here for just a moment on some of the costs of a system of systems approach. One is is that it requires a higher overhead by requiring more independent cycles. So for in the example that we just gave where we have this product system that consists of these two subsystems, there's actually three independent validation cycles that need to take place. One for the software subsystem, one for the electrical subsystem, and then one for the product system in total. If it was running if you were running it as a monolith, it would just be one validation cycle.

And this cost can be quite high if your organization does not have the appropriate procedures or tooling to manage that complexity. There's also a higher testing burden for running a system of systems approach because there's gotta be a lot of emphasis on the interfaces between the subsystems. Because more than likely, you have different teams that are working across these different subsystems. You wanna make sure that you pay a lot of attention to whether they built the interactions correctly for the product to work as intended. And then finally, there's this additional overhead of managing what we like to call the the tyranny of the dominant decomposition, which is that there are gonna be some cross system needs that don't fit neatly into the way that the system is decomposed.

This is just kind of an artifact of using the system of systems approach. And so there's some additional burden for someone who's managing at the product level itself to look across all of the subsystems to ensure that these cross system ideas are being taken care of in a consistent way across all of the subsystems. Sorry. We clear that. And so we'll have a quick poll.

Can you tell us a little bit about what challenges, prevent your company from adopting a system to systems approach today for those of you who are not currently using it? Yeah. Wow. So we have, you know, the at the top, we have lack of required technical skills. There's also, like, some consensus around integrating diverse system components and meeting regulatory standards and high implementation and maintenance costs.

All of that makes sense. And then a long tail here of increased cybersecurity vulnerability concerns, organizational resistance to change, issues with system scalability, and managing large data volumes. And I think we've we've kinda hit the nail on the head here of, like, kind of the diverse problems that can occur when you're trying to apply a microservice architecture or a system assistance approach to a medical device. So I think that leads us well into the next component of our our seminar here of talking about the like, how you can manage this within Ketryx. Thank you, Jake.

So now we will walk you through a simple example of a product using a microservices architecture to demonstrate the systems of systems approach in Ketryx and how you can reduce some of those, overhead costs that come with that approach. For context, the Ketryx platform is a connected life cycle management platform that allows your teams to manage and document the life cycle of the regulated products through commonly used development tools like Jira, GitHub, and AWS. So our philosophy is really that instead of managing the life cycle in one single system, you should be able to manage the life cycle across the different systems of your existing tool chain. And the way that we empower teams to do this is, are through two things. The first is enforcing the type of process control that your SOPs require within your developer tools to ensure compliance.

And then the second is that, we record and track transactions across your tool chain to automatically generate the evidence of compliance, directly from your source systems. And so that evidence is then used to automatically generate the documentation and significantly reduce the amount of time that you have to spend on it. So for the demo, we will mostly stay within the Ketryx system, but it's important to know that the data and the items that we will look at is actually being pulled from, the source system, in this case, from Jira. So let's move on. So this is the, architecture that Jake previously mentioned, and that we will also review in the demonstration.

So, as we said before, this could be a remote patient monitoring software as a medical device, analyzing and collecting data from a wearable device. To keep the demo simple, we will only focus on the software system a and the subcomponents of that software system a within this, purple box. And as Jake said before, by structuring our architecture in this way, each subsystem can be developed and tested and validated independently. And changes and updates in one subsystem do not require complete system recertification as long as the changes are isolated. So this is what, this architecture will look like within KetchX.

So you can see it will be represented by four different projects, and each of these projects can, be versioned independently. At the top, we have the software system a, and at the bottom, we have the three subsystems, and each of them are currently at a different version. So in the demo, we'll look at the interlinking project feature of Ketryx, that allows us to reference items across different projects and subsystems. So in this example, the software system a, pulls the items from the version two point three of your integration to the services, version one point two of your core services, and version one point one of your AI and ML subsystem. So, we will also go through the release workflow for the software system a, and we'll break that down into three milestones.

The first milestone is to complete all of the requirements within the software system a. Once that's completed, we'll go to move to the second milestone, which requires releasing the core services, of, the version one point two of the core services. Once that's completed, we can release, the version one point one of the AI and ML subsystem. And once we've completed all three milestones, we can finalize the release of version two point nine. And so, as we rely on a a version of the integration services that's already released, we do not need an extra milestone for for that sub service.

So let's jump into the products. So what you see here is your, organization's project dashboard, And, you can see the four different projects that we just referenced, the software system a and then the three sub services or sub components. And you can again see that each of these projects are being versioned independently. So the AI ML system is at a version one point one. Your software system is at a version two point nine.

Within your project box, you can also see a a a progress overview of where you are currently at for that specific release. So for the AI system, all our items are in a controlled state and all the tests in our test plan, have been executed. Whereas for the integration services, we still have a few items that need to be moved to a controlled state. Then at the bottom here, you can see a link to the source system where the data and items are actually being pulled from and where your team will actually be managing your items. In in our demo, in this case, each of these projects are linked to a Jira project.

So let's go into the AI subsystem. The first, screen that you see here is the all item screen, and you can see all the typical items that you would see in a sixty three of our compliance system. At the top, you have the requirements, the software item specification, your test cases, and your test executions. On the right, you can see the current state of each of these items. And for this, project, they are all in a closed and uncontrolled state.

When we click into the source of one of these items like this requirement, it takes us to the Jira issue ticket where this item is actually created and managed. And as I said before, Hetrix makes a certain changes to Jira to make it compliant with sixty three zero four and part eleven as well as GxP. And the first change is it adds this approval widgets. And the approval widgets, allow you to create approval groups to take certain actions within the system. So in this case, we have three different approval groups that need to approve this item in order to move it to a controlled state.

The second thing Ketryx does to Jira to make it compliant is, it allows you to visualize and create establish the traceability within Jira. And you can do this through this traceability widget. So you can see here, is a requirement that we're currently looking at, and we can see the software item specification that fulfills this requirement as well as a test case that verifies this requirement. If we would like to create a new software item specification that also fulfills this requirement, we can just click here, and it will immediately create a linked item. At the top, we can also see the parent requirement for this requirement, and this parent requirement is actually in a different project.

To see the final change Ketryx, makes to to make Jira compliant, we need to go back to Ketryx, and let's click into the item record in Ketryx. So, in this item record, you can see all of the fields within Jira is recorded here. You can also see the relations of this record, and you can see all the release documents, that contains this record. And what's important to note is the, history, the detailed history of transactions, that's being recorded from Jira to generate evidence of compliance. So whenever an item is moved into an enrolled resolved state in Jira and the approval groups that we had just looked at, through the approval widget, have approved the item, a closed it is moved into a closed state by Kitrix, and that creates a controlled record that can be used and pulled into your release documents.

And so this way, it significantly reduces the amount of work and manual work that you have to do to generate your documents as it automatically generates your documents. Yolani, let me let me interrupt you really quickly. We have a fresh so someone asked, how do I ensure traceability in a system of systems, and what is the best way to visualize that? And I think the the main thing that I wanna say is that's about that we're we're about at that place in the demo, and Yolani is gonna walk through that quite thoroughly. So, we'll be we'll be going through that really soon.

Please continue, Yolani. Absolutely. So when we get to the traceability screen, we'll talk about that, aspect. So for now, let's go back to our projects, and let's go into our software system a, that has these three projects as the subcomponents so we can demonstrate the power of the interlinking projects feature of KetchX. So within this, we're back in the all items screen, and what's different here is that it pulls the items from all of the subsystems as well.

So you can see your requirements and items from your AI subsystem here. If you scroll down, you see your core services and then your integration services as well. What's powerful about having all of your requirements and or items across all of your, subcomponents in one plain place is that you can now filter these, requirements and items. So we can filter it for a specific item type. So let's say we wanna see all of the requirements, then we can see all the requirements in our software system as well as, the subcomponents of the software system.

Another filter that we can do is to see all the items that have been changed in this new release. This is something that a lot of our clients struggle to to keep track of. And so if we click the filter here, we can immediately see the seventeen items, both in our software system a as well as its subsystems that have been changed since the last release. So this makes it really easy to, manage all of your items in one place even if they are distributed, between different subsystems. So the next screen that's really helpful is the graph view.

So, sixty three zero four requires an architecture diagram. And, again, with a microservices architecture, it can become more complicated to generate and maintain that as you go from release to release. And this tool makes it really easy and simple to generate that graph. So, at the top, you can select the version of the items that you would like to to display, and then you can also display the type of items. So right now, we're only showing the software items.

And, so it's showing us each of the subsystems with the, the specific software items inside of them. If we add, requirements, it will generate the regenerate the architecture diagram with the requirements included. You can see all of the requirements on the right, and it shows the relationship between them. And then you can also see how the requirements, link to the software item specifications in each of the subsystems. So, again, this, really makes it easy to, generate and maintain your architecture program across different subsystems.

So next, we'll look at the traceability and hopefully, address the question that was asked. So, as as, it's clear that, you know, with, with, systems of systems approach, it can become more complicated to maintain your traceability, across all of the subsystems. And so, again, this view makes it really easy for you to do this in one screen. So what you see here is a common seven column, design verification matrix. It starts with the user needs, and it flows down all the way to the verification and the validation testing.

And what's important to note again is it pulls in your requirements from your software system a, and it also pulls in all of the requirements and other items from all of your subsystems. And so this allows you to view to view and manage your traceability all in one place. And then at the top here, you can, see common folders that we can, use to easily, tell us if there is a gap in our traceability. So right now, there are no gaps. Our user needs are a hundred percent covered by system requirements and all the way down, and all of our items are a hundred percent controlled.

But if there was something missing, it would be very easy just to see it here and to filter your items to to, directly take you to those items that require additional attention. So, this makes it, easy to, maintain your traceability across all of your systems. Yolani, we have another question. So I'm gonna interrupt you really quickly. Yes.

So we have a question which is, does system of systems create interoperability issues? And the question is, what if systems don't work well together? Which is a a great question. I think if you recall from earlier in the the the presentation, I was discussing some of the the costs of doing a system to systems approach. And one of the things that I mentioned is the higher testing burden.

And the primary reason why there is a higher testing burden is because it's, of course, a significant concern to ensure that the subsystems are working well together. And, I mean, anyone who has has managed one of these processes or been worked as a part of them can understand why. Like, if you have do two different teams working on two different systems, it's quite possible for them to have missing context. And so when you move up to the product level, it's really important for the integration testing, the system verification, the system validation testing that there's enough verification activities there that give you a high degree of confidence that the systems are working well together. And I also think that this can be managed as well through a set of activities where teams communicate with each other.

They have regular reviews together to discuss the interfaces of their different systems. There are ways to mitigate this risk, but it is a concern. I mean, if you are going to build your product in a system of systems type way, one of the core things that you really need to pay attention to is the interfaces to ensure that the subsystems do work well together. I I hope that answered your question. If it didn't, please, send us another one, and we'll clarify further.

Please go ahead, Yolani. Thank you, Jake. So for the final part of this demo, we'll go to, through the release workflow for, version two point nine of the software system a. And, just before I jump into this, just to quickly review the structure of this system. So software system a is dependent on a version two point three of the integration services a version one point two of the core services, and this has not yet been released, and a version one point one of the AI subsystem.

So when going through this release cycle, you know, one of the pains with managing a system of systems release cycle is that it has, it includes multiple release cycles. And, in Ketryx, we use milestones to make it easier to coordinate these multiple release cycles. So at the top of this release screen for the software system a, you can see the three milestones that we created here. The first, milestone is to, finalize all the requirements in the software system a. The second milestone is for the release of the version one point two of core services, and the last milestone for the release of the version one point one of the AI system.

In the middle, you can see a release, progress screen that shows you all of your items in your release and their current status and also the status of the tests in your, test plan. And then on the right, we have a release checklist, something that our clients really love. It, gives you a set of tasks that you need to complete, in order to finalize this release. So for here, we can see most of our tasks have been completed. The only two remaining tasks are the final re approval and the milestones.

So let's go into the milestones to finalize this. When we click into the milestone, we can see a milestone specific progress screen as well as a milestone specific, checklist. In this milestone, the pro the progress screen shows us all of the items that need to be in a controlled state for this, milestone. And then in our checklist, we can see the only task that's still remaining is the final approval. So we can just go ahead and approve this milestone.

Now this is where CapEx makes it really easy to use your part eleven compliant signature. I'm just using my, fingerprint on my Mac. And you can see that we get a green check mark here to indicate this milestone has been completed. So now we can go to the second milestone. And on the milestone checklist, we see we need to, version the project in order to complete this milestone and do the final approval.

So let's go back to the core services project, to finalize the release. So here you can see the release screen of our core services project. In our release checklist, you can see most of the tasks have been completed. It is only the final approval remaining. And so we can go ahead and, again, approve this with a part eleven compliant signature.

Once we've, completed it, we can go back to the software system a, to look at our milestones and finalize the rest of the tasks. So the core the second milestone has turned green. This means it's ready for the final approval. And, again, we can very easily just add our signature to approve this milestone. And so for the last milestone, we'll go through exactly the same, process.

So we'll click back into the AI system and go to the release screen to finalize the release here based on our checklist. It's only the final approval that we need to do, and so we can provide our, signature to, approve this release. And then we go back again to our software system a. And now we should be ready to, finalize the release two point nine. We just do the final approval of the last milestone, And then we should see all these milestones have a green check at the top.

And now we're ready to do the final approval of, the release. And so our checklist has been updated. Our milestones are completed, and we can just approve this release. So last, but definitely not least, we can have a look at the release documents. And as I said before, Ketryx pulls this information directly from your, systems of use.

And based on the process controls implemented in your systems of use, we ensure that, it it shows you the evidence of compliance. So if we go to our release documents, we can now just download our system requirements specification. And if we open this, you can see, we have a document, and we have the version control for the documents. And then we have a list of all of the requirements. And, again, it's, important to note that these requirements come from the software system as well as all of the subsystems.

So this is from the AI subsystem. If I scroll away, see the core systems the core services subsystem, and we have some of the integration services here as well. And if you look at one specific requirement, you can see it has all of the information, typically necessary for sixty three zero four compliance. It shows you what, exactly the date when it was moved into a controlled state, who approved, the requirement, and then, all of the related requirements. So the parent requirement, the software item that fulfills it, and then the test that tests it as well as say the, result of that test.

And, of course, we can, customize the formatting of these reports. So most of our clients prefer a table format, which is really easy to do, if you want to improve the readability of this. So with that, that's the final, part of our demo. And, just to show you again that, we can reduce the burden of overhead that can come with a systems of systems approach, especially, related to client to compliance operations, by using the right tools. So, Jake, I think we can go back to the HEART flow case study now.

So we actually yes. We have two questions, though, online, Yolani, and one of them I'm gonna need your help with. So Aaron is asking, can you show an example how the system of system linking is established originally? Could you navigate back to the demo environment? And I think let's first go to the, let's go back to the projects, and let's go to software system a.

Yes. And you you were on the right track, Yolani. Let's look at the references. So, Erin, the the first thing is that we we have this concept of being able to establish references, and they can be bidirectional or they can be unidirectional. And you also have really fine grain control over what you carry over as being both referenceable and what we call incorporated, which means it actually shows up on the front end of that project.

So it's possible for you to have all of the items in another project be available to be referenced by, the items in the project that you're working in. It's also possible for you to have a subset, like, requirements. All of that is very, you have, like, really powerful control over that. And you also then have control over what actually shows up on the front end. And the actual impact that this has on the system, Yolani, would you mind going and opening a requirement in Jira and just, you know, clicking into the the parent field?

So Jira is, I think, our canonical example of the system of work. Actually, can you reopen the ticket, Yvonne? What do you mean? Unclose it. Oh, I see.

And the the way that we establish this interoperability, Aaron, is, you know, we have this field. We can look at parent requirements, which is on the right hand side, Yolani. Yes. Can we open that? And you can see here, we're we're in this Jira project, which is the AI project, and you can see AI one and AI two, but you can also see the SSA one project, which are, the other other items.

And these fields are so flexible that you actually can use this to establish linking to other systems of work. So for example, if you're managing specifications or you're managing test cases in Git, which is a very common use case that we have with GitHub, those items will also show up in these fields. So there's there's this high level concept of you wanna be able to establish which projects relate to which, and you can do that with this set of filters that Yolani first showed in the referencing. And then what the impact of that is what's available in these fields for selection for doing the traceability. And once you you establish it and also on the the UI interface.

I hope that answers your question. Please let me know if I missed anything there. And then we have another question here about, can you talk about cybersecurity a bit? How do you manage different cybersecurity requirements for different subsystems? This is a a really good question.

So for one thing, you we have the concept of a type of requirement, and this is actually, we're on the perfect page for doing that. You can see on the right hand side, requirement type. And this selection of type can actually have consequences for where require where a specific record shows up in which documents and as well where it shows up on things like the traceability screen. Would you mind navigating to the trace matrix, Yolani? So so that's one thing.

We have a concept of requirement type. We have, out of the box, a cybersecurity requirement type. Those we would think for you would want those specific requirements to sit within the subsystem themselves that are that need to be to meet certain requirements. We also and this is gonna be a big tangent, but one of the core aspects of doing cybersecurity is managing your SBOM and your SEWP. I don't think that this demo environment is set up, but I'm gonna ask, either Joe or Jen, could you please drop a link in the the chat to one of our webinars that talks about our SMOM functionality?

And what it allows you to do is to actually take a dependency that's in your super port and link it directly to, for example, the the requirement that it needs to meet for a cybersecurity, the cybersecurity requirement needs to meet to meet a test case that potentially tests to ensure that a vulnerability is, is covered off. So there's all of the items that are in all of the dependencies that you're managing are a first class citizen with respect to traceability within Ketryx. And then as well, we do, cybersecurity scanning and vulnerability management within our tools. So, if you connect our, our platform to a git repo, we can scan that repo. We can pull down the dependencies that are being managed there, and we also can allow you to do vulnerability management, and we we do the vulnerability scanning.

Like, we submit those dependencies to a database. We get the vulnerabilities back, and we allow you to manage records to demonstrate that you are adequately mitigating those vulnerabilities. And, I think round out the conversation, the the thing that's really valuable about a system of systems approach in this context is that you can apply different levels of risk management to the different subsystems. So you are going to have different parts of your system that have different, different amounts of risk to your intended use or to the safety of the the patients that you're serving. And the the project is the unit at which you establish the rules in Ketryx.

And so if you have a component of your system that doesn't have really significant stringent cybersecurity standards, you can kind of relax the configuration so that it's easier to release that project. And for the parts of your system that are really, really critical to the efficacy or the safety of your device, you can make those standards more strict. I I hope I answered that question. We dropped in the chat a link to one of our other webinars that discusses in a lot in a lot more detail, but really happy to field more questions about this if you're interested. And so to to kind of finalize the conversation, let's bring it back to where we started and and talk a bit about HEART Flow.

So I've I've talked briefly about the the Heartflow case and the the product that they're building. And I I just wanna discuss a little bit about why they decided to choose CapEx. So Heartflow, it's a it's a product that's more than ten years old. It's very complicated. There's a lot of legacy data that would was out there in their systems, and it be and it became something that they that they thought was challenging to being able to get the release cycle to a much like, a faster pace.

Like, the Heartflow's use case was, I want to make my release process smoother and faster. And as we started working with them, my team, we discovered that one of the impediments to this is that they were even though they had done an extremely good job of componentizing their system, they were still running the release cycle in kind of a monolithic type way. And so we we discussed with the the engineering leadership and with the quality leadership about this capability within our system. And once they got it, they they got they were bought they they bought in completely. And we help them refactor their existing data into a set of subsystems, which they now use to run regular release cycles with.

And the impact to them is that not only were we able to reduce the complexity of the amount of data that they were managing, but we also are starting to see the impact and the acceleration of cycle time for them. And at the end of the day, kind of returning to the very beginning of the talk, the the core value of system to systems is that it helps you release products in a higher quality way faster. And that's our overall goal. So, we we really appreciate y'all y'all coming and listening to this talk. We're happy to take questions for the last eight minutes if there's anything anything else that y'all would like to know about.