Sophie Rutard, Euler Hermes

All right, welcome again to another episode of Breaking Changes. I’m excited today to have Sophie Rutard from Euler Hermes. Sophie wears several hats at Euler Hermes, she’s the head of document management, ID and access management, as well as API DevRel. Welcome, Sophie.

Yeah, thanks for having me.

Well, you seem like you’re at the heart of the digital transformation going on there at Euler Hermes, and I want to understand that a little bit more, because I know a lot of my listeners are also kind of in the middle of a digital transformation in their large enterprises. But let’s start with the basics: what does Euler Hermes provide for its customers?

Well, Euler Hermes is basically the world leader in trade credit insurance. That means if you are doing business with a customer, you’re delivering goods of any kind, and you send an invoice with your goods, and then there’s typically a certain delay until that invoice is being paid. And now the risk in that is that your customer might not be able to pay that invoice for several reasons. They could afford it, but they could also just go bankrupt before they can pay that. And this is where we step in. So we will check your customer before you trade with him and give you security that if ever something bad happens to your customer, then we would pay the loss accordingly. So that’s our main product. And we have two, three other specialist insurance products, like guarantees, which is very relevant in the construction sector, and also we have fidelity insurance, which is partly cyber fraud and also linked to, yeah, internals that would expose information outside which they shouldn’t, and all these things.

So what role does APIs play in that?

Well, the thing with our insurance concept, it’s not like a car insurance where you would sign a contract once and then forget about it, and maybe if you have an accident three years later, then you would have your next contact with your insurance. In our case you really have day-to-day interactions, because you would insure each of your customers individually with us. So we would have an individual check every time you do trade, or you have a new customer. So there’s a lot of interaction, which you can do either on an online portal that we provide, of course, or if you’re a big company you probably prefer to integrate our APIs in your SAP system or your ERP system, or whatever systems you are using, and then you can have a seamless process, so it can basically run through fully automatic and just give you some alerts if you have to interact. That’s of course much easier than to handle.

You mentioned a couple, like construction and others, who are the consumers of these APIs, what types of industries?

Well, in the construction area you have the company that orders a building to be created, and so we would guarantee that the construction company that you charge with that would be able to do that, because if they go bankrupt in the middle of the construction, then you, the one investing, you have a huge problem. So you want to secure in advance that you choose the right construction companies that are capable, and especially if you have large construction sites, if you’re building a skyscraper or an industry site, a factory or whatever, you really want to make sure that you’re dealing with the right companies. You won’t just select the cheapest one, you really need proof for their stability.

Yeah, I can see it really coming in handy to manage all of the relationships that it’s going to take to put up a big building or tackle any major project. So your title, you seem to wear a lot of hats in what you do. How long have you been at the company and what were some of your early roles, how did you get started there?

Yeah, well, I’m in my 18th year now with Euler Hermes, and that’s why my title is sort of an aggregate of various things I did before, which I manage today. I started back then in Germany, I started in a customer support team actually, and that was very interesting to understand what our customers really need, how they really work day-to-day. From there I evolved over several projects and programs and so on, and in 2012 I had the opportunity to create Smart Link, which is a customer-facing API that we created then for the first time. So it was still on SOAP technology, we’re replacing that of course with REST, which is much easier, but that’s where I jumped in first time in this API adventure. And I really enjoyed the fact that it’s something that creates a huge value for our customers and partners, and back then it was really an innovation, we were the first credit insurance company to do that, the others have followed ever since. And we see that from year to year the demand is growing continuously, because this automation, this integration, is becoming really more and more, even a prerequisite for our customers to do business with us. They don’t want to do that administration manually.

Yeah, I met you through work that I’ve done coming over to Europe to try to spread the word about APIs, API Days conference, and you’re very public in what you do. Why are you so public in telling your story of APIs?

Well, it began at some point in time I was just asked to do a presentation at API the Docs, and I was sort of asking myself, why me, because I didn’t think that we are doing something very special. But then it turned out to be quite a success, I mean the feedback from the audience was awesome, and so I learned that what we do at Euler Hermes is basically something special, and we try to really invest in that and become even better all the time. And then I repeated that and did different conferences, and every time I get this kind of feedback that it’s very interesting what we do at this company, and so I find that quite enjoyable, to get that feedback. And I also think that if what we do is perceived good, then let’s share it, and that helps to create a network of other people like you who are very knowledgeable in the domain, and that helps us again to learn from that and become even better. So I think it’s a clear win-win situation.

I love it. I mean, you know, I’m an evangelist, it’s what I’ve been doing for the last decade, and getting folks to share their story and realize the value, and I wouldn’t say just value, it’s nourishing and rewarding to share your story and find that people are interested in it. Because within a company you tend to just do your work, and sometimes it just feels like work, but when you’re able to go out and tell the story and capture the attention of your audience, I love it. The storytelling part of it is really important for me, so I love that you’ve started telling the story and you continue. And one of the things I’m always trying to understand when I’m trying to get other people to share their stories is, you know, where you came from, how you got into it, telling what role you’re in and which conferences, API the Docs, API Days, which ones bring you out. But do you have any encouragement or advice for other women who are looking to get involved in the API space and tell their story as well?

