Episode 19

What you’ll learn

Definition of an API
How APIs can improve the public service
Who is using APIs in the Government of Canada (GC)
How (and when) to pitch APIs to your manager or team

In this episode, we’re experimenting. I’ve drawn from a fun, in-depth interview with folks from the API Store team and Transport Canada and distilled what I think are the most interesting, relevant, applicable parts. I laid the parts out Q & A style and edited the quotes to improve flow and readability. The podcast is available via Soundcloud at the end of the episode.

APIs are one of those things I didn’t realize I was interacting with regularly. When the GC leverages APIs, we’re channeling several GC Digital Standards: working in the open by default, being good data stewards, addressing security and privacy risks, and collaborating widely. You don’t need to be working in an IT shop to use or recommend APIs for your work.

Interviewees

Mohamed Frendi – Director
Laura Collier – Senior Manager
Ainsley Bernard – Programmer Analyst (Transport Canada)
Don Vo – Technical Advisor
Chrystal Olorunsogo – Communications Officer

What is an API?

An application programming interface (API) is a way to trade data between IT systems without compromising the security of those systems. APIs can be published by one provider and used by others.

Ainsley: Personally, I like the illustration of the restaurant. You're going to a restaurant and you want to order something. The waiter is your API. He goes to the backdoor to the chef, and the chef brings back the result, which is your meal.

What are real-world API examples?

Ainsley: A lot of departments have APIs, but it's also [about] making them publicly available. So for Transport Canada, we developed an Alexa skill. A skill is basically just an enhancement of Alexa’s ability, her knowledge. We specifically used an API to enhance her skill.

The Treasury Board Secretariat (TBS), in the beginning, was actually looking for publicly available data. One [source] was the vehicle recalls [database], which is hosted by Transport Canada .

So we developed a skill using this API. Now you can look up vehicle recalls using your Alexa at home. [The public] can actually just tell Alexa, “Search for vehicle recalls.” She'll interpret it and say, “Hey, there's this skill. Would you like to download it?”

Mohamed: As a user, when you go to Expedia, you just input certain criteria: I want to fly inbound or outbound this day, and come back on that day; I want to spend three nights in the hotel. Expedia will then trigger calls to the different systems that are remote somewhere in the world.

Man waiting in the airport looking at a plane taking off. — Photo by JESHOOTS.COM / Unsplash

When these calls happen, the system […] is just a contract. If you give me this input, I will retrieve [the data] and send you back the output. So they’re retrieved by Expedia and they’re sorted based on the criteria. Expedia itself doesn’t store data. They just get it live, and sort it, and give it to the user.

What is the API Store?

Laura: The API Store is somewhere to find and publish APIs, share APIs, and really get the message out there that this exists. Let's see how we can collaborate together.

The API Store is the eHarmony of APIs.

Say I want to consume a service. You have certain criteria, the exact same way that eHarmony would work. Once you click on that service, you want to consume the data. The API Store connects you to the owner of that service. If the owner approves your use, suddenly there's this connection that happens between your API, the publisher, and the one who's using that API through the store.

Are APIs safe, from a data security perspective?

Laura: APIs facilitate digital information exchanges between systems and organizations in an easy and secure manner. Only the information that is chosen to be exposed by the API provider is accessible through the API—securing the integrity of their own systems.

What’s the benefit to Canadians?

In conducting this interview, I realized APIs are a key ingredient in the GC’s “Tell Us Once” approach. Canadians don’t want to be providing the same information to 10 different government websites. APIs allow systems and data to feed into one another and reduce work duplication. We needn’t start from nothing: instead, we can build on the work of our colleagues.

What could it look like if the Government of Canada harnessed the power of APIs?

Mohamed: Cost savings, that's the first thing. Everyone is thinking, I need to build this little component that will, for example, parse my address to write it in a good, elegant way. If I knew you had this API, I wouldn't build it. I'm just going to use yours.

