Oh, good morning. Good afternoon or good evening. Depending from which part of the world you're dialing in. Welcome to our presentation today about the importance of a healthier digital world. My name is Clarinda. I'm ac co at software improvement group.Uh I'm dialing in from the Netherlands and my co presenter via, you're dialing in from New York.

Hi, everyone. Hope you're having a good day.

Can you tell something about your role? You're a software engineer at software improvement um, at the US team. Yeah.

Yes. I'm a software engineer. I'm based in Brooklyn. I live in New York City, but I'm originally from Canada and I've lived in other parts of the world, but my background is in computer engineering and I've had about 15 years of experience, everything from starting off as a developer to a manager and now I'm in consulting.

Thanks. Yes. So different than, than, than me. I, I have, I've been, I've been experienced in the software industry for almost 25 years. I calculated it today. Um And uh but I've been more on the business side so I'm less technical than uh than V I is. Uh but I've experienced during my whole career, actually frustrations where it was about building a website and it took so much time or it didn't exactly do what I wanted to do and not understanding why that was the case or waiting for our own policy to bring to the market. And it took more time than we anticipated for, to create a feature, for example, to launch a module. And yeah, I was always felt a bit frustrated that I did not really understand what was going on and why things are the way they are. So uh when I find out about uh something uh a company called Software improvement Group where we both uh both work, um I really got intrigued by this and how, how you can actually measure the health of, of a software application. Um That's a little bit of a very quick introduction, but I think why we really care about the importance of a healthy digital world. Uh That's something I would like to share with you with a more uh personal story actually. Um Let's let's go to the next slide because um um yeah, this brings you back certainly to the year 1953 to night in February 1st, there was a massive flood in the Netherlands.

Um And um uh the Black Air Line that you see on this map is the area that was hit by these floods. Uh What happened? There was a spring tides and there was an enormous storm and there was also a low pressure and that together the result was that the sea level water could raise almost 6 m, almost 19 ft above sea level. So that's really, really a big amount and uh that caused a lot of troubles in this area. Um You can see the little island where I live. It's with the circle around it. Um That island is called Toland and the yellow dot is where I live. It's called a city, small city called Toland. So the island is called Toland, but the city as well. And um uh the blue dots that is Stanis. And um what actually happened is uh my father in law, he was standing on the dike in that same night in February 1st looking at the water raising to serious scary levels and at a certain moment, the water dropped inches and what happened? The dikes broke in stais and uh this short video will show you a little bit about how that looked like.

Uh and the fact that the dike broke on that place probably is one of the reasons why my my father in law still lives and I met my husband uh but the staff and he said it was really, really bad as amongst other places, about 50% of the population died there. So that's something, of course, the Dutch government never wanted to happen again. And uh they started a huge investment in building dikes and dams uh to prevent it from happening again. And one of the biggest dams is actually the o held a hearing. Uh This is the Oelde killing. It's a nine k long. And what is special about this is that it's, it's still open. So it allows the water from the North Sea to flow in and out the cr which is called Osters Gel and which is a very beautiful nature. Actually, there's uh it's famous for its oysters and crabs and lobsters, for example. So that is still intact due to this special dike, as you can imagine. Uh Nowadays, everything is about data and there's a lot of measure, a lot of data being tracked within this dyke, uh how much water is flowing in and out the pressure. Uh All those things are measured in systems in sulfur systems and based on those systems, the minister that's responding for this decides whether or not to close the dam. So the dam can be closed in a moment when there is a risk.

So it's super important that those systems are reliable and of course also secure. But and this is something that sovereign improvement Group is monitoring. Um So I guess this is uh my personal main story why I uh I joined SI G because I think this is really important and this is an example of nature and uh things can happen. But you know, probably some of you uh attending have Children and you see how Children are acting with technology on a daily basis, not really knowing whether they can trust it or not. So, um maybe we can go to the next slide uh V and I, we both step forward as being part of social improvement group to uh to tell our story here today. Um This is not a promo talk necessarily about SI G, but I do think it's important that you uh you know that this is a company that exists already for more than 20 years uh out of the Netherlands originally. But nowadays, we have also uh uh entities in uh in the Nordic, in Belgium and of course, in New York, the UK and the German region, um we're going to talk about how you can measure so health in a moment.

