Robert Flowers, @DukeEnergyMediaCtr

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore topics from the world of APIs, but we look at things through the lens of business and engineering leadership. Joining me today we have Robert Flowers, senior product owner and enterprise API oversight at Duke Energy. Robert provided me with yet another view of how experienced product owners are acting as the bridge between business, IT, and the consumers of APIs, but in the case of Duke Energy, also bridging compliance.

Let’s start with the basics. Who are you and what do you do?

All right. My name is Robert Flowers. I am the senior product owner for enterprise APIs and data products at Duke Energy. I’m actually on the east coast, in South Carolina. I’ve basically been in the IT industry for a little over 17 years at Duke Energy. I’ve been building APIs as a developer, and now I’m managing the vision of how Duke is using APIs to combine their business units and how they can integrate the work that they’ve got going on. So Duke Energy is working toward being carbon-free by 2050, and part of that is our modernization of our architecture, and part of that involves APIs heavily.

Okay, so you’re a developer, so you’re technical, but you’re working with business folks to kind of bridge what I would call the classic business-vs-IT divide that I’ve known for my entire career. Why are you making this shift, why are you being this bridge between these two groups?

Well, I worked with APIs and doing integration for years, mostly in the utility industry, and decided about five years ago to switch over to be a scrum master and be an agilist. And as I did that, it came to light what Duke Energy was starting to do, and how they were transforming the way they do work and the way that they look at it from a utility perspective, and it excited me. So I’m using what I know from a technical aspect to help bridge that gap with the business. I feel like I have a knack for explaining things to the business in a way they understand, it’s not too technical, but at the same time I can work with our teams as we’re building our APIs and our full enterprise data mesh, just to convey that information from the business and make sure that we’re bringing value to each of our business units.

Yeah, so important. So what I’m seeing across a lot of enterprise conversations I’ve had on the show, but also just through my regular work, is a lot of groups kind of responded—everyone’s doing APIs, it’s just whether you’re doing it with a strategy or not. And then the ones who have kind of gotten on the API train in the last five, six years have realized that they launched a portal, launched some very technical-lead-driven, well-designed technical APIs, but they lacked any business alignment, synchronicity, and they didn’t really accomplish much. So these groups are really looking to go back and get more business stakeholders involved in the conversation. So does this reflect what you’re seeing in the energy space? Do we need more business stakeholders at the table?

I think we do, especially when you’re dealing with all the different data domains that are just in the utility industry, where you have not just supply chain, you’ve got your work management, you’ve got your power generation, you have customer. And you can’t have one IT group or even a couple of departments to know everything about that. So what we’re doing is making sure that we pair with our business and we’re using their knowledge, and a lot of the things we’re doing are customer-centered designs. So when we’re talking about what we’re doing for an API or even an event stream for our data mesh, we kind of ask the business, what are you wanting to get out of this, what’s your use cases that are going to make the decisions you need to be successful? And from that we then can reverse-engineer back to what the source system looks like, we can build our connectivity back to the data products and the source systems that we need. But when the business looks at it, that’s what they—they don’t care about what it came from, is it an Oracle database, is it SQL Server, is it a NoSQL DB, they just want their data and they want to be able to do different things with it. Now, especially in the energy area, they want to not only just run reports and make decisions every day, they want to analyze that data that they’ve been collecting for years and be able to make better decisions and understand the trends and what affects their customers.

Yeah, that business value. But what do you mean by data mesh? You used that phrase. So how does data mesh enable that?

So what we’re doing is we’re looking at all of our different data domains, and we’re wanting those data domains to be able to talk between each other. So you can’t just have your work management doing everything in a bubble. They’ve got to know about assets, they have to know about supply chain and shipping, they also have to know about what customers their work orders are affecting. So in that example, you can’t just have one domain doing all the work, you have to basically have them talk between each other. So what we’re doing is using a data mesh that’s brand new to Duke, and we’re building those different building blocks—all the different domains, the subdomains—we’re building those building blocks and then tying them together so multiple people across the enterprise can see the same data and it looks the same across every single business unit.