As one department, you already can save. Expand this to the government level, it's going to be multiple millions of dollars of saving, if not more—and time shrinking in delivery. Because now instead of building, you're assembling as much as possible.

A plant sprout emerging from a jar of coins. — Photo by Micheile Henderson / Unsplash

From the user perspective, we are offering services that are available to deliver data or process data in a certain way. We let Canadians and Canadian companies build the best services, so we’re kind of allowing people to compete.

What obstacles have you had to overcome?

Ainsley: Is it really solving a problem? That was the hard part in terms of knowing what’s the actual benefit to Canadians.

When we get deeper and deeper into it, we see that vehicle recalls are provided by the manufacturers to citizens, but there is a delay. If you visit the [Transport Canada] website, or if you use the voice assistant, the voice assistant [we trained] is actually a quicker way to retrieve a recall. Getting this information quicker is a benefit to citizens.

Laura: We did get a little bit of pushback on the fact that people had to register for the service when they first came in. But the registration allows that control. We understand who our users are. It's not just an anonymous person out there. Some people are saying that it is public information, and they just want it out there. But information is a little bit sensitive for certain specific groups of people. We want to make sure it's being used in the right way. The controls are in place so that we can understand who our users are, who is using this and who is pushing that information out there. If there are issues, we know where to go. At the same time, we have now opened up communications with specific users [around] our data, where we can work together to make that data better in the future. Or we can change the way that data is packaged or put together so that it can help improve services as well.

Don: I'm not necessarily an IT person. I don't know how to call APIs or write an app. But I'm sure if you expose the data in a way that other people can use it, people will use it and do something useful with it.

I think it's important for non-IT people to learn about APIs, just to know when to demand them. I mean, if you're sitting in a meeting and talking about a new version of your enterprise system coming out, it doesn't take much to say, “Oh, do you have APIs?” - Don

Laura: From a non-IT perspective [the question] is, What information or valuable data assets do I own or have that I'm sharing with others? Is there a better way to share this, and is that better way through an API?

I think if they should question themselves sending Excel spreadsheets that are just getting to one person, but they’re trying to get this information out to multiple people or multiple departments. That's where they can say, “Maybe this API thing can help me get that message out faster and quicker. It can be an easier way that can free me up to do other things.”

Mohamed: There is a directive on APIs issued by TBS, which now forces or empowers the departments to build microservices and APIs into their software.

Laura: It's trying to have the programmers and the service delivery agents understand that there's potential here if you understand this API thing—that you can really change your business processes, you can really extend reach for your services. Like I said before, you still keep control of that information in the data. You're just doing things in a smarter, more digital way.

We would be happy to schedule an information session about the benefits of APIs and the API Store with your CIO and management teams. They should contact us at the API Store or through the Support page on the site. We’ll be happy to work with them to get them on board at the Store!

How can Canadians get more involved?

Laura: By recommending the type of data or information (in real time) they would like to get from the GC (through the Support page). Those using the APIs that are offered can also make suggestions on how they can be improved.

In closing

Not to give away my generational identity, but those who remember Field of Dreams starring Kevin Costner will recall this famous line: “If you build it, they will come.”

Given our discussion, I think this might be more apt: “If you share it, they will build.”

Lego piece. — Photo by Hello I'm Nik 🍌 / Unsplash

Learning more about APIs

Podcast

Rebecca: I'm Rebecca Nava and welcome back to the Busrides podcast. I'm here with the API Store team, as well as Ainsley Bernard from Transport Canada. And so around the table today we have a few folks. From the API Store team we have director Mohammad Frendi, welcome. Laura Collier. She's a senior manager. We have Don Vo, technical advisor.

Don: Good day.

Rebecca: And Chrystal Olorunsogo. And again, from Transport Canada, we have programmer analyst Ainsley Bernard.

Rebecca

All right. Welcome, everyone. So to kick it off, what is an API?

