21. Challenge Accepted with Mathias Rönnlund

Piotr Karwatka: [00:00:00] Maybe we're just gonna start with short background info, how you started your career, what you learned in the process before you joined Mirka,  and how you landed at the company. 

Matthias Ronlund: [00:00:12] I landed in the software industry already when I was maybe 14 years old, when my father bought our first PC and you know, games weren't that great at the time.  So you couldn't fill your whole time with games. So I started thinking, what else can you do with the computer? And then I borrowed a Turbo Pascal handbook from a neighbor and that's how it took off. 

Piotr Karwatka: [00:00:47] So the PC was your first computer?

Matthias Ronlund: [00:00:51] Commodore 64, but only for games basically. And I also started  with Turbo Pascal. So I've been following that Anders Hejlsberg, who is the creator of Turbo Pascal quite closely, but with the coding languages, He is one of the fathers of dotnet also and C-sharp in particular. So, and then it took off and I went to university to study Computer Science.I did that for a few years then I actually switched over. So I actually have a Master's in Economics, but with Computer Science as a minor. And that's been, been really good because it kind of helped me switch the mindset also to the business side of things. So I think I'm a fairly okay developer. But also with the mindset for understanding why would somebody want to pay for my code so to say.

Piotr Karwatka: [00:02:01] I'm going to ask you more about this in a second, about your role, because I think it's exactly this role of being a bridge between the business and. So how you landed at Mirka.

Matthias Ronlund: [00:02:13] So I had a normal career in computer, in software development in different companies in Finland. And lastly I was at Fujitsu for a long time. Then I actually started doing some freelancing and I ended up doing some small things for me. And then eventually they asked if I wanted to jump on board full-time with Mirka. So I've been here now four to eight years, roughly. 

Piotr Karwatka: [00:02:44] Interesting. So let's give the listeners also some short info about the Mirka business because well, It's pretty close to me, like I know what you are guys doing, but not sure if our listeners are on the same page, so it would be great to hear that.

Matthias Ronlund: [00:03:01] Yeah. So Mirka is a basically family owned company from the West coast of Finland. The manufacturer of sandpaper and sanding and handheld sanding and polishing tools, basically you could say that sandpaper is our main business, but the tools are actually on the rising. Really, really growing; and they are really great tools.

That's why they are gaining so much popularity because they are really, really awesome to use. So this is basically what we use sandpaper and the tools to use that sandpaper.

Piotr Karwatka: So it's kind of B2B company. 

Matthias Ronlund: It's absolutely B2B, the vast majority of our sales are through resellers like hardware chains and, and more specialist companies distributing our products worldwide. So we operate in, I don't know how many, but maybe 40, 50 countries at least have our products on sale. Pretty huge organization. Yeah, we are about 1,500 people worldwide. So a lot that goes into a lot, are people working with manufacturing, our products, a lot of our sales, and then there's the back office staff. So to say it's where you can probably count me as well. 

Piotr Karwatka: [00:04:23] Gotcha.  How does the online and offline business split what was the situation when you joined them? What is the situation now? 

Matthias Ronlund: [00:04:33] Well, we haven't really had an online business for ourselves. Some of our resellers have set up shops in a quite limited capacity. And that is about to change now. We thought about our different eCommerce initiatives that we are doing. And but, but basically we had like online channels directly for our, our customers where they could go in and, and, and buy online. But, we haven't had an online e-commerce public presence in that sense.

Piotr Karwatka: [00:05:14] And how are the other channels of online orders? I mean, when we were preparing the interview, having the pre-call, you said about the ITI, I think that's a pretty interesting thread especially important for B2B businesses. How does it work? 

Matthias Ronlund: [00:05:29] Yeah, so we have different kinds of integrations with our customers to make ordering easier. We have EDI integration, which is the standard way of doing it. And I've probably been for tens of years so that we are doing around the world and Then we also have other ways of communicating with our customers. We have a lot of smaller customers, so they can now send in their orders even through email.

And then, then our system will pick up the attachments and create orders out of them automatically. So there are other integration alternatives also, but at the moment, we are looking more heavily into giving them a full blown e-commerce experience. Yeah, do to really engage with our customers so that they can both, of course see our products and prices and stuff like that and, and order them, but also get access to all other material that they find, and find that they need to be successful with us, basically.

So it was the situation when you joined the company that was more like. The electronic channels were used mostly for let's say Berg, B2B orders between probably other distributors users of, of your toes. Large-scale orders sent between ERP automatically. And now you are heading towards a more like digital experience where you have.