Well, my impression is that there’s a general thing that we need to show to women that technology is something nice to work in. I try myself when I do recruiting to find women for my teams, and I find it very difficult, unfortunately, to find them, especially in the development area. So if you are one of those women working in the domain, speak up, be in touch with other women you see on conferences, even if you’d see just a speaker on API Days or myself, just have a chat, contact her on LinkedIn or whatever channels you have, and see how you can join in these networks that are out there. And most probably you will have a very interesting story to tell and to share, so don’t be shy, just do it, and I’m sure it will be quite rewarding.

Yes, and so there’s a lot of a network of support out there, there’s a lot of speaking opportunities there, and don’t feel if you don’t have the speaking skills or presentation skills right now, there’s a lot of work and opportunities to help you along that way and develop it. I remember when I first started speaking in 2010 and ‘11, it was hard, and I was not very good, and I didn’t have really much of a story to tell, and it takes time before you get there. So definitely, as soon as Sophie said, reach out, because it’s really important for us to keep growing the pool of women. I find it’s changed the tone of the conversation within companies, but also within the industry, the more women we have speaking at the events and sharing their stories and talking about APIs, it’s a much more enjoyable place to be.

Yeah, I had a lot of discussions around the imposter syndrome on conferences, and I think it tends to be more present in women, to think that’s not very special what they do in this technology, but again, it’s mostly not true, and on the opposite, it’s mostly very interesting. So it’s definitely a recommendation, just be in touch.

Yes. So at Euler Hermes, does the leadership know about APIs, are they aware of APIs and what they do?

Yes, definitely. When I started it was very difficult to explain to someone in the business, first of all, what is an API, why is it relevant, and why should they engage in any way. It was partly even perceived as an obstacle to the customer relationship, because some of our distribution staff feared that this would complicate the relationship, because it’s technical, so they have to have the resources and we have to explain and so on and so on. So in the beginning of my job I spent a lot of time evangelizing internally and trying to explain that, and proving then, based on good customer feedback, that it is something valuable. And since, I would say, two, three years, this has completely changed. Up to the C level, everybody knows why we do API first and why we push this enormously. It has been validated with the CEO and with basically everybody, and so we shifted from explaining what it is to explaining how we make it operational, and to looking into actual business cases of our APIs when we prioritize them and so on. And that makes life easier.

You use the phrase API first in there, what does that mean to you and your teams?

For us it means that before we do any coding and development activities, we ask ourselves, what is the purpose of an API that we would want to build, what is the business value of it? And once this is set, then we try to do a design that’s easy to understand for somebody who’s not an expert of our business or even our technology, because it should be completely disconnected from these specifics. So then we try to create this OpenAPI spec, and then develop it on basically cloud native architecture.

You have a public API portal that you have as part of your organization. What’s the vision for that, is it everything you want right now, or is it still more of a work and process and a journey? What’s your vision for the future of that portal?

For now it’s still in an early phase, I would say. First of all, I differentiate between public and semi-private, because the APIs we provide today are mostly supporting the business that we signed, so the credit insurance contract for example. So there’s no public usage for those kinds of APIs, if you don’t have an insurance contract then you can’t use them. But we have created an easy onboarding process for our customers and partners, so once we have a commercial relationship, they can just create their accounts and it will be available very quickly, and then they can see all the APIs that we have for them today. This is yet limited to the credit insurance domain mostly, and I would like us to provide a full-fledged functional scope for all our products, to really, let’s say, standardize. If you have a product with us then you can use it by API, because in the end every service that we build, we build it based on APIs to integrate it in our customer portal afterwards. So it’s technically completely possible to directly use them, integrating in their own software.

Part of this standardization I’ve heard you speak about before is API design, good API design. What are your principles for good API design across all of that?

The principle is to make it as easy as possible, so we avoid any technical artifacts in this specification, we avoid vocabulary that would be too specific, that would need expert knowledge. There’s a lot of education around that actually, because our internal colleagues sometimes are used to the abbreviations and the terminology of credit insurance, which can be quite particular and people won’t necessarily understand if they are new to the business. So we try to find simple wordings instead that we put into the specs, and the ambition is always that a developer of our customer can rapidly understand what this API is about. And the developer of our customer will most probably not know what credit insurance is, so we try to keep it simple. And then the second principle is of course that we try to have consistency between our APIs, because we have a lot of them, and we create them with quite autonomous teams. And so we created an API governance entity that has issued a design guideline with basic principles, and that helps, on the one hand, in coaching all these squads and all the newcomers, and then is also controlling in the deployment chain and CI/CD, that whenever there is a new OpenAPI being specified, it goes through a validation step, the governance, before it can then be actually developed and deployed to production.

How much of that process is automated versus training and education for those squad team members?