Interesting. And would you—I feel like the last 20 years has been dominated by RESTful, using low-cost web technology to deliver digital resources as these RESTful web services, and that’s by far the most dominant pattern. But event-driven stuff isn’t anything new, it’s been around for a long time if you’ve lived through the SOA ages. But there’s this kind of resurgence, I feel like, this—I’m seeing enterprise organizations realize, well, what’s next is not just the resources, it’s the capabilities. So it’s the workflows, the automation, it’s events, it’s much more real-time and streaming, as you said. Is this what you’re seeing, is this just part of the maturing and journey we’re all on?

I think it is, but I think it’s not just the event-driven. You have to marry it up with request-response type interactions. So a lot of times where you would usually trigger something off of a batch—we always had a lot of things that would run every night, every day of the week, and it would go in and process large chunks of data—well, now with being able to use event-driven, we’re seeing data come across as it happens, and we can take those actions on that data the second it happens. But you’re still going to have to deal with large sets of data, so usually you’re going to use your APIs to enrich the data you’re working with. So you may get triggers off of, like, a bill being generated for a customer, but in order to know all the information for that, you’ve got to go to an API and get the historical information for that customer.

Yeah, that’s a healthy balance, I would say, because it’s not an either-or. You got to be doing—you got to lay this RESTful, synchronous foundation, and then the asynchronous kind of complements and goes together. But the other part of the journey that I’m seeing is a lot of enterprises are struggling to get to the point where you’re at, because they’ve had to do a lot of modernization of legacy systems. Are you through that journey, are you still fighting that journey, where are you at in that?

We’re actually—I would say in our adolescence of that journey. We’re not in our infancy, we’ve been working it for five years, but we’re still having legacy systems we have to integrate with. And what we’ve been seeing is, a lot of legacy systems, we were worried that you put too much effort on them, you hit them too hard with API calls, any kind of query or even batch processing, and it affects the throughput of the system, it affects the experience on the other end. What we’re finding out is, with event-driven and even using APIs, you can do things like putting a caching layer between your legacy system and whoever’s needing that data, that API, and the impact’s not great to the system of record if it’s a legacy system. Because we still have some data in mainframes that we’re having to hit. But what we have seen is that event-driven, because it’s small pieces of data moving across, it’s not hitting the system, and they’re not seeing as much of an impact. So we’re still seeing it, and we’ve got a lot of legacy applications that we’re well underway of modernizing. That’s how we’re also reducing our carbon footprint, is we’re moving toward a cloud-based solution, and that’s really what we’re thinking about right now, is cloud.

Well, that was going to be my next question. What’s the role of the cloud in helping you achieve this?

So what we’re looking at is one, moving our event streams—we’re actually using event streams right now to get data into the cloud and have a cloud repository of data for request-response and for some type of event-driven streams. But when we’re dealing with our APIs, we’re now looking at not just having full monolithic API collections, but we’re looking at using serverless technology to provide on-demand APIs that don’t need a persistent processing space like ECS or even an EKS type solution.

Nice. Yeah, that’ll give you a lot of that native cloud elasticity and flexibility that really is necessary, I think, to take this to the next level. It’s important. So your synchronous, your web APIs, request-response, are they contract-driven? Are you using Swagger, OpenAPI to help guide that journey?

So we’re kind of doing two things. We’re using OpenAPI and Swagger to define a lot of that, but we’re versioning our APIs, which is something different in our area, a lot of groups haven’t versioned APIs. So what we’re doing is using the contract of what’s the body, what’s the request, response, what’s the parameters needed, and that’s our contract that we agree to with the consumers. If a business need comes along where fields become required instead of optional, or we have to change the entire structure of, say, the JSON return for an API, that dictates a brand new version. But at the same time we’re keeping the previous version, because we have multiple consumers and you can’t request all those consumers to make changes within the next couple of months to support the new version, you have to keep multiple versions back. So we’re following that from an API versioning standpoint.

Nice, makes sense. Having a contract kind of managed—it’s just like business managing the relationships, the expectations, here’s what we’re agreeing to in a language we can all get behind and make sense of. So is that similar across your streams as well, your versioning your schemas across those as well?

