Launching API Programs in Non API-First Companies
Ep. 11: Jeannie Hawrysz, leader of API Programs at SAS
Moesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals.
Joining us is Jeannie Hawrysz, the Lead API Architect at SAS, a 22,000 person business analytics company. Before that she was an 18-year veteran at IBM and was the Technical Development Manager for IBM’s API Connect Micro Gateway. In our podcast she shares how to successfully launch API programs in non API-first companies.
Larry Ebringer, Moesif’s CMO, is your host today.
Listen to the episode on SoundCloud above, or download it on Apple or Google.
Table of Contents
- 1:14Work In API Management
- 4:45Form a Center of Excellence
- 8:58Build Bridges Across the Lifecycle
- 10:30Sweat Dev Personas
- 12:25Workflows Guide Devs
- 15:50Biz Reasons for External APIs
- 18:29Minimum Criteria for Externalizing
- 22:43Product Management is Accountable
- 24:28APIs Make Money
- 27:344 Technical Considerations
- 30:15Align with a Business Need
- 31:37Have Patience, a Vision and Empathy
Larry Ebringer (Moesif): Welcome to Episode 11 from Moesif’s APIs over IPAs Podcast Network. I’m Lawrence Ebringer your host today and the Chief Marketing Officer of Moesif, the API Observability Platform. Joining me is Jeannie Hawrysz, the Lead API Architect and Manager at SAS, a 22,000 person business analytics company. Before that she was an 18-year veteran at IBM and was the Technical Development Manager for IBM’s API Connect Micro Gateway.
Jeannie, welcome to our humble podcast network. Where in the world do we find you?”
Jeannie Hawrysz (SAS): Thank you. So I’m located in Cary, North Carolina. I work at SAS. Well actually, I work at home right now with my family.
Larry: As we all do.
Jeannie: I’m located in North Carolina and love it here. Mountains and beach, you can’t go wrong.
Work In API Management
“My project’s been canceled … what should I work on … you should try this API-management thing”, as he handed me this O’Reilly book called APIs: A Strategy Guide. I read it overnight. I couldn’t put it down. That’s how I got into APIs and API management.
Larry: Excellent. Well, kicking things off, why don’t you share with us your path through the last 18 years at IBM with their API gateway product and then bring us up to speed with you running all APIs at SaaS.
Jeannie: So I’m going to try to cover 18 years pretty quick. I’ve been really, really fortunate to have a lot of different opportunities within my career, both at IBM and at SAS. I started out as an engineer working on the mainframe TCP/IP stack, and I got to work in support, performance and development. I got my big first opportunity for technical leadership across divisions to build an SDK that people were going to use to build software and virtual hardware appliances. Unfortunately, that project actually ended up getting canned because of business priority reasons in the summer 2012. Which was a pretty big bummer because it was my big first leadership opportunity. But all the people that were working on it were invited to come work on the data power appliances which were doing pretty well. There were a bunch of different technology areas that needed engineering help. The CTO of data power at the time was actually my mentor when I had been an intern, which was kind of serendipitous. So I immediately went to him and said, “My project’s been canceled and I’m coming to your area, what should I work on?”
And he said “You know, I think you should work on this API-management thing.” I had no idea what that was, I had no clue. But he handed me this book called APIs: A Strategy Guide, that was an O’Reilly Book, and I read it overnight. I couldn’t put it down. That’s how I got into APIs and API management.
Over the next couple of years I did work as an engineer on the monitoring component of the API management solution for IBM. And then I ended up becoming a software development manager for the team that produced the data power RestAPIs, several of the cloud integration teams and then eventually the IBM API Connect Microgateway.
Weirdly one of the reasons that I left IBM and started looking at jobs outside of IBM was that I was actually really getting sick of APIs. I was “APIed out” and was ready to start looking at something else. I had big plans. I was going to become a security expert and totally rebrand myself. But somehow I ended up back at SAS working on APIs again. But, it was different. It was a much, much different experience than I had at IBM. I’ve had to learn, grow and embrace more of the API lifecycle than just on the technical side. Learning a lot of things that I hadn’t learned earlier in my career. So it’s been very interesting.
My career is really focused around networking, but all always seems to kind of gravitate back towards APIs. And it’s been really exciting to actually be at the ground floor of a program, the way that I’ve gotten to be at SAS.
Form a Center of Excellence
A center of excellence in API engineering manages standards, guidelines and common patterns, provides a catalog, employs the latest version of OpenAPI, has schema validation and style rules, and reviews each release
Larry: Well, that’s a ton of experience in the API landscape. I know that O’Reilly book well, that started you on that journey. So that’s very exciting. You’ve built what sounds like a significant number of API programs, both at IBM and at SAS. What, in your estimate, are the key steps in building an API program in an existing enterprise software company that, obviously by definition, is not API-first.
Jeannie: So to be clear, at IBM I wasn’t really the puppeteer, the string puller, I was more a piece of the puzzle working as a software development manager. But I took that opportunity to learn as much as possible about the rest of the lifecycle and I’m really grateful for that experience. If I had just gone into trying to lead a program about APIs, without having that technical experience, I would not have been successful I don’t think.
When I came to SAS in this role back in 2017, there were actually some good elements of an API program present. They did have a Center of Excellence, which was excellent. They had standards and guidelines, and some common patterns. They were all written down and established and they’d been talked through. They had an internal API catalog, which was great. They were using Swagger V2, which was the choice back in 2017. They had schema validation and style rules, automated at the time. And they were doing API reviews for each release. All of these things were really, really awesome. When I got there I thought that I wasn’t going to have my work cut out for me, because they had already solved it all. But what I found as I started teasing things out is that we had really only focused on the technical aspects of the program. And not really on the business aspects as well and some of the things weren’t working, or weren’t going to scale, or weren’t going to work with CI/CD. At the time I joined SAS we really weren’t doing CI/CD en mass and we were starting the process towards transforming the company towards that. And reviewing each release using a centralized team wasn’t going to work, so we need to start thinking about how we would decentralize.
Once I understood that we were more at the beginning of starting a program than I thought we were, I was definitely scared because I’d never run an API program or any program of this size before. And I had really thought that this job as an architect was going to be more about working on architecture and writing platform support code for all these things. It just ended up that those were things that maybe were in the best shape and they weren’t the priority of the time. We needed to start thinking about how to get alignment from the rest of the business and look at gaps in the lifecycle and fill them. I was asking myself “How do I do this? How do I turn a big ship.” And never having done this before, and still pretty new to the company, I had been at the company for a little over a year when I took this role, I needed to build up some credibility, because who was I to come in and tell people that thought that they were all on the right track, that there were things that needed to change? I didn’t want to be the person coming in from the outside and saying “everything’s terrible”, because things weren’t terrible, but there were definitely things that if we were going to make this a successful program that needed to be looked at.
So I’ve been solving this for the last three years. I really believe in APIs and I believe in APIs as a business foundation. Having that background at IBM and in the API economy really inspires me to make this happen. I really believe that it can. So I think that there’s opportunity there and SAS has such rich analytics capabilities that I know that we can differentiate with our API.
Build Bridges Across the Lifecycle
Identify believers in other divisions to help build bridges across the entire company, not just within the engineering division, but also within documentation, product management and support
It did feel slow at first, because the big thing was that I needed to start building understanding of where we really were with the APIs as a program and where we needed to go. We needed to get leadership, not just within the engineering division, but also within other areas like documentation, product management documentation, and support. We needed to get this quorum of people across the entire company that understood the business value and how to move forward. I was very, very fortunate to have some believers in other divisions that helped me establish leadership there and start building bridges across the lifecycle. There were definitely some people that got what we were trying to do from an API program perspective very early.
The big thing was that we started getting key roles set up so that they could help me help make this happen, because there was no way I was going to be able to do it all by myself. The first thing we added was a developer advocate, because we needed somebody to be able to help evangelize things both internally and externally around APIs. We added a project manager and who’s actually now more of a program than project manager. A documentation lead and with that we sort of formed what we called our API-First Core Team, a cross-division leadership team responsible for providing the strategy, direction and enablement that is needed across all of SAS to essentially make APIs happened.
Sweat Dev Personas
Developers should be first-class users of your software, they deserve to have an excellent experience
There are two things there that I did want to mention that have given us the biggest leaps forward: first of all, as an overall company, we have had a turn towards a more outside-in perspective with regards to technology and moving to be really product lead, And championing these design-first developments, not just API design-first, but design-first development. And the fact that the company was going in that direction anyway really aligned very well with where we needed to go with APIs. Our API-first initiative is totally built on the idea that the developer user experience of interacting with an API is worthy of design thinking and of sweating the personas that are going to use them. The developers are going to be first-class users of our software and they deserve an excellent experience.
The second game changer was the support that we’ve gotten from the SAS design team. So they didn’t hesitate at all at the challenge of taking their user-experience design knowledge and helping figure out how we translate user experience to API design workshops with product teams and stakeholders. So that was a big deal when we started doing API design workshops and started getting people across the lifecycle to start thinking about what people are really going to care about in terms of APIs. We could not have made the progress that we’ve made in the last three years without getting that alignment across all the disciplines. And it’s also just sponsorship from our leadership, having our CTO talk about APIs being important in meetings. It’s been pretty amazing the journey that we’ve been on. It’s been really great.
Easily Visualize & Fix API Issues with Moesif
14 day free trial. No credit card required.
Learn More
Workflows Guide Devs
To meet governance expectations, employ guardrails to guide devs
Larry: Well, thank you for covering the key elements of what an existing enterprise software company has to go through to, as you said, slowly turn the large ship to attack a new and burgeoning market. Drilling down a little bit into best practices for architecting APIs across different engineering teams, what standards have you found are the best ones to follow?
Jeannie: So our ultimate goal is that, through the design-first methodology, teams will be architecting and documenting their APIs to meet standards, as well as performance and security expectations from the beginning. We aren’t all the way there yet, but there are definitely teams further along down this journey and we’re very optimistic and now feel supported in influencing teams to follow our standards as a best practice. We do have a documented set of searchable standards and things like; how to do versioning, what HTTP status response codes are acceptable and common design patterns that are searchable. There are guidelines, recommendations and patterns for how to do different kinds of interactions. We also have a single repository that houses all of our API docs that are now still Swagger V2, but we’re in the process of moving towards OpenAPI 3. We have a decree for people to adopt OpenAPI 3 by the end of the year. And that forms the basis of our API catalog for easy Grepping.
But, like I mentioned earlier, it can be to a lot of information for people to be able to parse these standards themselves and interpret them. Because of that we actually wanted to do some more proactive work to help give guidelines for our developers to be able to follow these standards from the start. So, we’ve created something that we call the API-First Workflow, which is essentially a Jenkins Pipeline that takes our OpenAPI documentation, that’s housed in our developers’ repositories, and any supporting markdown that they have written to help guide developers as they’re using the API documentation. And it gives the development teams guardrails to make sure that their APIs are meeting governance expectations. Things like the refs resolving properly, or we have a ton of spectral rules that we have to enforce style and writing guidelines. Things like summaries that don’t have periods at the end of them, that helps us be more consistent across our API docs. We have mock servers set up that are automatically stood up based on our OpenAPI docs as part of this workflow. It’s been successful, we’re still early in adoption and we’re sort of marrying the OpenAPI conversion, the OpenAPI 3 modernization, to adopting this workflow. But so far the feedback that we’ve gotten from the people who have adopted has been really good. We’re continuously taking feedback and learnings and trying to make it easier for developers to stand up their APIs to meet expectations more quickly.
Biz Reasons for External APIs
All APIs should be designed with the intent that one day they’ll be externalized, so the product manager’s business rationale has to answer the question “Is this API appropriate for the audience that I’m looking to target?”
Larry: That’s fantastic. You’ve certainly built a plethora of supporting infrastructure and documentation to architect your API interfaces. And you’ve sort of usurped my next question, which is what do you think about how important OpenAPI 3.0 is, but you’ve certainly covered that. So why don’t we move on to the next section talking about internal and external APIs. So, we didn’t cover it initially, but your program at SAS has been very successful, you’ve exposed more than 50 API services to the developer community. So, share with us the process for a product manager to release their internal API as an external product.
Jeannie: So the big thing is that if we have an existing internal API that a product manager does want to put out into the world, their responsibility is to come up with a business reason for that to happen. That’s because, moving forward what we really want to have happen is for APIs to be architected from the beginning, and designed from the beginning, to be externalized. That hasn’t always been the case with all of our services in the past, so we do have to take a pretty good eye towards “Is this API appropriate for the audience that they’re looking to target”, or does it need a layer of abstraction on it for it to be usable for the audience that they’re targeting.
So the sort of authority around that is the product manager who gets to make the ultimate decision on whether or not it gets a release. They could override us, but I have an overall product manager that I work with on the business side, and between she and I we look at the API, we talk it through, we talk to the product manager to really understand what that use case is and we talk about the risks. If you are releasing an internal API and it’s not something that you think is going to be long term you have to think about when’s the end of life going to be. Are you thinking about whether they’re ever going to be breaking changes to this API. We advise them on the risks and in some cases they accept those risks and they publish API anyways for external use. But in other cases, there have been cases where people are like “Oh, well now that I understand this, we really want to build another API that’s the one that needs to be externalized.”
Minimum Criteria for Externalizing
Minimum acceptance criteria for releasing an API includes: accurate & tested documentation, a pledge from the PM not to make breaking changes, meeting appropriate security & performance expectations, and a real use case for putting it out there
We do have criteria for externalizing APIs that we call our minimal acceptance criteria. Our minimal acceptance criteria for the APIs is that they have to meet our SAS API standards and guidelines around basic industry expectations of consistency and usability across the product that they serve. They need to have fully written documentation, and then that documentation needs to be accurate and it needs to meet consumer needs and expectations. We want them to contract test the documentation to make sure that the functionality of the API meets what’s actually documented. We want them to basically pledge to not make breaking changes unless there’s some dire reason to do that in the future, obviously a terrible security issue or something that needs to be addressed. But we want these things to have longevity and we are really thoughtful and mindful about trying not to introduce breaking changes, and advising our product management teams that this matters to people who are using the APIs. We can’t break these out from underneath them, because people get very upset and write snarky things on Twitter about your company if you do that. So we’re very mindful of that. If we do have to deprecate or remove something, we are very thoughtful about deprecation with announcements and cycling around that. We need them to meet all of the product security office’s expectations. They need to meet any performance expectations that are set out for the product. And it needs to have a real use case, it can’t just be like “I wrote this cool API and I want to put it out there and somebody might use it, or nobody might use it like there.” There has to be a real business reason for putting it out there.
Then the last thing is a little more esoteric, but it’s that we want to make sure that there’s a feedback loop between the owning product management team, internal consumers and customer facing teams, so that we’re continuously getting input about the API. Because if the APIs not working, then maybe we need to build something else. But that feedback loop between all the teams and getting so the product managers really understand how people want to use the APIs, or are using APIs, that’s really the way that we know that we’re best serving the community that’s going to be using these.
Larry: Right, it’s very important to understand what your customer is and isn’t using your API for, and whether it’s being successfully deployed or not. That’s a little bit self serving, because I work for an analytics company and that’s what we do, but I totally appreciate and understand that issue. It’s funny that you brought up one of those criteria for externalizing an internal API, because in a prior podcast with Mike Amundson he said that one of the most important issues you should consider, when creating a new external API, is making sure that it follows all of the compliance and security issues that you would want for an external-facing service from your company. And that the best way of ensuring that, is when you first build your internal API to have the mindset that one day this may well be an externally facing service.
Jeannie: Yes. The big thing about that, is that we have a bunch of APIs that already exist and there are going to be cases where we have customers that have an immediate need for them, and I totally get that from a business standpoint, but our goal really is to start designing these to meet these expectations from the beginning. And producing things that can be externalized even if somebody might not want to do that from the first.
Product Management is Accountable
Product management should be rigorous in ensuring that all checks are completed, so that a whole product can be delivered
Larry: Right, so you at least have the capability built into the API from day zero in case you do want to deploy it externally. Digging a little bit into what you said earlier about the business case, in your experience who needs to champion an API to get it developed, or externally released? Does it have to have a sales and marketing buy in? Do they need to have a business case that’s ironclad, or is a champion in product management enough?
Jeannie: So for externalizing internal IP, you need a product manager. You need somebody to fill the product owner role, somebody that’s going to take ownership of the API from a business perspective and be accountable for it from a business perspective and make sure that it meets all of those life-cycle expectations from a business perspective. They’re definitely, like I said, needs to be a clear business need. You know, we have had engineering teams come forward with APIs that they have written and that they want to externalize. We just need to make sure that all the check marks are done, not just around meeting standards, but stuff around: has the support team been trained so that they’re able to support this API once it’s out, has it been tested, do we have good documentation for it? All of those things matter. So we really need to have the rigor of some sort of product management or somebody in a product management role to be accountable for that.
APIs Make Money
Decision makers should gauge the ability of APIs of be a profit center by showing them use cases from the field and exposing them to leaders in the field
Larry: Right. Makes a lot of sense. In terms of value creation, making money or losing money from your API - how do you get the decision makers in larger organizations to understand the value potential for APIs, where they could either make money or lose money depending upon if it’s done right?
Jeannie: So this has definitely been an uphill battle, battle’s the wrong word, because like anything in business focusing on something that’s brand new to that business that has potential and that hasn’t been proven yet, especially in a 40+ year old company, that’s naturally going to compete with other business priorities. And many of those other priorities that we’ve had over time, those were already making real money. And we’re just theorizing right? And, until it’s real, we’re theorizing that the APIs are going to make money. The tide is definitely turning though. We’ve gotten a lot of use cases from our field. We’ve been connecting with leaders in the field. They’ve been asking for high-value, easy-to-use APIs. We connect those people, that are coming to us and telling us that they have use cases for SAS APIs, with the decision makers, product management and our executive leadership who actually get to prioritize the work and hire the people to create those things. We present our vision and we’ve been very persistent, hopefully not annoying, but we’re pretty persistent in trying to champion the fact that there are a lot of people that are making money off of their APIs. I think that there’s a real opportunity within our business to do that as well.
I do think that we are definitely making a difference and I just wanted to share a very cool story that happened just last week actually. One of the coolest things that has happened in my career was that we have a brand new CTO at our company and he asked our API-first program team to come demo our vision of our new reboot. We’re working on a reboot of our developer.sas.com developer portal, which is also very exciting, and he wanted to do an overview of where we wanted to go with providing APIs as a service. And he surprised us by kicking the meeting off with his own research, where he brought a couple industry articles to share with his executive team around companies that were API-first and companies that were very successful being API-first. It was really, really cool to hear him talking about APIs as something that people would pay for. And to know that we’ve got that top-down support to move forward with this program. In addition to that, I’m going to have the opportunity to hire a bunch of new people soon, so be on the lookout on LinkedIn for that.
Larry: Well, maybe we could put a link in the transcript from the podcast to your open recs.
Jeannie: We can definitely do that.
4 Technical Considerations
There are four main technical considerations when establishing an API program in an existing enterprise software company: getting down the design standard & documentation guidelines, being flexible since standards will change, providing guardrails & tools for your devs and insisting on the use of OpenAPI
Larry: Good. Well, that’s great that you have the support from the top down, from the new CTO, to grow and expand your API program. So, wrapping up, share with us your best practices for establishing and growing an API program in an existing enterprise software company.
Jeannie: So, I think there are three different areas that you need to focus on so. The first area is the technical side. Getting that design standard down and documented is essential. Getting the rules of the game down are essential. I was very lucky that we had that Center of Excellence originally, that had really thought that through. I inherited a standard. I don’t love everything about the standard. There are things that I can’t change, because then it would make everything inconsistent, but I love that there is a standard and that there are guidelines to follow. That makes a huge difference to the people that need to consume the APIs, and it really, really matters to them.
Being cognizant that standards are going to have to evolve, that’s the second thing. I’m already seeing reasons why I might have to develop a second standard just for low code/no code APIs or APIs as a service. Our standard that we have today is really focused on our microservices RestAPIs and I’m seeing that some of those patterns aren’t really going to work for some of these other areas that we want to move into in the future. So, just knowing that there are things about the standards that I can’t change for the microservices, or will get inconsistent, but those things might not make sense for these other kinds of APIs and that’s okay, it’s okay to move forward, it’s okay to evolve.
And then the third thing on the technical side, give guardrails and tools to the makers, the people that are providing the APIs. And make it as easy as possible for them to follow styles, standards and guidelines. I have a very small team and I wish I could do more and give them more tools, but we’re very focused on that. I know it’s hard. The developers and engineers, they have all these things that they need to worry about in terms of quality, as they’re building out these API. The easier that you can make that for people, the better they’re going to do it, adhering to them. And then I just have to plug OpenAPI, because if you’re not using OpenAPI I don’t know what to tell you. You will thank yourself, both for doing design and for doing documentation. And if you’re not doing it, do it.
Align with a Business Need
When establishing an API program in an existing enterprise software company bring evidence that the API program is worthwhile — customer-facing teams carry a lot of weight
On the business side, especially if you’re at the beginning of forming a program, find allies. And the thing that really started us moving forward on APIs at SAS was once we really started connecting with the other people at SAS, people who believed that APIs could be more than plumbing and that they should not require a 10X developer to perform an integration. It’s one thing to have the API cult, which is what we kind of call ourselves internally, “APIs are important rah, rah, rah”, but when other teams, especially customer-facing teams, started supporting us, that’s when things really started to accelerate. And that also fits in nicely with my next one, everything you have to do has to be aligned to some sort of business need. You need to understand where you are in the overall priority and do as much as you can within the constraints that you have. Even while you lobby hard to raise the priority and get the help that you need to really make the program take off. You have to be persistent, you have to keep pushing for it. If it’s something that you believe is going to be important to the business, keep making the case. And I know I’m not going to say every company is going to get it, or turn the tide on this, but I will say that if you bring enough evidence, eventually things start to move.
Have Patience, a Vision and Empathy
Be patient when building your API program. Be empathetic to others who don’t see things the same way that you do - try to build bridges to help them understand. Have a vision and work towards it.
And then on the personal side, I just want to say be patient, I’m not patient at all, I’m not a patient person. When you find yourself at the beginning of something or walking into a situation that’s not as baked as you thought it was going to be, it can be easy to walk away. And you know that was something I thought about early on, I was like “whoa, this is going to take a lot of work, and these are things that I don’t know how to do.” But what I’ve really found was that this is an opportunity to build something amazing. And I still don’t know everything. I’m still figuring out a lot of things. But if you’re in the position that I’m in, where you’re trying to figure out how to build a program, stick with it, because first of all it’s great experience and, second of all, APIs matter. APIs are worth it. And I think that you’ll find that it’s a rewarding experience, even if there might be some early frustrations.
The second thing is have a vision. If you don’t have a vision, you’re in trouble. Even if that vision that you have seems really impossible today, or looks like it might take a long time, having a vision kind of gives you a thing to work towards. So I think that’s really important and then the last thing is just have empathy for people that don’t see the things the same way that you do and then try to build bridges to help them understand.
The last thing I was going to say about this, is just believe in the APIs. It’s not even a hyperbole to say that APIs are the foundation of our connected existence today. They may take on new protocols and trendy new styles, and widely varied use cases over time, but there will always be a need for integration. And there’s always going to be a need for machines to be able to talk to each other, and for humans to be able to talk to machines and there’s huge value in that ability to communicate in well designed seamless ways. And it’s getting increasingly easier to make this business case around APIs given the emergence of so many API-first businesses. So, if you’re struggling, or frustrated, or you feel like you’re not making progress, hang in there and keep at it and “API the world.” I think you will have success if you keep working on APIs.
Larry: Well. That is quite an endorsement for the field. And I’m sure all of our listeners are very happy that you didn’t leave the world of APIs, that you’ve remained in “the cult of APIs”, as you said. Well Jeannie that was a great chat with you today, explaining how a large existing enterprise software company has embraced the burgeoning world of APIs. And how to do it and gain success and profitable services from employing the right procedures and programs. So thank you very much in taking part in our podcast network today.
Jeannie: Absolutely, thank you for the opportunity to come talk about this
Larry: Thank you.
Make Your API Platform Successful With Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.