But I'm actually really curious fia what is your story? Why did you join Sig?

Yeah, absolutely. So Clarinda, you mentioned that uh you, when you joined the software industry before you joined, you were quite frustrated about um Softwares being software being delayed and not being delivered and pushed out to um uh our customers. And I was the person behind the scenes as a developer causing those delays. And uh and I know all about the frustration, creating a lot of technical debt and um I know a lot about the frustrations on being and that I became a manager. And so I've um know what it's like to be on both sides. Um And that was actually one of the reasons that previously, before I worked here, I worked for a um a global nonprofit around for teachers and um um and uh and teachers and educators around the world in underserved communities and just a lack of resources and um how we can use technology for something better and something good uh was always close to my heart and, but looking at quality and how do we do this in a good way was something that was very personal for my career.

So that's how I looked at SI G and I joined SI G because um I, I understand your frustrations all too well. But um we can take it. Yeah. And in this, um if you want to share a little bit more about um how we measure that would be great and then I can dive deeper into let's do the,

let's let's move on. Um What you will see on the next slide is an iceberg and this iceberg represents uh basically an application and the top of the iceberg is the software part that we all interact with, right? It's the functionality, the user experience. But what you don't see is what's underneath the, what's underneath the water. And that is where the real complexity is, the architecture, everything is underneath, you don't see it. And what SI G does is this is what we make transparent and we do this by using is 25 or 10 standards. And what we did ourselves is behind the different aspects of this uh standard. Um We created our own measurements. So for example, for maintainability, we created our own model behind it so that we can actually measure if we take the entire code of an application, we can measure how healthy it is. If we look at the complexity of, of the code, the entanglement with other elements, the code, unit size, all those things we can measure and based upon that site or make an, make it explicit what is good code and what is where you may should make changes to make it easier to maintain in the example of maintainability, same for security, reliability and so on.

Um Because what you don't want indeed is that you have the whole iceberg on top of your shoulders basically, if you need to make changes or updates. So that's really why it's so important to uh to keep what's under the surface basically in control and that's what we are we are here for. Um But maybe uh fia you can, can take a little bit more deeper dive in how healthy software should look like.

Absolutely. So I'll start a little bit about how, what does healthy she look like. And also I'll touch about how do we trust the technologies that our life lives depend on and how do we know when something is good enough and should we aim for perfection. And finally, I'll discuss a little bit about um how developers can identify problems early on to improve the digital health of their um system. So before I get into that, I wanted to start with what does healthy software look like. So we take a data driven benchmark approach uh to help answer this question, the chart that you're seeing on your screen is our benchmark data of all the systems that software improvement group has analyzed since the early two thousands. And so far, we analyzed about 7500 enterprise software systems totaling about 70 billion lines of code. And it comprises a variety of different technologies over 300 of them. And so each white dot you're seeing represents a system that's been analyzed and uh we measure monitor and capture the essential relationship between the systems, um technical attributes and its build quality in relation to the overall industry standard. So this is how we can measure against industry and whether or not how healthy your software is. So again, here, what you're seeing is that the typical trend we see is that um as the volume of the system goes up, the quality of the system goes down.

So when you see that downward trend that's going on, that's typically because larger systems tend to be very complex and harder to maintain. And this is a direct correlation to the number of defects that can be found in the system. So this type of benchmark data will generally help people in assessing the health of their system and identify issues early on. And next, I'll talk a little bit about why um build quality matters. So the first is cost of ownership, what you're seeing on the yellow bars here is that we found that um uh lower cost or a system that has a four star system, which we consider higher maintainability of both quality is usually generally, it costs two times lower to, to maintain that system than a two star system.

And, and it's four times lower when compared to a five star system to a one star system. And the next is the speed of development. And that's in the gray bars that you're seeing, which is we found that development takes four times faster in a four star system than in a two star system. And it's more than 10 times faster in a five star system when compared to a one star system. So the higher quality systems, so we say we have shorter defect resolution time and it's just overall important for um the business goals for organization. And, and if you, if you

look at those stars rating, oh, now I hear myself twice. I don't know why

that is, but, oh, I can hear you fine.