Yes, and we’ve looked at a couple of solutions, one being Avro and being able to have schemas on our streams as they come back, and then on our API calls. But yeah, stream-wise we’re looking at versioning those. Most of those are part of our data pipelines for our data mesh, but we do have consumers of those streams, and we’re kind of putting those into an enterprise-wide data marketplace, where any kind of stakeholders, product owners, if they need to consume certain types of data, they can go and search on the data marketplace for the type of data they need. It’ll show the hierarchy of that data and how it’s laid out, it’ll also show any kind of governance that’s needed over that data, but it’ll also show ways to access it. Can you access it through a Kafka stream or can you access it through an API? And then from there they’ll be able to go to an API catalog that gets more into the details of, here’s the metadata of that API—and that’s that OpenAPI area—but then it also should allow them to request access for that API, be it a developer app key or some type of solution like that to use OAuth.

Yeah, sounds pretty far along in your journey. What’s the visibility for consumers, is this primarily internal, is there partner access to this?

So right now most of it is internal, for a lot of our integration between multiple systems at Duke. But what we’re looking at doing now is, we have a couple that we’re opening up to Duke vendors that do contract work and do work orders, and those are actually external. So they’re hitting our APIs, and they’re using that to go through the right systems to update other systems based on work management information.

Nice. Yeah, that’s going to help you move a lot faster, beyond the service partners like that. But I know the industry you’re in—what’s the regulatory landscape look like for y’all? I’m guessing there’s a lot to think about.

Well, there is. The government holds a lot of that when it comes to nuclear data versus fossil, hydro, or even corporate data. So we have to deal with a lot of different regulatory areas. And going back to what you were saying about the business, it’s very important to bring the business along, because the business knows those regulatory requirements that are needed, and they can help guide IT to make sure that they’re building and managing that data and not violating any of the constraints that are put amongst our different development teams, or even our business as a whole.

What can we do to make it more friendly for these business stakeholders? Because I’ve been on the regulatory side of this, and I know how much work this is, and I can’t keep up. So as technical folks, what can we do to make this more inclusive?

I think the biggest thing is an open mindset. Duke has been really changing their culture, and it’s not a business-versus-IT, they’re doing more, they’re collaborating. And that was part of the agile transformation for Duke Energy, is they’re wanting to include the business early on. And really what happens is, you have people that are not just developers now, but they do need to understand how to maybe explain things a little better for the business. I guess, to use the old days where, you know, engineers would get put in a closet to write code for six months and come out with something, and most of the time it was decent, but it was only about 20 percent of what they needed. We’re hoping to get that 80 percent when we work with our business from the beginning, and we’ve been seeing that in the last four or five years, where we’re getting to market faster with innovative solutions, and the business is coming along with it. So their adoption of that technology and even some of the new things that we’re putting in place is really high.

Yeah, I’m really seeing a lot of companies, large enterprises in heavily regulated industries—not just energy, but healthcare and insurance and financial—and what we’re really seeing is they come to us wanting to talk about governance. It’s kind of a Venn diagram: the regulatory and governance, domain-driven design. And I’m like, coming from a company, Postman, who’s very bottom-up developer-focused, I’m like, look, developers aren’t going to care about this governance stuff, it just doesn’t mean anything to them. You need to enable them. I need you defining what the vocabularies are for the domains, providing the tooling, creating these safe and structured spaces for developers to operate in, with all the necessary guardrails and bumpers, so they do the right thing regulatory, they do the right thing with common schemas and standards. Does that reflect what you’re seeing across your teams?

It is, but it also adds a little bit to it. We are also having to deal with the governance from an infrastructure standpoint. When you deal with the cloud, you have certain data that can go to certain areas in the cloud, certain requirements over data that is considered, you know, DFARS or even SOX, Sarbanes-Oxley, or from a FERC or even a Nuclear Regulatory Commission. So we have to look at not just what’s the guide rails and what’s the guidance on who has access to the data, at an individual user or group level, we also have to start thinking about, if this data is going off of or onto on-premises systems of record, what’s the governance and where can it sit when it goes into cloud? And that’s a big piece, and that’s something that you can’t navigate just as an IT team, you’ve got to have the business coming along with you, and they have to see your vision as you’re going along.

