6 min read
All of the research into DevOps tells us that it is the most efficient way to deliver software. But, what does DevOps look like in places where you have the extra friction that comes with embedded systems and regulation?
Typically, software innovation starts in the cloud, moves to the embedded systems world, and then to the IT world. This may be surprising for some people, but the embedded world is usually ahead of the IT world because, despite the challenges you mention, in the embedded world you’re building products for customers. And that drives innovation.
Why does innovation follow this particular path?
It’s easiest to experiment in the SaaS world where the barriers to adoption are low, so everyone there is doing DevOps, everyone is doing A/B testing, and the positive outcomes are there for everyone to see. You then start to see these practices moving into the embedded world because the people there desire the same efficiencies. For example, in telecoms it’s already quite normal to see a software release every two weeks. These trends that begin in the SaaS world soon spread across the rest of the embedded industries and then into the IT support areas.
Two weeks is impressive by historical standards, but it’s still quite a long interval compared to what we’re used to in the SaaS world. When can we expect two weeks to be reduced to two hours? Or even 20 minutes? Is that realistic for the embedded world?
Achieving bi-weekly deployments took a very long time - many years, in fact. The telecoms organizations who are doing this had to change their whole culture to get deploys down from six months to two weeks. We can’t overlook how difficult it was just to get this far. It’s quite possible to see a further reduction to weekly and maybe even daily deployments, but I don’t think anyone is talking about 20 minutes.
Is that because eventually you hit a wall with automation in the embedded world where it’s just simply impossible to go any faster?
Well, the other thing you have to consider is the business dimension. Can you monetize pushing new features to the market on a regular basis? In the case of SaaS companies, running A/B testing to increase conversions gives you immediate payback. But, where is the incentive to run A/B tests in cars to make a tiny increase in fuel efficiency for a vehicle that you have already sold? It’s difficult to make a business case. The business model has to align and that’s much easier in the SaaS world.
Is talking about “embedded systems” in this context a bit of a generalization? I expect the challenges in telecoms and cars are very different?
There are certainly different types of friction, but to speak in general terms for a moment, the customer has much more influence in the embedded B2B world. I see companies moving towards DevOps and continuous deployment, but they also have to work hard to bring their customers with them. That’s one type of friction that a lot of DevOps companies in the B2B embedded world have to face.
We also see that in the B2B SaaS world. When you’re early the market sometimes isn’t quite ready to adopt what you’re building - even when they can see the value.
Yes, and the same is true in embedded. The second big source of friction, moving a bit closer to what you’re doing in Kosli, is regulation, and here’s where the differences really emerge. For example, telecoms don’t really have much regulation. They need to have certain approvals in place, and they can expect huge fines if something like an emergency number doesn’t work, but overall the regulation is quite light.
And they can self-assess before the release.
Yes, and you will find that self-assessment is standard practice in other areas where there is much more regulatory friction. In the car industry you have ISO26262 as the typical safety standard and car makers will have their own in-house ISO assessors to verify that they have operated according to the regulations. But, it’s still an internal verification process. Beyond that the next level of friction involves external approvals. So, with medical systems, you can’t make the release until you have received approval from an outside body like the FDA. And that’s obviously a source of great friction.
Of course, B2B SaaS isn’t free of regulation either. Take fintech, for example.
Yes, and they can also self-assess, so the whole process is in their own hands because they don’t need an external assessor. All they have to do is maintain a track record that they have worked and operated according to the regulation. What they need is automation. And that’s why, if we look at Kosli again for a moment, fintech is the obvious place to start when you’re looking to automate regulatory tasks across all of these industries.
Can we expect DevOps adoption in embedded and regulated industries to proceed according to how much friction has to be overcome? With B2B SaaS as the early adopters and healthcare at the other end of the curve?
I think that’s a reasonable expectation, but the next thing after that will be A/B testing. I believe that once everyone is practising DevOps, A/B testing will be where the innovation happens in areas like cars. So, let’s take functional safety. Creating an effective warning system in a car requires a very complex interaction between the driver and the vehicle. And it’s quite easy to design something that would make risky situations even more dangerous.
Can you give me an example?
Let’s say the alarm you design is too noisy or distracting and it scares the driver. This is exactly the sort of thing you can overcome with A/B testing. You can try all sorts of different ways of raising the alarm and then monitor the reactions of the drivers to figure out which variations of the same feature produce the best outcome. But, and here’s the key point so far as we are concerned in Kosli, every one of these alternatives needs to be tested, needs to be certified, and needs to be verified against the procedures and regulations.
Is this why you see potential in what we’re doing at Kosli?
Every company in the regulated space will want to get to DevOps. No question. And they’ll want to get to A/B testing. Then they’ll want all the other good stuff that comes from having quick feedback loops in the field for data-driven decision making. And they will all need automated solutions to ensure that they are adhering to whatever the regulators are asking of them.
If you enjoyed part 2 of our interview with Jan you might like to read part 1 and part 3 . You can also find Jan’s latest news on his website.
And if you want to find out more about doing DevOps under regulation talk to us via the link below