Mohamed: What is an API? Good question. There are different ways to explain what an API is. But if we were to look at it from a more public audience perspective, look at it as pieces of Lego which you can use and reuse to assemble more complex pieces to get nice, whatever devices, please whatever. In the rest of the world in more in IT world, an API is just a component, a software component that has an input and output and people can inDonke independently from any other infrastructure.

Group: That sounds pretty good.

Don: Like in terms of like, nerd speak, you know, it's a contract. I promise you, like, I have this API. If you call the API this way, you know, you ask for certain things, I will give you what you ask for the structured data. So you can do something with it.

Laura: And it's all in real time. So that's the good part of an API. So it's not doing just random calls. It's doing it's doing random call at a specific time for a specific information that's at that timeframe. So you are really getting that real time information as you need it.

Rebecca: Well, that's fascinating. And I remember a great example that Mohammad gave me was Expedia. So Expedia, it's like an aggregator is pulling flight data from many different sources. And it's using an API.

Mohamed: Yeah. So the reality is that Expedia is not built as a big system connected tightly to all the carrier systems or the hotel systems. As a user, when you go to Expedia, you just put certain criteria I want to fly inbound or outbound this day and come back on that day, I want to spend three nights in the hotel, Expedia, can you tell me what or or and what is this is my starting point and this is destination. So Expedia, give me the flights and at that time Expedia will trigger calls to the different systems that are remote somewhere in the world could be in France could be in China could be wherever they are, those systems there are expose all the APIs. So when these calls happen, the system as Don was explaining, it is just a contract. If you give me this input, I will retrieve and send you back the output. So those are retrieved by Expedia and they’re sorted based on the criteria, so Expedia itself, they don't store data, they just get it live and sort it and give it to the user. After you finish your, your sorting, and let's say you pick a flight, the moment you click again to book that flight, there's yet another API call that goes to the system of the carrier you have chosen and processes your flight reservation.

Rebecca: And as Laura mentioned, this is happening in real time.

Mohamed: Oh, yeah.

Rebecca: I mean, that's pretty incredible.

Ainsley: Personally, I like the illustration of the restaurant, of, you're going to a restaurant, you want to order something, and the waiter is your API. So he then goes to the backdoor to the chef, and the chef brings back the result, which is your meal. Yeah. So essentially, that's what it boils down to.

Don: So actually, I think you'd be surprised to see that there are a lot of APIs already being used the government. It's just that, the problem is they're not discoverable or that are just used for themselves internally. Because the idea like you know, in terms of developing software, we've always had this paradigm that you have a presentation layer, whether it's an app, a web app, or something and then you have the backend system that like has the data has business logic and things like that. So the paradigm of separating your services from your presentation has always been there. And that usually results in APIs, and like service calls and things like that. It's just the will to share and the ability to share this, this information, the services that people are very eager to do now.

Ainsley: The big thing is that a lot of departments have APIs, but it's also making it publicly available. Right. So that's the like a lot of what Don was saying that whole separation. That's a practice as a developer that we always have so it’s making that specific API available to the public.

Rebecca: Right? So now it's our best kept secret. Okay, so you kind of gotta know somebody who knows somebody who's got an API. Okay, so it's like falling off the back of a truck, you know, like, you know,

Laura: But that's how the store is now coming into play. So the API Store that we have put in place is to help that discoverability it's somewhere where we could all go together, find, publish APIs, share APIs, and really get that message out there that this exists. And let's see how we can collaborate together.

Mohamed: It fulfills several aspects discoverability security, because you ensure that through that API Store, it's not everyone who's going to call your API you cannot bringing some security layer between the caller and the provider. That API Store plays the role of the eHarmony for APIs. Really, that's that's the that's the case that that there is a consumer there is a producer and the API Store is the eHarmony matching site/ I would say, I want to consume those services. Let me check if there is you have certain criteria the exact same way as eHarmony would work. Sorry, I'm not a consumer, I just know. Just to use an example on this. I'm currently working with the food industry, particularly with Loblaws.

Rebecca: And the dating industry apparently.

