The wave of APIs taking over the world manifests not only in new companies springing up that are absolutely reliant on APIs, but also in transforming industries that have been around for hundreds of years. For one, the entire automotive industry is heading in the direction of being an ultimately API drive ecosystem.
In our latest podcast episode, we spoke with John Musser, the director of Data and Analytics for Ford Autonomous Vehicles at Ford Motor Company. John was attracted to Ford because the automotive industry is undergoing massive amounts of digital transformation through connectivity, electric vehicle expansion, the introduction of self-driving cars, and more. I chatted with John about what it takes to pioneer that digital revolution and the skills needed to guide a new wave of developers through the API frontier.
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
All right.
And thanks for everyone tuning in again to API Intersection podcast Super Stoked today we've got Anna for co hosting from Stoplight.
It.
And you can tell us a little bit about yourself and super exciting guest today with John Muster, old friend of mine been through a lot of different places and swap notes over the years.
But John spent the last few years at Ford, and we're fascinated by the work he's done there.
So you guys and give us a brief about yourself.
And then, John, you take a few minutes.
Kind of tell us where you're at.
Okay.
Sure.
I'm the product marketing manager at Stop Light.
I get to work with Jason a lot, which is pretty fun.
I'm helping kind of tell our story in the marketplace, and I am very excited to talk to John because Jason and I were geeking out about being Ford families.
My husband's family goes way back, and so we both drive matching Ford Fusions, so I'm very excited to talk about the opportunities of connected data and everything that you're doing it for.
That's awesome.
Alright.
Yeah.
Thanks.
And John, I guess give us your kind of intro about a little bit about who you are for probably a handful of folks that don't already know.
Well, again, thanks for having me on the show.
I'm currently afford the director of engineering for Ford Pro, which is a new division focused on commercial customers, fleet customers.
We'll talk more about that later.
I suspect I've been a Ford for four years, and I came to Ford having spent the last 30 years sort of in in various parts of startups and big companies.
And have you found a programmable Web in 2005? I spent the last 15 years in APIs and way, shape or form.
Right.
And part of what was attractive to me at Ford was here's this industry that's going through this massive transformation of connectivity and electric vehicles and self driving cars and under the covers.
So much of that is going to wind up being API and platform and ecosystem driven.
So I've had an awesome time at Ford and a bunch of different roles, but part of the thread there is API's.
Yeah.
So, you know, I think the bit that is probably like dusting off the cobwebs for you, but we're particularly interested in certainly at Stop button.
I know that's what people tend to listen to podcast for is kind of how API governance became a thing.
And that it sounded like that's kind of where you got started at Ford.
Yeah.
And how do we bring order to this and for on the order of, like, 1800 plus employees or something by last numbers I checked.
Okay.
And of course, you think of Florida as this vehicle manufacturing company that's been doing it for 118 years.
But behind the scenes, there's large self engineering organization that keeps going larger.
We're hiring, by the way, because it becoming digitally enabled.
Right.
So if you think about any large It organization, a Fortune 500 company or Fortune 20, in this case, you have lots of teams that are building sort of API products across the organization.
Some are public facing, some are internal, some are related to the car itself.
And so one of the things that we early on when I came to Ford, we were looking at doing some public based API's, and we've done some of that.
But also we realized just how many internal APIs we had, and it was quite fragmented.
So how do we go about bringing more order to that chaos of the different teams? So we stood up a team called the Platform Enablement Team.
And originally it was a small half a dozen people.
And now it's closer to 100 people who are all focused on APIs across the company in any part of Fords, whether it's for credit or the self driving cars, how do we start to do governance has one piece of it and not heavy handed hammer type.
But how do we make teams? How we up level the whole organization and we have the executive buy in from the very top so that you don't have to sell the idea of APIs or doing it.
Well, everybody's bought in.
So then it comes down to okay.
Yeah.
Yeah.
It's a good question.
Just like any API teams, they have to be a bit multidisciplinary because you're going to need some engineering folks who are down understand building software.
Right.
So some of those teams are actually building software.
Others are doing evangelism within the company.
So they're out there customer success solutions team to kind of help other teams bring up their API level quality or how to get them into the right pipeline.
We have.
Then there's some strategy teams looking across this as we start to look at what we're building, what should we be building? What's going? Well, where do we need to change things? Do we have any duplication, any big company, you're naturally going to have some pockets of things that look similar.
Yeah.
I think it's one thing that stood out for me for Ford for the last few years.
Very notable for me that we had high level Ford execs coming to API conferences five, six years ago talking about the commitment to it.
I think that stood out for me that there's something different going on there when I would add a note here that first of all, calling an enablement right out of the gate.
Okay.
That's the thing we've heard.
I don't do center of Excellence to enablement model.
All right.
I think starting with six people, definitely indicative of start with a small group that's building a broader kind of Federated approach.
And even at 100 people, I would just point out we're talking half a percent of the population of the company, so still incredibly small.
Granted, at other companies, 100 might sound like a lot.
Right.
Yeah.
So that's like taking a lot of the boxes of things that we hear about what makes successful programs.
First of all, so part of the question for any big company or even smaller sometimes, what APS do you have? What do we got it? I'm sure you see this all the time.
Yeah.
Right.
Again, because one of our initial work streams was API catalog.
So we registered the internal domain of API catalog four com set up.
Okay.
So what are we going to start to build there as a go to place.
That's not a totally generic API catalog, but have more substance that makes sense to our environment.
And then we started to add to that.
That's the catalog.
Like what we got.
And is that sort of an internal web based portal that we're talking about or does catalog mean more than that? Okay.
Right.
So that's part of the yeah, it's an internal web based, but it's database backed.
And any part of what we think is really cool about it is that it's it helps answer a lot of questions that you run into on the inside, which are whose API is this? Like, what team do I go to write? Who the point of contact? It seems easy, but that wasn't in there.
Or does every team have an open API spec? Right.
Do they do? Do they have that consistency of something that we can use as the input? So we've started to help teams do that.
That's part of what's in there.
Then you start looking at how are you going to get operational excellence? This is another key area for us.
So much more of the business depends on these.
It becomes all millions of customers now use the Forward Pass out.
If you buy a Ford car, you're going to use the Ford Pass mobile app on your iOS or Android device.
Yeah.
Right.
And you want that thing to be reliable and under the covers, it's using dozens of dozens of API calls.
Any mobile app does.
But we need to make sure that those are up.
And so we put a lot of time and energy into as every company I was like, oh, wow.
This is really important.
We're going to make sure this thing, we have these operational behind the scenes pieces, making sure that those non functional requirements are met in the API catalog.
You can then tie into if you were troubleshooting, the teams want to go look at it.
You can see those metrics.
You can tie it into the back end systems to see the charts and the performance metrics.
So it isn't just here's a list of all the APIs, so someone may start there.
And that's fine.
To get into the catalog, that's all you need.
I just need to be.
But as you start to grow in there, we start to enable teams to do more of themselves and sort of do this loosely coupled API catalog becomes a cool, extensible, loosely tag thing to go get other pieces of data elsewhere.
and at a high level, is this stuff like sort of SLA, so type definition or.
Yeah.
Exactly.
Okay.
And then I just tying back to I guess you've got to have some kind of environmental constructs to kind of tie back to various instances and things that get rolled up.
Yeah.
Again, what API gateways is tied to.
And also things like as product owners start to evolve, their as API product ownership is different than other types of product ownership.
Okay.
Oh, yeah.
Right.
And so we want to be very API product driven, platform driven as a company, using these tools and these platforms as a way to kind of enable an upscale all of us by default, to make doing the right thing the easy thing.
Cool.
Right.
And so baking in API metrics.
And they're thinking about just not API traffic metrics.
But what does that tie back to some business value.
So again, growing that along the way.
On.
So API catalog was one, and I start touching another big work thing for us, which was metrics starting to both meta metrics around.
How many APIs do they have? What kind of APIs do we have again, across.
We start to grow the catalog so that we can see it both within a team and across teams, across organizations, all those different taxonomies and some structures.
So that was super helpful, because then we get okay.
Well, here's where again, it's the 80 20 rule.
Where should we invest in more or less what's working? Well, error rates, the sorts of things.
And then the third big Workman was that SRE DevOps operational piece of the puzzle.
And then the four big workstream was that evangelism and and success for all the teams, that for a lot of the growth has been going out to other teams and helping them get better.
Got it.
So you mentioned that you had kind of all the executive buyin and support for all this, which is another hallmark of what we see is that's requisite for success.
Yeah.
All right.
The Band of Rebels can only get so far, right.
But I'm curious.
Presumably at starting at six people with a few work streams, presumably borrowing people from elsewhere, whatever out of the gate you're trying to build up, like, how do I prove the value of this and get bigger investment? So tying it back to kind of like business outcomes when you're looking at okay, we'll have a catalog of APIs and have a better baseline of what our operational status is.
Okay.
Right.
How did that kind of net you further investment to get to know what you're talking about? 100 people.
Low hanging fruit.
So you show success, right.
Like success builds on success.
So you need to be able to say, okay, this is what we did with a scrape on the team.
Here.
Look, we got our V one MVP catalog, right.
Ok.
And then taking these up.
And then putting one of the folks on the team was focused on the metrics piece.
Right.
And we could show value there, because when you take it up to the executive team, they understand numbers.
They understand the histogram of what's happening over time.
Right.
So being able to iteratively as you're not going to come out with the right numbers or the most meaningful numbers out of the box like iteratively.
But take that up the chain.
So go up to the quarterly executive meeting to bring these in some of the the data that the small scrappy team was collecting, then got distributed around and got more attention.
And that okay.
Well, that's good.
Then at least the question, like, what about this? What about that? I don't understand what this means.
And then using that to make that and get momentum.
All right.
Have you been incorporating tooling into these conversations? Like even from the six member team all the way to the 100 member team? Have you had to bring tooling and for observability or rebuilding your own metric based system? No, I don't think so.
We should build all ourselves.
Right.
We don't open it all ourselves.
No, that'd be terrible.
Ask me how I know.
Of course.
Bad idea.
But we have done.
What we try to do is take off the shelf tools and then integrate them ourselves for where it makes sense for us.
for sure.
Right.
Api gateways were going to build a gateway.
So of course, we big API gateway tools like the Splunk and the data dogs and those sorts of things in the background for sure.
Doing that, we built some of our own observability layer in between.
Right.
So.
Well, to allow our application developers and our API developers to connect up to this lower level infrastructure in a way that's meaningful for tracking our transactions.
Right.
Those sorts of that sort of glue.
And again, gluing the API catalog to those back end systems.
So trying to be smart and learning.
Right.
So some things we described and we're like, oh, we're going to have to change that.
But try and be relatively agile about trying things out, see what works, and then building out this more sophisticated tool set.
Yeah.
A bunch of postmen we use.
Right.
So again, you sort of look each stage, whether it's design, development, debugging, operational monitoring, publishing.
So we then build tools around our API publishing pipeline that would allow disparate teams to publish, to, say, an internal API gateway, which is a different gateway structure than the external, cloud based API gateway.
But over time, we got to the point where here's the things you need to input.
So you and I talked about this before, like, Linting is something super important.
How do you we built our API style guide, but if that's just a static thing that's sitting over on the side, it's much more easily sort of baked in.
You can Bake in success if you take the tools that you have and again, make them easy for the developers.
So developers, like, easy, they like to build on the shoulders of others.
They don't always want to reinvent the wheel.
So if you can show them why it's in their own best interest to take these tools that you're giving them, it's like, oh, look, I get diagnostics out of the box, or I avoided this security flaw, right? I didn't really do anything else because these other guys that already built this for us, and that's awesome.
Yeah.
Well, what we keep seeing with the Linting, and notably, we have the Spectral Open source project that is certainly pretty popular for this.
And actually, I'll even pick on our node Larent a little bit in his talk at API specs.
It's like when you've taking all that basic stuff out of the way, you can have a conversation, right.
Like you're not bogged down in does this convention match and that security kind of stuff falls into the same bucket.
Yeah.
I know.
Like we had I'm forgetting her first name money from 42 crunch on.
And they have very much the same approach of, like, let's catch everything on the left and save the pain on the right.
No.
So I love that story.
And a lot of it is that shift left idea, right.
Yeah.
How do you how do you catch those things early and with the least amount of friction.
Right.
Yeah, totally.
And you don't have to make it, like all.
No, it can be just like a Linter does.
Yeah.
You can warn people or give them a site.
It doesn't have to be, like, all stops here.
I mean, security ones.
Okay.
That's a different story.
But again, some of the other stuff can be fed in.
Yeah.
So shifting gears a little bit.
The obvious unique thing about talking to you, work and afford here is like we always talk on the podcast about how do you set up your program? What are the things that work that kind of stuff? I think you got a unique factor in that.
You know, there's big hunks of rolling steel out on the road by the millions that not only interact with some of these APIs, but host some of them from my understanding.
Yeah.
Yeah.
So when you thought about how to kind of do things pervasively or consistent, how is that different in the car world versus kind of building your back end systems or B to B integration or whatever.
Cars are awesome, but they're definitely different when it comes to how you going to turn these things into these digital phones.
Or.
All wheel.
Right.
How are they going to make this iphone on wheels? And I think because then it's basically this mega IoT device.
Right.
Yeah.
Right.
The car is the composite super composite IoT device.
It's divorce.
What's in your phone.
Right.
The phone plus plus.
Right.
These days, they're minimum of 50 of these ECUs is electronic control units.
There all have chips in them.
Which is why we have this chip problem right now because everything's at a computer in it.
Right.
Everything is effectively within the vehicle.
Here's the can bus and all these lower level communication occurring across these devices, which have to happen in real time.
Otherwise it breaks for your age don't work.
And so there's both the internal so effectually lower level API that existed in the vehicle for years, for decades at this point.
But they've been very isolated.
Right.
The little silver boxes that I only talk to each other at a very low level.
Okay.
So both within Ford and across the industry, there's AUTOSAR, which is a standard around trying to abstract out what goes on across components.
So that across suppliers and tier one and tier two and tier three suppliers that we all work with, that work together.
How do we start to rationalize more of how these communicate? Because we know all see that this is industry wide need.
Bye bye.
It's not just API.
It's also the data elements.
That's what is in there.
Right.
When you say fuel level, what do you mean by few level, like when you say Rpm.
What do you mean by that? All sorts of other details.
But these levels of APIs that you're referring to, the low levels, like your can Buster, it'd be OBD.
So that's in the vehicle.
Okay.
Yeah.
These are more programmatic interfaces, like not Web APIs that we're talking about at that layer, right? Yeah.
These are not restful Web APIs, right.
But the goal is to to make them more push those same principles that we've adopted in the Web and sort of make those more common, the abstractions.
Yup.
And you'll never be the same because it's a different universe.
It's real time.
And then so that's the vehicle part.
We talk more about that, but also quite safety critical.
Okay.
Yeah.
So we, as a company, are very attuned to safety.
This is safety and Privacy, or two of our guiding principles.
And every time you talk about eight conversations, safety and then ultimately, Privacy are part of this conversation.
Then there's that next layer of vehicle to the cloud.
Right.
So the this connectivity layer of how and sometimes people talk about this massive amount of data that's available from the vehicle.
You can get all this stuff and with any IoT scenario.
And again, here, I multiply by 100 X.
One of your challenges is like that's too much data.
I can't push that much data up to the cloud unless you want to build a customer $1,000 a month further further connectivity bill.
That's not going to fly.
Right.
Yeah.
So you have to then think about again, like in any edge computing or IoT environment, where do you apply the smart Where's the compute.
we.
Right.
So we're building more and more compute into the vehicle itself, increasing both the built in compute the bandwidth to grow it up for time.
Because again, these vehicles, you don't want to bring it every six to twelve months to put a new CPU in there.
Are you not going to do that? So you kind of have to plan for a longer term and over the air updates, which we can talk about, right.
In terms of being super critical.
But then there's connected.
Right.
So what do you expose both in terms of API's and and in general, part of we found on that front is in just over about two years ago, we had earlier invested in and ultimately acquired a company called Autonomic AI in the Bay Area, and they were focused on their core to what we do on the vehicle API side, taking all that low level binary Hex data that's coming off of the Can bus on 100 different ECUs rationalizing.
That pushing that back up to the cloud and then making pretty JSON Restful API out of it above.
That, right.
For both us internally and for third parties giving you that modern Restful API above it where you've done a lot of the dirty work.
You've taken the diagnostic trouble codes and zero blah, blah blah.
And turn that to something meaningful.
Right.
That's a big chunk of, for example, Autonomic AI is done within the Ford umbrella.
We also refer to it as the Transportation Mobility Cloud, but that's what that does.
Right.
And across all the vehicles and stuff, I don't think in 2021 you can buy a Ford.
I believe we've done it across the entire vehicle line.
They all come with an embedded modem, right.
A four G modem.
So they come off the assembly line.
You as a retail customer, has the ability to while I do want to use this, but there are a ton of advantages to using it, whether it's Ford Pass and all these other things.
And Ford pass for listeners.
And I know, Anna, you know, because they're also Ford family here.
But like, my use cases that are super common are like, I can tell whether or not I need air in the tires and be alerted of it without even being in the vehicle notified of when all changes are coming up.
So, like, totally meaningful here that all this sensor level data being fed up to cloud so that it can be integrated on my phone has a huge consumer impact.
Yeah.
And you did mention one of the other very often used features, and it varies by season.
It's kind of interesting to learn the seasonality to remote start.
Oh, yeah.
I'm in Detroit.
Right.
So you can sit there in your mobile season, right from the season perspective.
I live in Texas, so I don't talk about it, and I probably use it all the time.
Big one for us.
Certainly.
Again in the winter time, it's so much nicer to be able to go out to a nice, warm vehicle.
Right.
And all you have to do is push a button in your app and the car starts warming up for you.
Yeah.
Right.
For what? It's worth our seasonality in Texas as we use it in the middle of the summer.
Or cool or cooling down.
Right.
So I've been using it recently.
Exactly.
Or the other end.
Yeah.
Again, we look at the numbers as the dips in the edge season it's really North America.
Okay.
Makes sense.
But and then I think just to to expand on that.
Right.
So the same API, for example, that can help you locate where your vehicle is, start your vehicle, see the fuel level or the air pressure level.
Right.
So those are all there for going to the for past at.
But like with any good API, it's there.
Right.
So therefore, what other things can be done? We use of other things internally, but then also with partners.
So from an ecosystem, a good API program.
And we certainly see it this way as enabling new services.
So just over a year ago, one of the things that we did on the retail side was partnered with Amazon.
So when you order packages on Amazon, you can have those packages delivered to your vehicle.
Oh, I should use them.
Right.
So instead of saying here's my home address, you can say, well, you have to, of course, go through a few authorization steps to make this all happen.
But once you've done that, the Amazon driver can come and deliver it to the trunk of your car so you can be at work or wherever somewhere on the road.
And it's all done in a very secure manner.
And it can pop the trunk and turn off the alarm.
And then it turns that alarm back on when they leave.
So it's a seamless way to use your car as another delivery address.
Right.
But it's using the same with Super Cool.
And it's the same API.
Yeah.
I'm actually sitting here flipping around looking at it when you're talking about, like, pop up in the bed of my truck.
applications or grocery delivery.
I already got the cover on there.
Right.
I have to use that.
Right.
Every application.
Well, exactly.
That's so cool.
Well, and there are a bunch of startups, right.
And bigger companies thinking about all the different things you can do now that the cars or vehicles are connected.
Okay.
Right.
Yup.
So there's a fuel delivery you may have seen there's a number of fuel delivery startups and big oil looking at this as well.
Some States allow some don't, but again, bringing the fuel to your car.
So just like you would have your laundry delivery or any of those things if the car is digitally addressable in a secure way and you opt into that new opportunities.
A car is such a fundamental part of your life, right.
Yeah.
So it makes sense that it becomes so ingrained in your day to day activities that it becomes a new postal black pen or a new place to engage with some of the services you use every single day.
Yeah.
Bye.
That's so fascinating.
Yup, the light bulb goes out.
Yeah.
The light bulb has to go off.
Right.
Because it's like, oh, yeah.
That's right.
Now.
I never really thought about it.
Yeah.
I think that's kind of where the early days where we are, which kind of makes us so excited, like, so early.
So I guess bringing this back to kind of these big overarching, like how Ford build with better operational excellence and APIs and presumably higher quality and better innovation.
Looking at how these kind of Web APIs are getting designed for cars versus the internal services.
Are there commonalities between those things, or are they so different that you have, like, completely bespoke set of rules for each so.
Good question.
They historically so different.
Right.
I think what we're trying to do over time is okay.
Bring those closer together.
That will never be the same.
Right.
But, for example, by abstracting the differences in different headlights across cars.
And so you start to build these abstraction layers in the vehicle and then think about the APIs and data around them.
And then over time, start to then they open up those opportunities that you didn't have before.
Right.
So to make it a bit closer to what you see in the cloud.
And again, you're always going to have to have that layer to translate the to at some point.
Yeah.
But the closer that they look, the better.
Right.
Having tinkered with Can bus stuff before, I would be extremely grateful to not have to touch it.
Right.
Because the O two, which is that standard for plugging into the vehicle.
Yes.
yeah.
Yeah.
Well, in CANbus is like a globalized version of the on board diagnostics.
man.
so.
I mean, what you're kind of describing is this sort of common models that are applicable across all things.
So, like you mentioned headlights, like trying to find there's one way that we describe the headlights.
We have one representation for that.
It should be true whether you're looking at some backend system or you're interacting with these kind of vehicle centric APIs.
So.
Yup.
Right.
Cool.
Yeah.
Yeah.
Another recurring theme of find your common models and be consistent across all your channels.
No.
So it's really cool to see that can even apply to, like, I like your description like a giant IoT device.
Very cool.
Yeah.
It's here.
And again, I come back to principles around security and Privacy, right.
Because I think yeah, there are natural concerns around those.
And so that's why for no OEM, some auto manufacturer, you're going to see this grand open API program right now because you have to be so careful about those things.
Yeah.
Right.
And as owners, you're afraid of that, right.
Because it's connected.
It's like whether whether again, the quality of the software both built internally, but also again, hackers and anything else that might go wrong.
Right.
You just have to be really focused on that.
And again, from a Privacy perspective.
Again, that's a very private piece of information you have around where you go and any of that.
Right.
So we're very careful about respecting a fundamental principle.
Yeah.
We dabbled in obviously much smaller sphere of that when I was at uship many years back on starting to add location services to the app when we had truckers delivering things.
And it's like, I just have this constant cultural reminder that we have a full accounting of everywhere this person's been.
No.
So this is life changing data in the wrong hands, so I can't even fathom or that's like, the skill you guys are working on globally.
Yeah.
Yeah.
It makes sense that OEMs aren't really taking on that challenge, and that partnerships are so important to your business model right now because you need a good partnership that knows how to handle those security concerns that you don't have to worry about that data falling into the wrong hands.
It's a priority.
But that means that your APIs for those partnerships have to be easy, right? Because how else do you open up opportunities unless you are creating APIs that your partners can use.
Yeah.
So it goes all the way from the car all the way up right into the business.
Bye.
Yeah.
Right.
And then easy also means the documentation.
Yup.
So going back to your earlier question around who's on the team, right.
Because you need people who know how to do that.
work.
Well.
Right.
Absolutely.
Yeah.
It doesn't just happen by magic.
If only you could wave your hand and make it out of my magic.
All of our customers with the same thing.
It's not that easy.
That's what Stoplight is for.
Yeah.
Yeah.
Exactly.
So, you know, from us chatting before, it sounds like you're kind of shifting gears into more of this Ford Pro kind of the fleet fleet management aspect of things.
I understand.
Where do you see that kind of space moving toward around kind of the usage of the API, as you mentioned before, just having them in the vehicles is a hell of a starting point.
Yeah.
And I think it's a good topic.
And I realized one thing we didn't touch on just interject one other piece of my time for just coming out of which is the self driving car, right overall, farther down the road.
Oh, yeah, of course.
Yeah.
But we're working on it now, right.
And so self driving cars are APIs all the way down.
Whether we've invested heavily in a company in the Pittsburgh area called Argo AI, and Argo is providing all of that deep AI around how to actually do the driving itself.
And we're running pilot tests in Miami and DC in Detroit and other cities that we gradually start to run these pilot programs for self driving cars.
But again, you can't do it's all the same things, but at a whole nother level, right.
Because it's still APIs under the covers.
And even more so for APIs.
Talk to Argo APIs in this case, in the vehicle, and you have to be more attuned to how well does all that compute infrastructure work in a disconnected scenario because you can't always rely on connectivity.
But the car is there running to sell.
So it's another place in which APIs are super important API tooling super important governance, right.
Doing it well being secure quality APIs, multi party APIs.
So again, sort of it's an ecosystem to actually make that work.
So I think in the future, when you hear see more self driving cars out there, just keep in the back of your mind that self driving car is driven by APIs.
Well, I think maybe that's our teaser there.
When I ask about Pro, you start talking about autonomous.
the other inflection point right before there.
So some of the big inflection points right now are connectivity.
Right.
So all the vehicles are connected.
Electrification.
Right.
Electrification is again.
Okay.
Ford announced just last week an $11 billion investment in these new US based EV battery and vehicle manufacturing plants.
So that's potentially one of our biggest investments ever.
Right.
So that's around EVs.
But EVs are all connected.
You don't have a not connected EV, right.
Yeah.
These things build on each other.
And then farther down the road, you're going to have the AV.
So this is part of that longer term when you look over the course of time, when you think about cars over the next five to ten years, this is where it's going.
Right.
So it's connected vehicles, electric vehicles, self driving vehicles.
Right.
And then you have these mobility services built on top, coming back to the pro question as route.
If you're a commercial being like, we all individually supect lot folks listing on the podcast here, you have a car, whether it's forward car or another one.
You think about your experience as a single owner.
But there are fleet owners that have anything from two to 2000 vehicles or more.
And if you extrapolate what it means to be connected electric API driven platforms, there's a whole huge opportunity to build some really valuable services.
On top of that.
Right back in the spring, Ford announced a whole new division with its own CEO focus solely because we have such a lion share and such a core competency around the commercial vehicle space as effectively the leader in that space with transit vans, pickup trucks, chassis up, custom vehicle police vehicles.
We have the lion share, the police vehicle market.
So the commercial space is huge.
And it's a core competency of ours.
So doubling down that strength now that they are all going to be connected, let's start to give our customers, our commercial customers a whole new set of options that they didn't have previously.
So that's what this new division that we're just spinning up now.
And that's where I just joined that group to help lead some of the engineering efforts over there.
Well, I can't help but observe along that same timeline that's roughly as this new Ford Lightning full electric kind of EV truck is coming to market.
yeah, exactly.
The two big ones that are coming up in the next twelve months are later this year, early next year is the E Transit.
So that transit van.
And again, as someone managing a fleet, you become much more conscious around cost up time every time that thing is in a shop that's costing you money.
So thinking about how can you use these digital services to maximize your uptime, reduce your cost.
Best utilize that fleet once they're electric.
How do I optimize that? And that's given you another chance to both it's on the one hand, maybe a complication.
But the other hand, opportunity.
Right.
So again, building this entire digital layer for that business is key to what Ford Pro will be about.
Yeah.
Very cool.
Again.
I got some.
sorry.
Can you hear me and how to enable the different locations to have infrastructure.
Yeah.
So you're going to need electric vehicle places to charge.
You're going to need dealerships that are be able to service those individual electric and autonomous vehicles.
Yup.
They're not prepared yet for that kind of work.
Right.
So you need to be able to lay the foundations to enable those places to have your inventory.
Right.
Yeah.
And that's a great point because we just acquired a really cool company, a bare company called Electrify AI the summer in July, and their focus was on helping Sleet owners manage this depots and charging.
And they have some really cool tools around us, so that will be integrated into our it's our overall offering.
That's awesome.
And again, I think it's a huge opportunity.
And again, always API is under the cover.
you dropped off.
You're on mute.
Alright.
So I guess the read between the lines tip here is if you're in a auto oriented startup and you want to be acquired by Ford, make sure it ends in dot.
It doesn't hurt.
Ai, right.
I think all the other dot com are taken anyway.
Yeah, that's probably true.
So I as well will probably fly.
Yeah.
All right.
Well, I guess it feels like a pretty good point to wrap.
We I think got through a lot of the high level subjects we're looking for.
I guess I always want to kind of bring it back to knowing we have listeners who hear all this big, complex stuff and go, we have massive resources and all these things to throw at it.
But maybe I'm a team of one or a small team or a small company.
well, similarly, we try to start small, right.
So I think even though we're huge, even just like that platform name team with another example of what we try and to be small and focused and go from there.
help.
Right.
I think it's not necessarily a disadvantage.
Right.
And then thinking about how am I baking and API thinking platform thinking from the beginning.
So even in my small couple man shop, how do I think about API's and platform being core to what I'm doing and having that sort of set of tools to help you do it right? Because you don't have to reinvent the wheel.
So there's a bunch of both commercial and open source tools for developers now that didn't exist 2510 years ago.
Just like go to GitHub.
I think the part within your thinking is like, how can I leverage this to accelerate what I'm trying to do, right? Because there's more tooling all the time.
And it helps with the speed and complexity and the gotchas right.
And so those are super accelerators tools can be accelerators.
Yeah.
Well said John, I really appreciate you taking the time.
This has definitely been a different one, right.
Talking car stuff so much.
But being a die in a little car guy and my dad worked at a dealership for 20 years fixing Fords that I grew up with.
It so definitely cool to get the geek out on that.
But I think also just to wrap our heads around the scale you guys are dealing with and really the world changing effects of some of these things, it feels like a really interesting time to to talk about it.
yeah.
Thanks for having me on.
It's been fun to chat about it and kick out, and we can always do it again.
She'll be more talking about another time.
Also, we're hiring.
So if any of this sounds interesting, there's four jobs online.
You can come and see.
We need all the same skill sets.
Right.
All these sort of software related folks.
Certainly, we're definitely hiring.
And it's an exciting time to be in the space.
No question.
Hey.
And I should also thank Anna for stepping up to help co host again.
And I guess with that, we'll say goodbye, listeners.
So make sure I go check out four jobs online.
It sounds like our call to action here at the end.
Yeah.
Harry.
So thanks everyone for listening.
Cheers.
Thanks for having.
Alright.
Cool.
So that will be our rep point.