Can you hear me normally? Ok. Good, good. Um Those stars that you have here and also the previous slide, how does it exactly? Work, I guess it's related with the benchmark that you

just showed. Ah, yes, that's right. Um So, so we measure, so when we, I mentioned about looking at healthy systems, so there are things in the system that are, that you can actually measure in the code base. So we call them quality attributes. So we, we measure that across a variety of quality attributes within the system to tell if whether or not the system is healthy and if it works effectively and we aggregate those measurements. And typically we put them in a reading scale based on the benchmark data set that I showed you earlier and to make it simpler for everyone to understand at a very high level, 30,000 ft level what the system looks like. So then we give it a one star or five star reading and that's where you get that bunker.

So it sounds like a little bit like a standard. And I know there is no real software standards for quality yet except I think in the US nowadays, it's mandatory to demonstrate if you deliver software to a government, um the bill of material, software bill of material in terms of open source libraries that you use, don't you think it would be a good idea to do that for every aspect basically of software?

Yeah, absolutely. I believe so. So when you think about this software is just ubiquitous now everywhere it's used everywhere. And in my opinion, any industry that develops complex products and has such far reaching impacts should be using metrics to ensure quality and service.

So today can it would be unthinkable to not have strict quality measurements and governance in automotive and manufacturing industry. So in that sense, I think the software industry is lagging far behind. Um technology is changing so fast and the systems are getting more and more complex.

So I do think this would be beneficial to our end user really, whether it's a customer of a software products or tax paying citizens of the country, relying on software systems and tying that back to what you were saying earlier. Clarence about the Dutch Ministry of Infrastructure and Water Works. I know that you worked with them for a bit. Can you share a little bit about that?

Sure. Um Yeah, what was maybe nice to mention we can go to uh perhaps next slide. Indeed, that uh last year I uh I had a meeting with Pay and Health. Uh He was the Director of Development Services at uh at Eva, we say in Dutch, but indeed the Ministry of Infrastructure and Water Works and they basically own the entire infrastructure of the Netherlands. So whether it's highways, tunnels, dikes, bridges, everything, and they're in a transformation from becoming a much more data driven organization. Um So they really need to be able to rely on the software that's uh that captures that data and based upon they make decisions. So for example, if a bridge closes too fast or that can be serious impact, so they need to be able that they can trust that if ever in the past, there was someone sitting next to a bridge opening it manually. Now they do it on 100 k distance, for example, that they have an accurate, accurate view of what's happening at that moment in time. So for them, it's really important that their mission critical systems are being monitored on uh on quality, not just on build quality, but also on the architecture and security. And you can imagine security is also a very important aspect in these kinds of assets that we're talking about.

So that's a little bit of story. What I know about uh heaths,

that's great to hear. Yeah. And one of the things that we helped them out also um is with their supplier management. So they have a lot of suppliers that built their software systems along with their in house teams. So, so by using these standards, we specifically help make them make it mandatory for their software suppliers to meet si G standards of this 44 star quality built. And it helped the organization ensure that if there was any transfer of software from the supplier to the organization, they had it was a high standard and that they were getting reliable, trustworthy software. Um This also helped their development teams inherit a secure and highly maintainable software system.

So they can focus on building features and innovation.

And I think we also helped him uh what was it the end of 2021 when his look for JAY vulnerability uh was popping up everywhere, do you know what we exactly there?

Yeah, absolutely. That was a very important period. And just to give you some context there, our benchmark data actually shows that over now, over 80% or more of modern application code is sourced from third party open source software components. So the reuse of built libraries and capabilities provide such a major productivity benefit. But it also comes with a lot of vulnerabilities so and risks of using that. So one of those examples in a long series of these actually uh is L four JL four J just happened to be very public. Um And so we were able to identify that early on because we along with software quality builds, we also monitor security and open source health. And we were able to identify that early on and we notified Peter's team along with 1000 other uh client systems and, and they were able to resolve their vulnerabilities quickly and also reduce any potential incidents that might have happened. So I can actually share a clip of what they, how they monitor their system. So this is a um screenshot of just what um there. So obviously, because of our non disclosure agreements, I can share their systems.