Mohamed: Not yet. So I'm currently in the process of securing some interaction with Loblaws. The purpose is to discuss with them as well as with Health Canada and CFIA (Canadian Food Inspection Agency) and potentially offer some services. So Canadian citizen can through their mobile app, for example, get notifications of, maybe food recalls, or drug recalls or toy recalls if there is any poisoning or an any risk on their health. So instead of you listening all the time to the news, maybe they're going to say there is a food recall or such or such. Or maybe your tomato is infected by salmonella. Now suddenly, because you have the mobile app of Loblaws, or President’s Choice or whatever, yeah, the moment that thing happens, you get a push notification and you open your phone or your phone. Oh, there is a problem.

Rebecca: Okay, your food is ready. Use the waiter -

Mohamed: No - your food is dangerous!

Rebecca: So okay, so if I understand you right, then the API Store is a place where Canadians, it can be even a litmus test of what Canadians want, what kind of things that they want access to. So I'm interested in what kind of interaction are you seeing, are you seeing are you seeing some uptake in terms of the store and people seeking different types of information?

Don: Yeah, yeah, we definitely received a lot of feedback. You know, the kind of lists of wish lists of APIs that people would like, you know, people in industry just like public citizens and things like that. And you know, at the end of the day, we just we we let the departments know that there's interest. And then in the end, you kind of stuck with the IT project lifecycle, like if there is enough demand to kind of justify the costs and the initiative then, you can move forward on it. I mean, you know, that's just unfortunate friction that you have like to move things along. But we encourage people to always reach out and to show that there is interest because we, you know, we can only gauge interest from what we what we hear from people.

Mohamed: Yeah. And the idea behind at some point is the government moves from developing application to offer and services and let the Canadian, Canadians or the Canadian companies build those applications to reuse that example of the OC Transpo. OC Transpo did not want to themselves build a mobile app because you have to develop it toward these devices that devices Android Apple, which version. So they thought, you know what, why don't I just expose the data and let people build those services? Awesome. We want to shift the vision to become Canadian user-centric. I want as Canadian to sit in my couch, I don't care, am I dealing with municipal or provincial or federal government, all I want is to do to deal with public services.

Rebecca: Yep. And I want to be efficient. I love this, this puts control back in the hands of whoever wants to be. It could be like a guy in his basement, it could be a private company, and here's the thing: it's like you realize Canadians are in some way they can be provider agnostic. They just want the information. So I love this idea, because it takes pressure off us as well to be going contracting out finding the app, taking two years to develop the app, the apps, you know, we got to test it out. And maybe it's not good anymore.

Don: Yeah, because there's there's a lot of transactions that people have with the government that are very difficult, like you hear a lot of, there's a lot of business in interacting with the government on behalf of people or companies, right? So, why is it maybe the system's outdated, maybe it's just a little confusing. But if we have this, this API, this contract where, you know, you're providing a service. Now, the presentation, it's up to the other companies or people who maybe can do a better job of it or just are willing to do, you know, jump through the hoops or the difficulties to provide the service.

Rebecca: I love this.

Laura: And what's really good about this, as well is, we still retain control over that messaging. So it's still our data. We're still controlling what data is out there. It's not getting whitewashed and so one and so forth. This is our data. It's still trustworthy. It's coming from the source of truth. But now we're expanding our reach. So instead of us as government trying to promote, oh, we have this service, or we have this information that you might want now we're letting it go out there and letting the market expand it even more or other third party partners expanded more, or other levels of government. So there's others that can now take that embedded within their own services and get that reach out there as well. But yet, we still can retain the control over our data.

Rebecca: I love this because it's kind of like crowdsourcing solutions and giving it back to the people. That's exactly this. Yeah. This is fantastic.

Rebecca: And before we move on, you know, I like to keep them with light. So I wanna I want to point out this is this is a hilarious team. They came into the room, they're laughing already. So I would like to know kind of what's your faDonrite thing to do as a team?

Mohamed: Asking favorite things to IT people. We probably are the most, how do you say that? Flat people.

