Host Intro (Gene Kim)

Gene Kim: I am so excited about this first session for so many reasons. The next speakers are going to explore the frontiers of what is possible and how to create an ideal working environment to push the frontiers of what is possible for building and operating medical surgery robots at Medtronic. This definitely qualifies as a safety-critical cyber-physical system that must operate in a highly regulated industry and perform as designed in production.

To present their experience report are Tom Baker, robot behavior software architect from Medtronic, and Luca Ingianni, an independent consultant. One of the things that so much excited me about this presentation is how they thought so deeply about the role of architects in their socio-technical system, and how they experimented with very different ways for them to work with hundreds of engineers working on things that really matter, that must work safely, securely, and reliably. So here are Tom and Luca. Thank you.

Luca Ingianni

Luca Ingianni: Welcome everybody to something that looks very straightforward and natural if you write it on a slide, but of course was a lot more meandering as we were trying to figure out what it actually means to be an architect, a software architect, in the medical device industry in an agile setting. Tom and I have been working on this for two years, three years, I cannot remember. Anyway, for a long time. This is the distillation of what we have discovered over the years.

If you want to ask a question even during the talk, I will try to, or we will try to, accommodate you. Just at us in Slack, and if we have the time, then we might answer you live during the talk. If not, then of course we are very happy to talk to you afterwards.

Let me quickly introduce you to who we even are. I am Luca Ingianni. I am in Munich in Germany. I am an aeronautical engineer by training. I started out just as a regular engineer and somehow tumbled into this entire agile world because it felt necessary. I observed many teams doing their thing and struggling with it, and I felt pushed toward figuring out how to make them work together better. This is how I have now turned into some kind of agile coach, trainer, explainer, helper in general. Also, I am afraid to admit, I am a bit of a podcasting addict, so I have three different podcasts that I am running in this general area. Now I have been talking way too long. Tom, welcome. Who are you?

Tom Baker

Tom Baker: Thanks, Luca. Hi everyone. Pleasure to be here today. My name is Tom Baker. I am a mechanical engineer by training, focused on robotics, dynamics, and controls. I spent a bit of time researching robotics at the German Aerospace Center. For the past six and a half years I have been with Medtronic. The first four years I worked as a control software engineer, and for the past two and a half years I have worked as a robot behavior software architect on Hugo, the surgical robot that I would like to introduce in the next slide.

Luca Ingianni

Luca Ingianni: This is what Hugo looks like. Tell us more about him, Tom.

Tom Baker

Tom Baker: Hugo, as you see here, has basically three main components. On the left you see the cart with the robot arm, where you attach the instrument that goes toward the patient, and that is the thing that actually operates on the patient. The device in the middle is the surgeon console. That is where the surgeon sits, uses those two input devices, those joystick-looking things, and the monitors to operate on the patient. On the right-hand side, you see the tower: power supply, communications, all of that.

It is a very complex system. It has many, many, many different computers distributed across the system. It is cyber-physical. It has hardware and software that closely interact with each other in a safety-critical environment because you are operating on a patient live. Of course, it is a medical device, so the whole industry is highly regulated. Those are the challenges that you face while working on a system like this.

Medtronic as a whole: just maybe some facts about Medtronic. We are over 95,000 employees distributed in 150-plus countries, one of the biggest medical device companies in the world. We have a huge range of products, one of them being Hugo.

Luca Ingianni

Luca Ingianni: By the way, Medtronic is a big company, and you might think that big companies have big problems, or at least different problems than smaller companies, but in my observation everybody struggles with the same kinds of challenges. I think a lot of what you hear today will be directly applicable to whatever environment you happen to be working in.

Where did we start? What does a software architect do anyway? I think that is a question that many people ask themselves, but of course it was even more important for Tom because he is an architect and the question is: what should he be doing? How could he be most helpful, most valuable to his colleagues, and help them create the best, the safest medical robot that we are able to build?

Here on this picture you see the traditional architect stereotype of somebody who sits in an ivory tower and draws boxes and arrows. Tom, are you drawing many boxes and arrows these days?

Tom Baker

Tom Baker: I still do, yes. The question I had on the side is exactly what I asked myself two and a half years ago when I started this role, and what I am still asking myself now. It depends where you read. One of the first things you always read is the term architect, chief builder, or maybe super-senior developer, which just given my age and working experience I definitely cannot qualify for that title yet.

Do I still develop software? Do I abstract the software in some way? Do I then draw those in boxes and arrows? Do I constrain other developers creativity? Or do I sit in this tower, which I like this picture because it summarizes all of these thoughts together: sitting alone by yourself, working in your own environment, drawing these boxes, looking down or looking to the side at all these Scrum teams working on things?