But this is our systems, we also do measurements on open source software. So uh what it looks like. So from an open source help, uh we have one of our modules, we scan all open source and third party libraries within a code base. And we look for any risks pertaining to security, license, usage, freshness, um activity and the stability and overall dependency management. So most importantly, it highlights any uh any risks and opportunities so they can take action on it. So, and we highlight that in these um rating systems, but also these color code, um the coding systems that you see here. And I'll sure we also look at security of um a code base and this is security of the overall system. We look at the technology risk as well, whether or not the technologies are modern and up to date. And then of course, we look at the overall maintainability of system and this is a suite of systems that allows you to get a 30,000 view feet view. And also we drill down to code level view very quickly

and it just looks really cool. But I see in the previous slide as well, I saw a lot of reds and here I see five stars that means dark gr uh green. And this case J is not on five stars. What should you aim for? Should you always aim for solving all the reds uh alerts and aim for five stars.

Uh Yeah, that's we get that question quite often. So it's uh we want, we want to focus on things that you care about and they keep you awake at night. And so not everything. So we typically advise companies to identify which applications are business critical and which applications are higher risk, such as ones that are public facing or integrate with a lot of external applications over stand alone. And also we look at the severity of impact and the likelihood of a risk occurring. And then we also take a look at combination of other characteristics like how, how frequently is code being developed on that application? What's the life cycle of the application? If it's an older system that has thousands of uh person years of development, it will be much harder to get to a safe four star quality quality rating. If it's a newer application built in modern technologies, then it's advisable to aim for say four or five stars. So what you're seeing on this dashboard is sort of the overall, you know, perfect five star software assistance, but that's unrealistic in most cases

and, and you worked on both sides uh so far that was very healthy, so far, that was less healthy, perhaps.

What do you prefer? Oh yeah, that's a very easy question to answer. I prefer uh healthier software mainly because then let me go to the and uh I don't have to, you know, stay awake at night wondering whether both bad quality offer or having to manage it the next day. So instead I'd rather be on a beach in Jamaica, like in that photo, it was um uh and uh enjoy my time. This is also

reflecting a bit, I think the values of SI G, right? I think we have a culture of people who intend to help each other work hard to make it happen for our clients. And therefore we also need to have time to relax and enjoy life a bit. Uh Other core values I think are important to share. Apart from what you already saw today is fact based, instead of opinion based, you want to measure it and based on actual measurements, we will hand out the recommendations and identify risks, for example. Um But also uh our independence is very dear to heart. We want to be able to be honest in what we measure and that no one can ever accuse us of creating our own work we never will solve and we never do the work to modify the systems ourselves. That's something we leave to the teams themselves or to third parties. Um And something else that's important to us is that we respectfulness and integrity and in terms for uh uh diversity, which I see a little bit as a link of uh respectfulness. Of course, we still have a little bit of work to do in terms of diversity between male female. So I really hope that uh today, we have inspired maybe some of you to uh to join our forces. Um So let's have uh let's have a look.

Uh That's my last slide that I think is nice to share um join our forces. Of course, you can do that by joining our company or becoming a partner. Uh Therefore, uh please visit us uh on our uh in our vi virtual booth after this presentation. If you're interested in that, if you want to learn more about the models and do a little bit deeper dive, definitely join VIAS talk tomorrow via which, which time is your talk? Yeah, it's 9910 B for nine Eastern time. And your title of the presentation is

so it's about architecture. So and how to build maintainable architectures. So I'll go into a little bit into the, we just touched upon at a high level today, but I'll get into more details on how someone can look at using measurements to build maintainable.

Yeah. Hey, and if you are in development yourself already or you are a manager of an IT organization, you can start working with these principles already as of today, right? You don't need to join our company. You can do this today out of your own organization. So if you're a developer embrace clean code guidelines for yourself or for with your whole team. And as a manager, of course, you have the the power basically to implement the governance structure to measure build quality across your whole portfolio shall to say um last but not least if you have no time to join one of our sessions, please scan the QR code and join us on our SI G symposium where we will launch our latest benchmark report um where we will share uh results that we saw in our trends that we see in our benchmark with the community.

And after joining the symposium where we do the official launch, um you will also receive a copy. And with that, I think we went three minutes over time. But uh I really hope you enjoyed our talk and please feel free to visit it on our booth or uh check us on linkedin, for example. Thanks. Thanks a lot. Thank you.