Chrystal: They’re speaking for themselves. I pride myself in not being as flat.

Mohamed: There you go.

Don: I mean, yeah, like, is my faDonrite thing the daily stand-up or is my faDonrite thing, the postmortem of the sprint?

Mohamed: Let me just speak to the team. I think that one of the things that the team likes, particularly Do is play games. So several times. I did happen to witness that I enter thinking that the team is working. And what are they working on the screen? They are plugging their console, and they are playing games as a team, this is teambuilding!

Don: To be fair, there's a foosball table on the fourth floor so that’s encouraged by the department.

Rebecca: Yes. Has there been any funny moments that's happened in the course of your time together

Mohamed: As a team? Probably Don. He's a big Joker.

Little jokes, usually usually in the standup meetings every day, we joked when we were running this initiative. Right, right. Well, I was I was I was always pleased to work with this team. Right. So we tried to be as as as one as a flat maybe it was flat-y from the jokes perspective. But we really are as an organization, at least in my team. I try to have a very flat organizational hierarchy. I don't have this you need to talk to your supervisor or talk to the director. No, it's everyone is accessible at the same time. What we look for is feeling good in the team and also being efficient in taking action when needed. We try to be as flexible as possible, although we sometimes have very tight timelines and some some demand and this was a very high profile initiative last year, we worked unbelievably enter under very tight timelines I recall just an anecdote when we announced just internally here to some partners saying we're working to get an API Store that was in June 2018. We're working to get an API Store ready for the government by end of fiscal few hours later, I would say probably a couple hours later, the Government of Canada CIO had already tweeted it, so it was no longer we’re aiming. It's now you better do it. Now the public is aware of it.

Rebecca: Yeah. Yeah. No kidding. No kidding. So sleeping bags in the office.

Don: It’s a special noise, you know when you make it, you don't know if it's a laugh or a cry.

Mohamed: And the beauty with cloud is you don't need to sleep at the office as long as you work from home, 24 hours is okay be at home. Yeah, we did, we did long weeks.

Rebecca: And for those who don't know, like a daily stand up is also sometimes called a scrum. And that's used. It's an agile term. So it's like the whole scrum framework. And, and you're using a lot of the terminology, which is part of the whole process where you have your daily scrum or your stand-up to kind of have visibility on how things are going, to ask for help to say your workload to see what how you can help each other. So it's a very different way of working.

Mohamed: Yeah, and to tell the truth, where we are very proud of what we've delivered, not for wrong reasons. First of all, we've been invited to a summit in Boston last year to present this API Store as a first thing in the world and I've been personally approached the team also have been approached by different governments from around the world Australia, New Zealand, UK, and recently Japan government who want to take advantage of the same solution.

Rebecca: So this is a world first?

Mohamed: The world first done this way, other government world, for example, New Zealand tried to do something similar within one department, and it did not succeed and it was fully outsourced where in our case, we did it for really inside of the government. It's mainly government employees and it is successful and it's working very well. And as I said, it is so well welcome that these countries want, so I know that Australia, we are still working with them to sign MOUs so we can share the code and the practices so they can do it themselves. UK same thing they contacted us, Japan, just recently they did a summit in there and they wanted me to speak to them and we are still in collaboration because they want to do the same thing.

Rebecca: I think this is exemplary because it just showcases Open Government, Beyond 2020 - agile, inclusive, equipped and, kind of, again, giving it back to the people and being on the cutting edge. So I really, I really think it's cool. I would like to turn it over to Ainsley because I think I'm one of those people really learns with examples, so I would like to know, so you're, you hail from Transport Canada and right now you're using APIs. So, can you describe how, how that's going?

Ainsley: Yeah. So for Transport Canada we developed an Alexa skill. And a skill is basically just an enhancement of Alexis’s ability, herknowledge. So we specifically use an API to enhance her skill. So this entire Alexa project actually gets its birth from the API. TBS, in the beginning, was actually looking for publicly available data. And one of them was the vehicle recalls, which is hosted by Transport Canada. And so they deemed that as something that was viable. And so then we developed a skill using this API. So essentially, you can look up vehicle recalls using your Alexa at home.