The process of deployment is rather automated, but the checks and the coaching is fully manual. We have been looking, and I think we haven’t given up so far, but we’ve been looking into API linters to help us and to reduce the workload for the governance team, but yeah, when we first looked at them, it seemed too technical to actually help us. And I think there has been a lot of evolutions ever since, and we just need to find the time to look at it again and see how we can possibly integrate it in our process.

Yeah, I would say it’s still right at that edge where, and I’m an expert in the linting rules and all of this, but I still feel like it’s a whole nother vocabulary and language that I have to learn, it’s a whole nother rules engine that I have to think about, in addition to the API design that’s going on. So I think this is something that needs more investment in the open source space as well as with tooling vendors to help support companies in their journey. That education that you provide to these squads and teams, can you talk a little bit about that, like, do you have classes and workshops, is it more inline and ongoing as they’re developing APIs? How does education and awareness work?

We currently adapt, so to say, to each squad and the individual needs that we see, because we see teams that are super mature and they come up with a first proposal and it’s almost good, that’s the best case. And then we have of course also other teams, maybe teams who are not really familiar to API technology, and well, we have seen some designs that we had to reduce completely. And so in between that, our governance team tries to understand how they need to adapt to each team to get to an overall good result. What we have just recently done, I created a webinar that can be reused internally to show a bit the general principles that we want to see, the general workflow of how we perceive API first, for example, what it means for us. And we did that in sort of a funny way, to not have this e-learning that you have to do and that is maybe not so interesting. It’s a funny way to discover in a first step, and from there on then we can work more individually. And we just discussed this morning to have a second version of the training to go more into the details and, I don’t know, say teach about what is a pagination, it looks like this and not like that, this kind of things. Maybe we can do that in the second half of the year.

Yeah, those types of materials are super important to help introduce people to all of these concepts that I’ve learned along the way, and I’m not always aware how to share them with teams, and so I’m always looking how organizations are doing that. Besides making it funny, how do you incentivize team members to learn about good API design and what’s needed?

Well, of course we are in touch with the team’s managers to make sure that everybody knows that there’s a process and that it’s necessary. And then we’re not doing a lot of policing in what we do, really, we try to go into the process early, maybe in the first design sprints we can participate and give our opinion. And as we do that, the teams see that there’s some value in what we do, and then overall I have not seen really refusals so far, I think it’s working quite okay.

Good to hear. So how do you prioritize what APIs or microservices are needed to support business, is it business leadership, is it customer led, how do you prioritize what gets developed?

We have a small number of very big programs going on currently as part of our IT transformation roadmap. The most important one certainly is what we call MyEH, it’s our customer portal that we have created from 2019 on. And as this has the most direct customer impact, that is sort of driving the prioritization. So we are aligning them with the businesses locally, what are the features that are most valuable for our customers to be added to that, and these will probably drive the APIs that are treated first. It can be that there is some transversal or more technical APIs that are then just prerequisites to make this work. For example, the user management that I’m in charge of, it’s the basis for all the security of everything, it’s a zero trust environment, so of course that has then also a very high priority, because sometimes a business feature could not be delivered if we would not have done our work. And so we have regular, we call them big room meetings, where we get all the programs together in one big room, or maybe a big WebEx session thanks to the pandemic, but there we try to align all the priorities between the programs and find one logical critical path in between them, and then make visible to everybody why this or that feature is now the most important one, and then each team will align to that and have its own roadmap then corresponding to that. It’s not super easy, but it works, and I think we haven’t seen anything better for now, so that’s quite okay.

Yeah, that sounds like it really gets the business and the technical people and details in alignment and moving forward in a meaningful way, when this is responding to your customers and your business goals. I’m hearing more, especially in Europe but also in North America, regulations and government influencing the direction that enterprise organizations are going, because the industries they operate in, and influencing APIs. How does regulations influence how you do APIs?

As I perceive it today, the influence is not in the API design like it would probably be in banking with PSD2. However, there’s of course a lot of regulation around the IT security and the auditability, the possibility to restore in case of a disaster, to prove to our customer that a certain information has been transmitted. And if ever in a trial somebody would claim that you have confirmed they were insured and they were actually not, because we need to be able to prove that, and that causes a lot of investments more in the less visible parts. So it’s a lot of the actual IT infrastructure, the architecture on the cloud that is influenced by that, and it’s actually quite interesting to put in place these procedures based on a cloud platform. Yeah, so it’s not very visible to the customer, but it all happens in the back end, and it keeps us quite busy.

Do you find APIs make it easier to deal with this regulatory complexity and challenges?

No, I don’t think so. It might even be easier in the old world with your own data center that is in your own firewall and so on. Although I tend to believe that it’s more secure to be in a zero trust environment on the cloud than what it was before, but from an auditability perspective it was easier to prove the process that were in place and to control them. But again, it’s an IT transformation that we’re doing, and it’s definitely possible, and we have to implement these mechanisms, and they work very well then.

What is your favorite part about your role and what you do?

My favorite part is, you know, for example when we are able to have our developer portal better, easier accessible and more valuable for our customers, and when I get then a feedback that confirms that, I’m still very, even if in IT I’m not in direct touch with the customers anymore, which is sad but that’s what it is, when I then get this feedback…