CloudBees Automotive – Andreas Dharmawan
In this keynote, Andreas Dharmawan of CloudBees will share his experience on what Automative enterprises are doing to adapt and excel in this software-is-eating-the-world era. Automotive OEMs and Supply Chains are experiencing more and more software requirements due to the the increase in electric cars demand and in autonomous driving trends. Automative companies are asked to deliver higher-quality software faster, despite the limitations in budget and resources. Working relationships among supply chain partners are strained as the number of requests is higher, while the software delivery cycle is shorter. Integration test becomes very stressful as the compressed development and test cycle lead to more bugs. How do enterprises in the Automative world cope and adapt?
Transcript
Hello, everyone. Greetings from San Francisco. Thank you for joining us.
Today, I will talk about how CloudBees and its client, the automotive industry, are successful in accelerating innovation, mitigating risk and increasing efficiency by embracing diversity in tools, processes and teams. First, I will cover emerging powerful trends that I'm sure you guys are aware, but it's worth visting to put context to our talk today. And then I will explain CloudBees point of view and approach in resolving challenges in automotive software delivery.
In some level of detail, I will cover our automotive use cases that we have worked successfully with our clients and then also I will explain the transformative benefits and at the end, I will summarize it all. When we read technology news today, we cannot escape reading Internet of Things, drones, robotics, autonomous vehicles. Electric vehicles, passive and active safety.
ADAS, vehicle to vehicle or vehicle to infrastructure communication. 300 million lines of code in today's hybrid car. It's no longer big news.
To add complexity. In today's car, there are software components that reside outside the car. Today's driver can interact with the car via his or her mobile phone.
When a mobile device is involved, there is a third component that reside in the cloud. This is the server component that interact as the intermediary between the mobile device and the car. But this server component in the Cloud, also acts as a big data processor.
It monitors the usage pattern. It catalogs error. It also meters the usage for billing purposes, for subscription surfaces.
Now, we are also accustom to our mobile phone. How frequent it gets, the software updates. With the increase of innovation on subscription surfaces that are available in the car, people are expecting frequent updates as well.
So over the air updates, are becoming a must have. If you put the requirement for a driver to go to service department of a dealer to get a software update, this requirement will turn away buyers. Also, it will break the service department because they cannot keep up with the volume of appointments and the frequency of software updates.
More importantly, when a car design team designs a car today, it must concede three target environment for the software components. The car, which is the embedded software, and then the mobile device, which is the app stores, and then the cloud for the server software. Now, the tsunami of software requirement are hitting automotive industry.
The costs of not being ready can be extremely painful and it may impact future revenue. When we work with our automotive clients We are hearing these five common challenges. Some clients prioritize certain items higher than others.
These common challenges are also Experienced by companies and embedded software involve in medical equipment, Aerospace and defense. Mobile devices, networking gear, And we are all coping with the ever increasing powerful for hardware and more sophisticated software. Let's talk about CloudBees point of view.
This is a very complex chart, but this is very common. We discover this every time we do an engagement with our prospects and clients. The R&D team, They are all want to actually be more HR in delivering software, so they tool up.
They also implement lift shift left testing And increase the number of tools and automation, many of them actually are reporting, good result that they are able to Deliver software faster and safer. However, as they scale up, they are having trouble in having a visability and insight into the collective health of the project. Because many project teams that are working on various components, they are all working with separate tools, separate processes, separate automation.
As the number of components grow, the number of things grow. They are all becoming more disconnected. They are disconnected because they are siloed tools.
They are siloed processes and siloed teams. The disconnected problem increases as the organization scales up. Now, some technology finder May recommend to solve this disconnected problem is by moving into a giant all in one system.
However, we disagree because this is a software anti-pattern. Additionally, if prevent us to use a purpose fit tools. Especially in automotive, Sometimes we have or we must have a purpose fit tool to actually push the boundaries of innovation.
We have a proprietary tools in our tool chain and that will increase our competitive advantage. This giant all in one system will prevent us to actually use such tools. Furthermore, technology and tools changes very frequently in today's world.
When that is new technology that we want to adapt, this giant all in one system may prevent it or slow it down. The other thing also, this all in one system ignores the reality in enterprise, which is multi model and diversity. So what's the right approach?
We believe you should keep your existing processes and tools because the investment that you have made in tools, processes and skill are valuable to you. In our unique approach we add orchestration layer. That will orchestrate many of the existing islands of automation.
And then we also add our rule and policy layer. And a unified system of record. That will normalize data from all tools, all teams, all processes and bind it together.
We are also getting recognition by using our unique approach, embracing diversity. We are getting third party recognition from Gartners. We are the leader of Gartner application, real orchestration magic quadrant for several years in a row.
We are at the edge of the graph leading companies. The leading company here for continuous delivery release automation. Both analysts, recognized us to have the most complete solution for the different roles in SDLC.
And they place us for our visionary roadmap. Let's now talk about the specific automotive use cases. In general, we have three solutions.
Three, solutions that we want to cover today. The first one is the acceleration solution. This solution addresses the challenges of not having enough time to do component and integration testing and slow software build and tests.
This acceleration solution is basically our patented technology that will distribute task so that it can be done in parallel in many, many machine. And this parallelization can be done in your existing hardware or a cloud in environment or a hybrid. The second solution is our orchestration solution that addresses the long, tedious manual hand off among many islands of automation and also address not having the end to end visibility of software lifecycle.
Here, our solution, embrace diversity by adding orchestration layer, rule and policy layer and the unified system of record. Lastly, in terms of the challenge of dealing with growing or exploding number of software Supply-Chain in your ecosystem, our orchestration solution can be used to templatize your best practices, abstract and templatize your best practices, your success criteria, and extend those best practices and success criteria to your suppliers. We'll talk about that in detail later.
Now, this is a graph from our clients. The graph on the left shows that when our client increased the number of component in the system, the build and test time increases linearly and then toward the end, It start to increase exponentially. In the middle, there is a slight dip where they added more powerful hardware but the management team didn't want to continually solving the problem with a hammer.
So they asked them to look for a solution, alternative solution. And that's where we mapped. The graph on the right hand side is the graph, when we are introduced, you can see that point in time in the graph where CloudBees solution is introduced.
Notice that immediately with our paralyzation technology, it's a patented paralyzation technology, We are able to distribute the task of build and test into many, many machine. And then the build and test time decreases as the number of component increases. However, that is a period when the build and test time is actually going up again.
Our acceleration solution has also additional capability. It actually monitor the real time dependency as the object files are actually built. By looking at the history file, we can identify areas where there is a lot of conflicts or there is a lot of object rebuilt.
By analyzing the history files, you can actually perform optimization in your makefile. With that info, additionally, this took also give you a forecasting capability. If you were to add additional machine, how much more acceleration you would be getting?
We provide that analysis as well by combining the history file and then the forecasting capability on possible acceleration. Our client is able to optimize the resources for paralyzation. And then since then, they are able to continually reduce Their build and test time and then they happily, continually adding components for because they want to push the rate of innovation.
Second use case. This is from another client, went they are actually using our acceleration solution They find that they are able to increase the frequency of CI in a day, and when they look and analyze after a completion of many project, they when to look into JIRA and run reports. The JIRA report basically say that with the increase of CI, they are able to find the bug big sooner in the SDLC.
When they find the bug picks sooner in the SDLC, they have an easier time to resolve bugs and to actually release the component on time. So the need to be in the office for 12 to 14 hours a day and then the need to be in the office on weekend, are no longer needed. Right.
Because now they have much more predictability. Furthermore, what they are finding is that by using our paralyzation technology, they are able to pool their resources. They have teams that are collaborating in North America, Europe and Asia by pooling their resources, and thanks to the cheap bandwidth and high speed connection, via fiber optics under the sea as well as satellite link.
Right. They are able to pull the software resources such that they don't have to have siloed resources environment for each team in the different time zone. And by doing that, they are able to increase their utilization on the resources by 90 percent and reduce duplicate resources.
So they are extremely happy with that result. Just to put things into perspective in the automotive V-model. You can see the blue shaded area here is where our acceleration solution is actually applicable in the V-model, that V developement model in automotive.
Now, next, I'll talk about how we solved the long, tedious manual hand off among many islands of automation and not having end to end visibility in the software lifecycle. Here is a simple implementation. We have Used our orchestration solution to orchestrate many, many islands of automation from left to right here.
And because we are the one that actually executing the tools or islands of automation, we know who does what and when. Additionally, we collect the data from each tool input, output, and lock files. We put this in our unified system of record and we also normalize the data.
Normalization is important because our solution, as the process moved from left to right, as the solution is collecting all of this data and normalizing them. Our solution grows in knowledge in terms of what has happened in the process. This normalize data then can be aggregated into dashboard, drilldown dashboard so that you can see the health of the project.
In many different tea across the globe. And furthermore, you can customize our orchestration solution to collect evidence, certain type of evidence that automatically you can use to generate compliance report whether it is security compliance or regulatory compliance, such as MISRA and ISO two six two six two. The additional use of our normalized data is actually, you can use to normalize data at any point in time to make automatic or manual approval so you can put gates in many different stages of your development and test stages where there is need to be some kind of approval based on regulatory or security success criteria or just proprietary criteria.
Right. And you can automate this gates by looking at certain variables that need to be met. For example, do not do hardware in the loop testing unless software in the loop testing has passed with 99 percent rate that can be automated.
Right. For example, or you can collect certain evidence and then package the evidence into a very simple dashboard and then send the link to test that board to the person who will approve to move to the next stage. And then that person can look at it using his mobile device and then click, yes, I approve this to move to the next stage.
Now, as I mentioned earlier, because we collect data, we know who does what and when. We also collect input, output, and lock files. We do this for every single project and for every single project execution.
Over time, you have historical data. The historical data will be able to show you trending information. So you can review whether after many, many runs of a project, a successful project.
You can see whether the team can deliver the project faster every time, every iteration or about the same. How about the bug escape Rate? Has it been trending up or trending down?
All of this trending information and historical data can be analyzed in many, many dimensions. This allows you to have a predictable process, hence meeting the SPICE level four. Additionally, our orchestration solution, it captures the time lapse for each stage in your process.
So, then you can go back after the completion of a project, you can see where is the long duration stages or where are certain specific tasks that takes a long time. This information is very useful for you when you're trying to optimize your process and helping you to achieve the SPICE level five here. Now let's talk about how to use our orchestration solution to help you in scaling your supply chain.
Before I start here, I just want to highlight the fact that the solution pattern that we discuss above is actually applicable when you work with your supply chain. Thanks to the growing popularity of our common powerful ECU platform and then the increase in sophistication of software that drive innovation in car dynamics, infotainment, autonomous driving, safety. Right.
The number of software supplier for OEM's are exploding. The number is just growing right, every day. Pandora, Apple, Amazon Music, Google are now part of the OEM supply chain.
So let's take a look at the two cases here. I will explain, one by one. Case one is when you need to use multiple supplier to build the same component with the same spec, because each supplier cannot deliver the number, the amount that you require.
So in this case, you just have to distribute the workload. Right. But the spec is the same.
So our orchestration solution, first of all, you are already successful in using your orchestration solution to coordinate your global team. So. The rule and policy, the role based access control for segregation of duties and also the toolchain in terms of best practices in the toolchain.
All of that that works in your inter department process, right? Globally in your organization, It can actually be abstracted up And we can templatize that. We can remove certain thing that is proprietary so that you can actually have the abstract of your best practices.
The abstraction leader of your best practices. And then you can actually turn that into a template. Now, with this template, we can say, let's do a validation template.
This template then can be shared with your suppliers. Now, there are multiple ways of doing this. You can actually open up part of your data center with a certain area where your supplier can log in or you can use a cloud resource.
Once this templatized validation environment is available, then its supplier can work on its own workspace, so Supplier A cannot see the progress of supplier B, but you can see the progress of both suppliers. And in this case, then they can actually do validation testing before they submit the component for your integration testing. Because they are using your template, then the likelihood of that component to be successful in your first run of your integration testing is very high.
Right? So in this SVEC environment, supplier A will log in and then perform the software component validation testing, supplier B will do it the same way, they cannot see each other work. However, you can see the progress of both supplier.
That is how we can share best practices with our supplier and reduce the risk of having many, many attempts on the integration testing, once the component arrive at your location. Let's talk about case number two. In this case, you are building a system that contains component A, B, and C and you need to actually distribute the work to highly specialized supplier that knows how to build A, knows how to build B, and knows how to build C.
And then once they are finished, you are the one to assemble A, B and C because you understand the dependency, and then create a bigger system. In this case, the solution, the validation template that is shared in the shared environment for case one is also valid for Case 2, but now our solution, in our solution you can at dependency, rules for component A, B and C. Once you work our solution, understand the dependency rule, you can actually orchestrate the process of assembling the software component together and then you can automate the process of software in the loop testing.
In some cases, We can go as far as the hardware in the loop testing automation as well. So there's that orchestration thing. All of the software component and put it together as part of a bigger system release.
The other thing that is important, you can put deadlines for the different stages the Validation test template, you can put deadlines as well. In such a way that you can see as the supplier A, B, and C interacting with your shared environment, you will be able to see how well they are doing. And if one supplier is running behind, you can actually detect and predict the potential delay to the overall delivery of the bigger system, the orchestration of release.
OK, so let's talk about the transformative benefit. While I cannot speak in details, I can speak in generality. We have many automotive clients, some of them actually have been working with us collaboratively for seven to 10 years.
They are Tier 1 OEM's in Asia and North America. Tier 1 suppliers in North America, Europe and Asia. We have experience working with our powertrain, chassis, safety and infotainment division.
Now, I also wanted to share with you our customer in embedded space, because as I mentioned earlier, the challenges are actually the same. We are all dealing with highly, very highly powerful hardware with sophisticated embedded software. S.
Aerospace and Defense and then their ecosystem. As far as the benefit you can see, we have accelerated processes, right, from what used to take weeks into hours and then in terms of build and acceleration specifically what used to take hours, becomes minutes. And because of our unique approach in embracing diversity, it's very easy to connect the global team to provide that global visibility on how well collectively the teams are doing in these various projects that makes up a bigger component.
Right at the end result is basically they are able to produce component or system faster to market with higher quality. Now, this is a table when I categorized the benefit based on the solution, that is solving those challenges in automotive. We will make these materials available for download so that you can actually take a look at it in detail.
I am also available for one on one conversation to double click on any of the topics that we have discussed above. Now, lastly, I just want to again remind, highlight our point of view. Embrace diversity.
CloudBees and our clients in automotive have been collaborating and we have Proven it, that it is possible to accelerate automotive software delivery. And all of the technical advantages that we discussed in the automotive cases above, resulting in our client's ability to increase the rate of innovation, the ability to mitigate risk, and then also increase efficiency. Thank you.
And I'm looking forward to have a dialog with you in our panel discussion as well as future meetings. Looking forward to working with you.