Rebecca: So you think scale or skill, skill, skill, okay. So upskilling Alexa, yes. Okay, that's cool. So, so you created a bit of like a super-powered Alexa like I'm picturing a lab rat. Yeah. infused with like, powers.

Ainsley: Yeah, essentially. Yeah. Give her abilities.

Rebecca: So did it require, like speaking to the company that manages Alexa in order to do this? Or how did you hack Alexa?

Ainsley: So they provide a software development kit. And so there was no need for hacking. The main issue was providing the training data to Alexa. The API itself actually doesn't provide the raw material. So when we're talking about restaurants, and you're saying to the waiter here, meet me this food, that's good. But if you this, though, like the raw materials like onions, green peppers, and all the protein and all that stuff, that actually those ingredients you need to actually provide to Alexa. Alexa can actually make her own conclusions, essentially. So the API didn't provide that. So we actually internally had to grab all that data and then provide it to her. And there are some other complexities where we actually had to like, essentially link the specific data so we can extract and send text messages to the users.

Rebecca: Wow. So where are things at now?

Ainsley: It's operating now, it's publicly available. So people have been using it and now we're just starting to get a little bit more the project is a six was deemed like a six month pilot. It's been extended now. And so we're getting more marketing out there to expose it essentially.

Mohamed: So if anyone wants to use Alexa so that they the Transport Canada skill, what do they do they have an Alexa pod at home, what do they do?

Ainsley: So they can actually just tell Alexa, search for vehicle recalls. And then she'll try to interpret it and say, hey, there's this skill. Would you like to download it? So, they don’t need to search for you just kind of say it and then she'll try to retrieve the skill for you, and then ask you if you want to download it.

Rebecca: Wow. That is pretty incredible. That's a great story.

And how long did that take?

Ainsley: It took about eight months. Yeah. So it's just really just learning the software development kit, and like learning how to actually use that kit to develop for this skill.

Rebecca: Right. One thing I wonder about because I want this, I want this to be situated within a real context in which people work. And I know that fear is a very powerful emotion. So when this was in progress, or even for the API Store, what, what obstacles that you have to overcome in terms of people's fears?

Ainsley: I think most of the fear was really, because this, our project wasn't really had a definitive why we're building this project so much in terms of like, is it really solving a problem? So like, we were more of a, this is an innovative idea, and let's try to see what Donice assistance can do and what they can provide to Canadian citizens. So I think that was the hard part in terms of like really knowing what is the actual benefit to Canadians? And actually, when we get deeper and deeper into it, we actually kind of see that, like vehicle recalls are provided by the manufacturers to citizens, but there is actually a delay. So this is actually if you visit the website, or if you use the voice assistant, this is actually a quicker way in retrieving a recall. So that's actually actually seeing the actual benefit of that is actually something that like it's very powerful. And knowing that there was actually as an article about someone not getting the recall notice and they had engine troubles and the cost of actually having to replace your engine, just because you didn't take effector not know or whatever the case may be. So getting this information quicker, is a benefit to citizens.

Rebecca: I love that as well. Because typically, you know, you're doing your user research said it has to be separate from providing a service, or it's kind of at the end of a service, would you fill out the survey, and you know, you get 10% uptake? 30% if you're lucky. So in this case, people are just doing what they want to do what they're naturally wanting to do, and you're getting data.

Mohamed: Exactly. Yeah. Very, very good way to see it.

Rebecca: Yeah. So we're seeing, I love it.

Mohamed: Continuous data collection, it's nothing that is private data it’s just that we know that this service is being used at 10,000 times a day or a million times a day. And the more we see, but if we see, for example, that the service is not called at all, then it's an information for us, maybe Canadian don't know about it, maybe they don't like it. Can we do an outreach and see what do they want to see? So it's really you gathering information that allows you to continuously improve the services you offer?