Luca Ingianni

Luca Ingianni: We started looking around for answers. Maybe you can see on this slide, this is the SAFe so-called big picture, where you have the role of an architect. In fact, you have three of them. You have somebody very high up who is called an enterprise architect, and you have somebody who is fairly low down who is called a system architect, but it still left the question open: how does architecture work in the context of a team?

In fact, even reading all of the SAFe guidance does not really make it very clear what Tom was supposed to do all day. Does he draw boxes and arrows? We keep coming back to this theme. Who will consume those boxes and arrows? What kinds of boxes and arrows should he be drawing? And of course, even more importantly, should he be drawing boxes and arrows at all?

That is a difficult question that I think many people have grappled with before. There is a lot of stuff that sounds clear and good in theory, and then once you try to start, you find out: actually, I do not know how to fill this with life. I do not know how to be a good architect for my colleagues.

So we thought about the different levels at which we can look at this. Tom and I started to decompose where he should be, whom he should be talking to, and at what level. Tom, what was the experience?

Tom Baker

Tom Baker: This summarizes the main takeaway that I had with all of our conversations over the years. Abstractly, as an architect, I have an interface to product management and the business side, where if I come and say, I want to refactor the software because this will make us quicker down the line, they say: great, do you have any numbers to show this? It is difficult, I find. You are balancing there with new features that the product should implement. Very often you get pushback because features obviously are going to be more important. They have the bigger impact also toward patients, given that this is a medical device.

On the other end, if I interface with developers, there is tension. Am I going to change their code? It is their baby, basically, that they are working on. Also, if I slide myself into the whole development lifecycle, I am going to create a bottleneck, because there are many, many teams and I am a single person. So there are going to be some conflicts there.

If I avoid both conflicts, or the tensions on both ends, I am going to get forced into this cozy, comfy middle, where I can draw my boxes and arrows. I can dream, I can scheme, and I feel like I am doing something. But the reality is that is a trap.

Luca Ingianni

Luca Ingianni: The other thing is, you stay in your lane. You stay in the architect lane. You do not talk on the product level because maybe you ought not do that as an architect, and you do not talk on the code level because maybe you ought not do that as well as an architect. But just like Tom says, it is a trap.

Tom Baker

Tom Baker: This is where I think the ivory tower is quite interesting. It is often shown as a stereotype. I do not think it is a voluntary stereotype. You end up there if you do not do the other parts quite well. You just end up in this cozy middle where you end up in isolation. You start to get disengaged from the day-to-day more and more, and you lose connections to both business and developers. Because you want to do something, you want to make an impact, you focus on what you think you should be doing, drawing those famous boxes and arrows, which at the end no one really reads and uses.

Luca Ingianni

Luca Ingianni: You can really accidentally be pushed into this trap of the golden middle by people who imagine that this is really your role, or that you should stay in your lane, or things like that. Accidentally you might end up together as an organization nurturing the architect role and maybe leaving a critical gap.

What can we do about this? I think the important thing is really to take a step back and say: being an architect is not about drawing boxes and arrows. Being an architect is about supporting the organization, supporting developers as well as the product people, to focus on value and find out what the value is. If over the course of that you end up drawing boxes and arrows, then so be it. But the point is you need to have meaningful conversations at the level of others. The architect really becomes this pivotal point of information flowing upstream and downstream between the product at large and the development at large. Is that right, Tom?

Tom Baker

Tom Baker: Yes, absolutely. The key takeaways from my experiences are that without trust and support, there is nothing you can do. To get that, you have to focus on the value. Even though the code might not look as nice as you wish, it might not do exactly on paper what you want, what is important is what value you are adding by changing or proposing changes to the software in a certain way. Only by relating that always to the business needs and conveying that in non-technical terms, which is not straightforward as a technical person, that is absolutely key, I found.

Luca Ingianni

Luca Ingianni: Then there is the other side of talking to software developers. Maybe going down to the level accidentally sounds negative, but what I mean is really talking to them in terms that make sense to them, talking in terms of interfaces, perhaps literally sitting down with them and hashing out header files together, or whatever, and not retracting to the safe middle of boxes and arrows and saying, well, go implement this. No, you need to be in the thick of it with the developers, we found, as well as with the product people.

Tom Baker

Tom Baker: Absolutely. Here, I think key is again the vision and the goal where you want to go toward. As soon as the developers understand why you want to do it, and have some how you are going to do it, communication is still key here. That is more like a communication role rather than a technical developer. You do that in the background, but continuously talking, making sure everyone understands the why and the how. I think that is a super important bit. Often what also helps is clear boundaries with developers, knowing which parts you are going to work and collaborate on, and which parts are the developers part that you do not touch.