Yeah. So I’m going to come clean on what I said about seeing things from the regulatory side. So in 2013 I worked for the Obama administration, doing API and data interoperability, trying to get agencies to be more interoperable using APIs and open data. And one of the things they sent me to was a one-week-long negotiation, we’ll call it, with PG&E out here in California, when it came to the OAuth scopes for—so, say I’m a homeowner and I want to put solar panels on my roof, and I’m going to have a third-party contractor come out. What does a government mandate, or what’s an acceptable amount of data for PG&E to share with that contractor upon my approval? So OAuth scopes. And I learned so much about the energy industry, I certainly learned so much about the business. What you’re saying is this knowledge and wisdom—and it was intense. It got heated, I would say, some days. So it’s really an interesting—I think the partner asks to do this external, it’s not just internally within Duke to regulate at all these levels. You guys are going to have to be navigating this landscape across all these growing energy industries and contractors and third party. There’s a lot to navigate there, right?

Right. And there’s a lot of external influences on what we’re doing, with the EV movement that’s going on right now. I think all power companies across the country are looking at what impact is that having, and they’re having to work on building up their infrastructure to support that. And I feel like, when Duke Energy says they’re building a smarter energy future, I feel like I’m on the front line seeing that, and that’s really the exciting part. You actually can see the benefit of what you’re doing, and I see that day to day.

Yeah, wow. So we did have a show a couple weeks ago, it was an API-first company, all they do is the APIs for the EV charging station. So they’re specialized, they just do the payments and the energy, kind of negotiating what the energy price is and things like that, and they didn’t want to deal with the whole rest of the stack, they were just being API-first and solving one thing. But they talked about the strains that that’s putting on the energy grid. So you guys have regulatory forces, you have market forces, you have all these things kind of pushing and pulling on you, and APIs are how you guys are going to be able to respond and be able to stay agile enough, right?

And I think that’s the biggest thing. Just like you were mentioning with the healthcare industry and how you had integration between them, there’s not a lot of standards on how a provider like Duke Energy for power would provide data to, say, a consumer like an EV charging station. There’s not a standardized format. And I think, in order to make everything efficient and to make sure we’re all talking the same language, doing something like that is going to be very important, because otherwise you’re going to have a lot of extra work of translating that data and making sure—how do you validate the data, especially when you’re dealing with something as big as our power grid?

Yeah, those standards are critical. And I worked on the FHIR specification, Fast Healthcare Interoperability Resources, for a Center for Medicaid and Medicare, and helping with that rollout across 50 states. Last season we had an interview with the state of Colorado, and they were talking about, you have to—to do business with Center for Medicaid and Medicare, as a state you have to have a FHIR-compliant API. So I think that’s a fairly healthy representation of government-led standards in this way. But from what I’ve seen with PSD2 in Europe, financial—I’m not entirely convinced that government creating internet API standards is where I want to be. So would you say Duke’s in a position—because what I see is, if you get APIs well enough as a company and you’re able to move fast and iterate and have these processes in place, your approach and your schemas can become this standard by default. Are you confident enough to say that Duke could be in that place in the next 20, 30 years to help lead that way?

I would say that’s definitely a goal for the future. I think that, with what Duke is doing from being a—trying to be one of the first digital power companies or energy utilities—I think it’s on the table for maybe the format or the standards being led by what Duke does. So I think it’s possible.

Yeah, because I really feel like it’s not just the standards, not just the naming and ordering of the schema or the design of the API, that’s part of it, and watching these standards roll out. But it’s what you described as that relationship between business and technical, that feedback loop and that ability to iterate through versions and respond to partner needs and market needs, that creates the best standard, in my opinion. That flow, that process. So as a company, you can get to that point where you’re that agile, nimble, and you have the right business feedback loops, you’re going to create a pretty compelling standard for any specific slice of the industry you work in.

Yeah, and one thing that Duke has done in the last five years, probably moving a little bit longer than that, is what they’re doing with innovation. They’re not accepting the way things have been done for 20 years. So when it comes to thinking outside of the box on how we deliver data and how we handle that data, I feel like Duke is really pushing the envelope. And I think there can be some standards and some common language that comes out of that. But just like you were saying, you got to bring the business along, they’ve got to be there, because those are the ones that make the decisions. And it’s not just for Duke, it’s for any other power company, and it’s basically, how do we talk from an energy resource across all the different municipalities and different groups there are in the country? I think that’s a very important thing.

Yeah. So you seem to have a real solid handle on the technical of data, the value of data, the importance of it. Does business leadership at Duke really grasp it, as—I mean, the data is just as valuable as the energy that you guys transmit through your grid as well. Do they see it?