Rebecca: I mean, it sounds like the potential of APIs in the Government of Canada context is massive. Like what could it look like if we were if we Government of Canada were really harnessing the power of APIs?

Mohamed: Lots. Cost savings, that's the first thing. We are sure that within one department I'm not talking about across departments. There are multiple components, APIs, that are being built on separate projects because as we were saying before, they're all siloed. Everyone is thinking, I need to build this little component that will, for example, parse my address to write it in, in a good, elegant way, everyone is going to do that. Had I known that you had this API, I wouldn't build it, I'm just going to use yours. And look at this as one department you already can, can save, expand this to the government level, it's going to be multiple millions of dollars of saving, if not more, and time also shrinking in delivery, because now instead of building, you're assembling as much as possible. But now as we go into the Internet of Things, maybe your fridge is going to tell you that tomato, the tomato you bought last week, can you please take it off because it's poison?

Rebecca: This is half my fridge, really. You know what Mohammad? I'm sold. Okay, so I have, I have taken APIs hook, line and sinker. And I'm listening to this episode and I am an IT person at department X. How do I get more involved in this? How do I pitch this? Who do I pitch it to?

Mohamed: You’ll pitch it for two sides. First of all, obviously, inside your department, there must be a little bit of an interest to build APIs which I think is already there. We've done lots of outreach, we’ve done lots of communication. The Canadian Government of Canada CIO helped us a lot in making this becoming true. Beyond there is directive on APIs issued by TBS, which now forces or empowers the departments to build microservices and APIs into their software.

Laura: So it’s really working with the business units. So with those who deliver programs and services within their departments, so if you deliver a program or service, chances are you're you're exchanging information or data with someone else, or you're collecting data that could be used by someone else. I think having those are IT developers out there who understand those systems or they understand what we're doing for processes within everything. Now work together with their program delivery and service delivery groups within their organization. They can start really seeing some possibilities that could change things by inDonking or by creating APIs, maybe we can now exchange information between departments to help improve services, we can exchange or publish information to the public where others could start taking up those services as well. So I think it's really trying to not only just pitch from an IT perspective, it's really trying to have the programmers and the service delivery agents understand that there's potential here if you understand this, this API thing, that you can really change your business processes, you can really extend your reach for your services. And and like I said, before, you still keep control of that information in the data, you're just really doing things in a smarter, more digital way.

Mohamed: With regards to that, two aspects of the IT aspect means you're working to change the culture, to build that capacity to build APIs. The second aspect is: reach out to us, to the API team, the center of expertise for Government of Canada to get you access to the store so you can start publishing and interacting with, with the API Store.

Laura: And I think as well, by contacting the store, we're willing to come out and talk to your management teams, to talk to your business program areas, and let them know what the store is, what APIs are all about, and see if there's ways that we can work together and collaborate and get the groups speaking to each other or even if we need to bring partners in to work together on things, then I think we have the ability to do that if they reach out.

Rebecca: Right. Yeah, because I think there's some capacity to be built and some knowledge to be built. It goes back to the training point.

Chrystal: So the training is something that has popped up a couple of times, and right now we are it's something that would like to proceed with, when the time allows. But right now what we're trying to figure out is, how much do people want to do people it? Do people want us to do the training? So we're trying to give our feelers right. So whoever is listening, if you would be interested in it, it's definitely a point to reach out, because that would be great. Because, of course, there are these trainings that we give. And it's like, we can definitely, we have the equipment, we have the knowledge to give it, but who would like to receive it? So we can tailor it, what do you want to hear? What do you want to know about it? How do you want us to approach it? Those kind of things would also be a great thing to do. And it's something we did want to do ASAP. But of course, these things take time and planning. So you don't just want to jump into it headfirst. So yeah, that's definitely a point to consider. We as a COE, as a center of expertise can do our own independent training for people. And if we do a developer developer one first, then hopefully the interest comes in and we can build another training for business centered people as well. And of course, the more the interest comes in, the more we can focus more on different aspects of people.