Only in shop, probably with all the product material information and other staff self-service to have those clients be onboarded directly not via the distributors. 

Exactly. So now we are building, this was actually an initiative that was mostly in the starting phase when I came aboard and to make the electronic channels for our direct customers, the resellers much faster.

So is this something we have actually launched recently? And it's speaking of speed. So, we really have big hopes for this new channel for the future, because it gives us a totally different way to communicate with our direct customers about how we are working together and, and, and.

They have a much easier way of accessing all information that is important to them, about finding all orders and tracking orders and, and all these things. Yeah. And seeing how everything is working out and finding out information about products and, and stuff like that. So we are really open for a big impact on this new channel.

Piotr Karwatka: [00:08:19] Gotcha. No, that makes perfect sense. So. When did you join the company? The online presence was almost like nothing, zero. Just the order automation process was digitized between the backend systems that the company was starting this initiative. So how is your role in this whole engagement?

Matthias Ronlund: [00:08:44] As an architect, my role has been to do a lot of technical planning and decisions on how to build up all the technical infrastructure that we need which is a lot, there is a. Yeah, there is immense amounts of information that needs to flow from correctly for the shops to work with product information and all these things. So what I brought to the table was architectural knowledge on how to set this up and also, I mean, made a cost. Core competence of course is sandpaper and tools business. So I think I also brought a bit of experience from software development projects to the table. But we have actually been staffing up even more because the, needed competencies for big projects like this, it's not to be underestimated.

That is one of the learnings we have had, but really, really making sure that all data can flow. And one of the main things that we have also been looking into is that. Not to make point to point integration. If we buy your new product, we don't want that product to talk directly to another product because then it will lock them in so hard that it will be hard to replace them, even if there will be a need for it.

And also all information that we are now listing out of the different systems. We have really hard been, looking at how we can make that information read usable. So all product information that we are gathering. For example, in our new eCommerce products, we took the beam, the product management function there and made it our new pin because it was more, and more than that, we had a lot of information about customer data and all this. We have been exposing those through, through reusable API APIs.

Piotr Karwatka: [00:10:41] That's interesting because I read on your Linkedin a quote that one of your goals is to make the miracle API first. What, what does it mean that this is exactly like what you just said that you. Your goal is not to make these integrations, just like one offs investments, like a tight web of connections, like point to point connections, but rather make it more reusable right. And I think the biggest learning that we have here is that if we integrate to our ERP, for example, if you go into an ERP systems database, that's usually full of historical decisions. You can see how it's been evolving. So the data structures in the database are both containing historical decisions, but also it's built for the era it's built by the ERP system for the ERP system.

So the data is not built to be exposed. So mainly we have built now a reusable API. Is that, that goal or battery as a backend system, which of course the ERP is, is one of the most important backend systems we are really looking at transforming that data. So it will be easier to understand for the reader of that data, that you don't need an interpreter or some documentation to understand that all fields should be named as good as possible. No aggravations that might be in the column names in the database and of course, and stuff like that. To think about the data and really think about who is going to use this data and what would make this data as understandable as possible before, because people don't have time to read, read your documentation anymore.

Piotr Karwatka: So you start with the service contracts approach. 

Matthias Ronlund: [00:12:43] Basically. Yeah, we always start with the business need, and then we try to think about what is needed now. And I usually try to think of stuff that doesn't generalize until you have at least two requirements against it, because it's hard to generalize with only one requirement.

Of course, in a project like this, you might end up with having to do it exactly that you have one use case at the moment, but you know, we need to do an API now too, to generalize this and then you may have to make a best case but really to think about how to expose today.

And I think the tricky part in exposing an API is that if the current user needs a specific data set, now, if you include that too then you really need to think about whether there any data here that maybe the next user won't use and try to split them up into different endpoints because otherwise that first data set will become so huge that it will become social or that nobody wants to use it.

Piotr Karwatka: [00:13:49] It's pretty much the domain driven design approach you need to apply on, on top of those data contracts figuring out very, very carefully To also not have the API too too broad, right? Because it makes it More difficult to use and even more difficult to maintain it.

Matthias Ronlund: [00:14:08] Yeah, exactly.

So if they are too broad, they will actually say be hard to maintain, but also probably slow. But if you have them too granular, then it might be that a user has to do three different API calls to get the data they want and then they have to start that corrugating it's so finding the balance there. This is something that cannot be underestimated. And this is, this is maybe not a development task. This is a design task, so to say.