Luca Ingianni

Luca Ingianni: You may be wondering by now: where is the connection to medical devices? The funny answer is that there really is not one. What we are telling you is crucial in medical device development, but it is equally important in essentially all other contexts. Nothing here is really magic. It is just that our challenges are maybe a bit larger, and the need to do things well and properly and be able to document that you have done them well is important. That changes maybe the seriousness with which that role has to be taken, but I do not think, interestingly, it fundamentally changes how the role would be implemented.

Tom Baker

Tom Baker: That is where I see myself as a person of communication, translating inputs from a business side to developers, but also bringing up the developers concerns and maybe ideas of how to be able to develop more efficiently back up to the business, and create that bridge between those two.

Luca Ingianni

Luca Ingianni: Exactly. It is also interesting: I have done this in other contexts, in other medical device companies, where we have had outright analysis of communication flows. It was very interesting to see how communication flowed from one layer of the organization or one part of the organization to the other, and at which point the communication somehow stopped and was just lost. I think that is a surprisingly important part of being an architect: to ensure that the communication, especially on a technical level, on a maybe non-functional requirements level, et cetera, does not get interrupted. Instead, everybody knows what they need to know in order to make the right decisions at the right time.

So what about the boxes and arrows then? Does Tom still get to draw them? I think the answer is yes, but they really are just one of the many tools of an architect to convey important parts to everybody involved. I am inclined to say they are not the most important part.

Tom Baker

Tom Baker: Yes. Documentation is important, especially, for instance, in the medical device industry. At some point you will need to show the assessors how your system is decomposed. That is all well and good and has its value and its place. But much more important is to ensure that communication does not get interrupted between different roles, different groups.

Luca Ingianni

Luca Ingianni: This leads us to something interesting, because when Tom and I were discussing this slide, I was saying: do we still need the boxes and arrows? He paused for a bit and said: well, if someone takes away my boxes and arrows, am I even still an architect? Such an interesting sentiment. Tom, talk about this.

Tom Baker

Tom Baker: I still think the same way. It feels like that is the essential bit of what I am supposed to do. But at the end, it is just a means of communication. If that helps to fulfill the communication between both sides, great. If that helps me to create the documentation that I need to create from the regulatory perspective, fantastic. But it is not the main thing. The main thing is connecting communication, getting everyone on the same page, and providing the part of the product that you need in the regulated industry.

Luca Ingianni

Luca Ingianni: I still find it very interesting that it gave you so much pause, because I think it shows really the pull of this trap of the middle that you need to actively resist at some points.

Tom Baker

Tom Baker: Absolutely.

Luca Ingianni

Luca Ingianni: To summarize this, the main learnings we had really are that an architect needs to be more involved with everybody around them and not retreat or be pushed to the middle and accidentally be neutered. Instead, really talk to developers at their eye level, talk to product people at their eye level, and avoid this trap of being accidentally forced into the tower.

Once more, there is nothing special about this. This slide does not mention safety-critical or medical devices at all. The point, I guess, is that you need to be more careful. You need to be even more deliberate in doing your work than in other industries. But fundamentally, I think all the mechanisms and all the approaches are very much the same.

Tom Baker

Tom Baker: Those are things I am still trying to figure out, like what do I still do as an architect? That is still ongoing. It probably will still take my time for the next couple of years. One part I think is key is to use the same tools as the software developers as a software architect, and use things that are already developed in the repository as the source also to generate documentation. Maybe my boxes and arrows help, but maybe I can have the behavior of the software described not in diagrams, sequence diagrams, or state diagrams, but described in a bunch of integration tests. That is where I am still thinking through the next steps.

Q&A

Luca Ingianni: That concludes our presentation today. I think we still have time for one question that I see from Louis, who says: would it not be better to have developers and business talking to each other directly rather than funneling that communication through architects? That is a very valid question. My personal experience is, if you can get it to work, that is awesome, but it tends to be difficult to get them to speak the same language. Maybe sometimes you can just make the connection and then step out of the way and have them figure it out. But in many cases, I think you will still be needed as a translator. Would you agree, Tom?

Tom Baker: Yes, absolutely. The translation, I think, is key.

Gene Kim: Fantastic. Thank you, Tom and Luca. Congratulations on all your achievements. By the way, for those of you who are interested in this topic, Thomas Yamin, head of software computed tomography from Siemens Healthineers, presented two years ago. This is just a fabulous extension to that body of knowledge. Thank you so much, Thomas and Luca.