Rebecca: So we've done a nice summary of how an IT person could, could pitch this or could use the API Store. But what about someone who's not specializing in IT?

Don: Well, I think it's important for, for non it people to learn about APIs just to know when to demand them, right? I mean, if you know if you're sitting in a meeting and and talking about, oh, a new version of our, you know, enterprise system is coming out. It doesn't take much to say, oh, like, do you have APIs? Like, is there a way for? I'm not necessarily an IT person, I don't know how to call APIs or write an app, but I'm sure if you expose the data in a way that other people can use it, people will use it and do something useful with it.

Laura: Yeah, I think it's really from a non-IT perspective is: what information or valuable data assets do I own or half that I'm sharing with others and is there a better way to share this and is that better way through an API? I think if they ask themselves that we're now saved, I'm sending them Excel spreadsheets before I'm sending them big files that they're just getting to one person, but I'm trying to get this information out to multiple people or multiple departments, and so on and so forth. That's where I can say, oh, maybe this API thing can help me get that message out faster, quicker, and an easier way that can free me up to do other things. So I think it's really understanding that what an API can do for their own programs in areas.

Don: As a non IT person example I use, not government, is Mint. Do you know the the service?

Rebecca: Mint! Yeah, banking?

Don: Yeah, well, thank you. But it's like, how do you, how they access your data? Well, you have a choice. I guess you can like upload a spreadsheet every month, or you just give them your banking information. That's a little suspect, you know

Rebecca: This episode is not endorsed by Mint, or eHarmony.

Don: But I mean, like, so that's the thing with an API that sets a contract, we have controls, we can have authorization and things like that, to enable access to services in a controlled fashion, to deliver value.

Ainsley: And also, I also think that like demanding for APIs also makes the government more transparent, because you can actually visit an API like a website most of the time if it's not secure, so you can actually just see the data. Right? So if you're interested in just seeing data, and then if you're a hobbyist and you're interested in different technologies, you may be able to incorporate it. It's not, the barrier to APIs isn't above your level, I would say.

Rebecca: I love it. I love it. It's so many things wrapped in one is you're doing kind of that user experience design. In some sense, you're kind of seeing that litmus test of what people want. And you're also doing consultation in a very organic kind of ongoing way, as opposed to saying, All right, guys, we're gonna spend six months doing consultation there. We're going to start doing the specs for the project. I'm going to roll it out, and let's see how it goes. So I really I really like it's it's agile, inclusive, and equipped. I think the one follow up question for you, Ainsley. There's this theory called contact theory. And I'm wondering now that that other teams are seeing what you've done with APIs, is there, are you seeing a little bit of an appetite now? On other teams?

Ainsley: Yeah, so definitely, I've been contacted a few times for help for developing their own Alexa skill. So there's one for helping Canadians for their citizenship. So using Alexa to practice what they need to practice. So there’s definitely more government departments that are using APIs to build their Alexa skill.

Rebecca: I think that's really important for our listeners to hear because it means that change happens, I think in sometimes small increments, and then one team does it. One little project does it and then other people can see it and it gets, it starts to take shape.

Laura: Ripple effect.

Don: Yeah, yes, success builds upon success.

Rebecca: There you go. There you go.

So I think really, we have covered a lot. And I think that this has been really remarkable. I have learned so much about this. And I’m just so grateful for your time, for your insight. And we're going to include some of the links that you mentioned on our show notes so people can learn more, we’ll conclude how to get support from the API Store. And yeah, this was fantastic. So thank you, everyone. Thank you to our listeners. And for you can find Busrides at busrides-trajetsenbus.ca. And so yeah, thank you so much, everyone.

Podcast Shownotes

Music: Higher Up by Shane Ivers - https://www.silvermansound.com

Open Government

APIs: Data Waiters in Disguise

Dare to be Open: A look at Open Government