Piotr Karwatka: [00:14:39 And how do you approach this issue like implementation wise? I mean, beforehand it was very popular to implement all sides of, you know, ESB enterprise service buses, but I suppose that is no longer the case?‍

Matthias Ronlund: [00:14:52] Well, actually all our API’s are our Azure functions. So we wanted to go the serverless route and well take one step back. I mean, firstly, we kind of made a decision when coming from an on premise setting that, that we needed to go to the cloud. And then because Amazon is already Amazon, and sure they have such an immense amount of services that it may have become really difficult for us to make the transition. If we start always comparing the different offerings. So we made kind of an Azure first decision which means that we first look in nature. Does it solve this problem? Good enough. Then we use it. ‍

Piotr Karwatka: [00:15:43] So aren't you afraid of using those cloud native things? Like no specific Azure functions don’t even contain the risk of vendor lock-in or maybe the advantage is so huge that you can ignore the vendor lock-in problem. 

Matthias Ronlund: [00:15:56] Vendor lock is interesting because that's something we have been struggling against. So of course the Azure functions that they are using now are a specific technology. But if you go in and look at how a function is what it looks like from a code perspective. So it looks like a small console application. It's just a piece of CSR or JavaScript we are using C-sharp. So of course the technology has a net that is difficult to transfer away from, but if we didn't want to use Azure functions, we could just take the code and run it any way we liked. So this is a technology we choose to use, but we could lift out the code and run it in a different fashion.

If we wanted to without a big problem, we could even run it as an Azure function on prem, but it's still just a piece of it. It's just a piece of C sharp code that gets a command and it starts executing the code. Yeah, it's it's really simple technology.

Piotr Karwatka: [00:17:20] Do you use any other, you know, more specific features of Azure? Because I also like we also discussed that (...) is doing quite a lot of EOT. Monitoring things and, you know, they have pretty cool Azure ads for IOT and other features. Do you use them as well?

Matthias Ronlund: [00:17:36] Yes, absolutely. So we use a lot of Azure stuff so far for the Azure functions. I mean, those are then from that by, by API management, which is another service from Azure to just take care of subscription keys and stuff like that. Then we afforded IOT and diverse. So, so we have like two streams for, for IOT.

One is for factory data. So we have a lot of sensors in all the machines that manufacture manufacturer sandpaper and. There we have set up quite a lot of integrations with a national service called IOT hub where we were just an ingestion service. So it's just one integration end point for everything about the vendor lock there.

It's actually in IOT, there is a MQTT and a MQP are the most used protocols. So I think if I remember correctly, we are using MQP now, but which makes the IOT hub server replace some other IOT or messaging service. So, they don't feel that we are in a vendor lock even though we have selected a specific Microsoft technology therefore for ingesting all our data.

Piotr Karwatka: [00:18:56] That's really interesting because what you are saying is that. You can still use the cloud native. It's usually lowering the cost and making easier doing some specific things or offering pretty cool UI and other features like this IOT monitoring systems, but still you can avoid the vendor locking if you.

If you base on some kind of lower level industry standard protocol is the way to go because you can then pick another vendor using exactly the same standard. And you can maybe losing some features or maybe, you know adding some features if they offer more reach experience. But you can switch.

Matthias Ronlund: [00:19:38] Yeah, absolutely. So this, I mean the data coming into our IOT hub. That goes forward to our data Lake which is basically just so we have long-term storage there, which is just basically a big number of CSV files. So, so just normal text files. We could have a habit. I mean, parquet format may be partially due. But, but they're also in our data lake it's, it's just standard. So we are using the Azure data Lake but that is also completely replaceable and the data is really easily moved away from there. If there was a reason to do so.

Piotr Karwatka: [00:20:19] That's a cool approach. I must say that you know, you have this really well-taught. I mean it's not that often the case when I spoke with the B2B companies that they have such as let's say, modern architecture, because it's very modern, but still pretty much, you know standard base. So it's sounds like a good compromise. 

Matthias Ronlund: [00:20:40] Yeah. Yeah. It's been working really well. In our sanding and polishing machines, we have a lot of sensors in them as well. And we have an app called myMirka where you can hook up your tool with Bluetooth, and then you get a lot of data out, like how much vibrations you have been exposed to because the more you use something, our tools are really good, so they don't vibrate so much, but, but anyway, if you use them a lot, you could long-term have poor blood circulation in your hands, something called Raynaud’s disease. So so this is something we are trying to avoid by having tools to help people understand when they have been, been exposed to due to vibration. But there's also a lot of other, other sensors there as well. And yeah. And we also have under, under interesting projects around the, that that are currently under development.

‍

(...)

‍