I think so. From everything from the data that’s used to forecast the energy usage, to anything that’s used for how our customers think about the services we’re providing. I hear a lot from an enterprise perspective, from different products internally to Duke that are using data in different ways. They’re wanting to use machine learning, they’re wanting to use different process analytics, and that’s just on the customer side. There’s a lot more they’re looking at, for, like, leak analysis. And that’s not just on the electric side, that’s on the gas side. They’re also looking at different things with connectivity on our power grid and how that works from a geospatial perspective. So I think our business does see the value, because otherwise we wouldn’t be getting requests and new ideas for brand new products that our stakeholders see are valuable for making the business more successful.

Yeah. Well, to be able to respond to all this and have the feedback loops in place, you need a certain amount of observability. So I’ve been doing APIs full-time since 2010, and I’ve been very vocal in public, and I get on airplanes and people are like, what do you do for a living? Well, I’m API Evangelist, or I’m an API specialist. What’s an API? Trying to explain to them what an API is. But you can’t see APIs, they’re not physical. So when it comes to infrastructure at this scale, it’s really hard to see things, these things are abstract digital concepts and capabilities. So what do you all do to help with observability and see things, see how it’s happening?

So really, what we do is we look at two things from an API perspective. We look from a data perspective of, are we providing value for the data for the business to make the decisions they need to make? The other thing we’re looking at now, and this is more from an enterprise, is how much extra effort did we save other product teams by using our APIs? Did they—the old school was every small team would build their own APIs against their own data source and it would just be used internally. We’re trying to get away from that and save developers hundreds of hours where they’re just recreating the wheel. And we saw that a lot in the past, and that’s what we’re getting away from. So I think from a visibility standpoint, when we see multiple teams using our APIs, we’re going through that API lifecycle, looking at observing what our APIs are doing, how many requests are we getting, what type of data throughput are we getting. But when you can see multiple consumers hitting your API, that you’ve actually gotten to that level of enterprise usability, and that’s how we gauge how our APIs are and how visible they are.

Again, looking at it through the business lens, which I think is pretty critical. You got to look at all of this technical stuff through a business lens. If it’s creating value and doing good things there, then it’s important. Otherwise, no, deprecate, move on, figure out some other approach. So another area that’s top of mind in most of the conversations I’m having is security. So I’m guessing y’all are a pretty good target for people wanting to do some not-so-nice things. What’s the security landscape look like for y’all?

Well, we’ve got very dedicated cybersecurity departments that amaze me every time I talk to them about new things that they know about, new things they’re checking us for. They do a lot of—there’s a lot of auditing on our side just internally from an IT perspective, even from an API. Some of the things that we get checked on—there’s a lot of governance over that, we’re not allowed to just throw things out there. Even internally, you would think from an internal perspective it would be a little open, because everybody’s one big happy family, but no, we have to deal with who can have access to that data and how do we secure it. And now as we’re moving to more external, there’s a lot of work before we can even put our first API out there that is externally accessible. But we’re using a lot of the industry-standard tools, like Apigee. We’re doing our monitoring using tools like Dynatrace, just to verify what our everyday usage is, we use it for monitoring, for maintaining the health of our APIs. And as the landscape changes, which it does change daily, I think we’ve got the right people and the right knowledge there to keep us going on the right path.

Yeah, it’s an ongoing battle, and you have to have the observability, you have to be able to see and understand your traffic, to be able to understand patterns changing, shifting, all of that, what’s healthy, what’s not so healthy. But for you, what’s new and exciting for the future, looking forward? What are you working on, investing in, that keeps you coming to work?

Well, the whole idea of how our APIs are delivering data. I can say in the last year and a half, I’ve gone from being more developer-focused on individual products, to how do we look at an enterprise level. So I was able to take a step back and see the benefits, and you really understand how large this is and how different teams use that same data. So as we’re moving toward a modern architecture with cloud-based, with AWS, just seeing how all that ties together—everything used to be just sitting on-prem, and it seemed like it was really easy to develop against that. Coming into it, I had the idea of, oh, well, it’s probably a little more difficult dealing with things in the cloud. But as we’re seeing, it’s not, it’s just another way of doing it. I’m not at that point where I’m down in the weeds developing, but being able to understand how the data moves, and then how we can access that data, and then being able to explain that to the business and bring them along—I think that’s my biggest drive, what I come into work for every day, is being able to explain the vision of the company and what we’re doing and get people on board. When I get people that have the lightbulb turn on and they understand what I’m saying, and they get excited like I am about it, that really gives me fulfillment in my position.

Yeah. So, I’m chief evangelist at Postman, my blog that I’ve run for the last decade is API Evangelist, and I’m almost to religious levels of a believer in storytelling, getting people on the same page, getting people excited. But I talk to a lot of enterprise organizations that are very siloed. People learn different parts and they don’t have visibility, and they don’t always care about change at the org level, they’re more focused on their incentives. So how do we light up more people like you, within either technical or business groups? Because I feel like your persona, what you do, is how we get where we need to be in the next 20 years.

Well, I think that what you’ve got to do is, you’ve got to let both sides of the business, your development side, your IT side, they need to feel like they’re in a safe place and they’re empowered. I feel like, by them feeling empowered, they’re going to cross that line, they’re going to bridge the gap between IT and business. And it’s a cultural change, I think. It’s not just learning how to modernize, learning how to go to the cloud, knowing how to use event-driven and data mesh, like we’re doing. But I think it’s important to know that the business are also just other people that are trying to get their job done, and when we understand that we’re helping facilitate that, and we can work together to get things done quicker and also maybe even learn something along the way between both sides—I think that’s what it takes. It takes people just being willing to get out of their comfort zone, break down the walls, and really collaborate.

Yeah, so important. Trying to stop isolating people, like you said earlier, developers locked in rooms and slide pizza under a door, just seems like such a last-century concept as far as how we do this. And I’ve been there, I’ve been that developer in the room with people feeding pizza to me, and I would never go back to that.

Well, in this world—at Duke a lot of you, you’re all dealing with a lot of change in how energy’s created, how energy’s used. What’s changed during the last two or three years with COVID?

Oh, wow. Well, it’s kind of funny, because we really, just before COVID hit, we were pretty hot and heavy on our APIs and actually using microservices. We just got done putting one of our first Lambda functions into AWS that was used by the customer side, and actually the week after the pandemic started and all the lockdown happened, we had to deploy our first Lambda API into AWS. But what changed was, we had to learn new ways to communicate, new ways to work together. A lot of our teams are strictly XP, some are scrum, and some are kanban. I think our XP teams kind of stepped up to that a lot faster because of the pairing methodology that they use. The team I belonged to while the pandemic was going on, it feels like they didn’t even miss a beat, so there wasn’t much change except in how do we communicate and how do we keep working. And I think as we’re getting back out of that, a lot of different areas see that IT can be just as effective working remotely as they can working face to face. But at the same time, when you get to go back into the office and see a member of your team that you haven’t seen in person in two years, it has an impact on you.

Yeah, so I mean that was kind of interesting. But I think you really do see who can adapt, and we have a lot of great developers that adapted to this and were just as effective during the remote work sessions as they are working in-house.

Yeah, it’s definitely a strength in my team. My team’s pretty global, but it’s really strengthened a lot of how we work, and we know we’re never going back, there’s no shifting to the old times. And having the conversations I’ve had with different companies on Breaking Changes, I’m seeing how similarly they’ve adapted in different ways. So, as I was listening to you talk, I think what I’m going to try to do—so, what are we, 2022 here, coming up in the summer—sometime next spring, I think I’m going to do a Breaking Changes kind of reunion, and I’m going to get like—so we’ve done one of Boy Scouts of America, their API first, 7-Eleven, Formula One, Goldman Sachs. So I haven’t had any energy ones. So what I’m thinking is, I could maybe get you all together for a day or two and do some talks or some round tables or something. Would you be game for something like that?

Oh yeah, that would be fantastic.

Yeah, I think that might be interesting, because I’m going to purposely not have one from the same industry, just have all different industries all together and see what kind of conversations we can stir up with that.

That’d be exciting. Great.

Well, I will tap into you for that a little bit later. But this has been great. It’s been enlightening. I love learning more about the energy space, understanding how you’re all attacking the future and using APIs to do it. I appreciate your time today.

Sure, I appreciate it, Kin.

All right, thanks, Robert.

Thanks again to Robert for stopping by. You can find more on Robert on LinkedIn, and you can learn more about Duke Energy at duke-energy.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host, Kin Lane, and until next time, cheers.