Timophey Zaitsev, Ridgeline

All right, welcome back to another episode of Breaking Changes. My name is Kin Lane, I’m your host today. I’m the chief evangelist at Postman, but also bringing together a bunch of different interesting folks from interesting companies from across the API space to talk about the API lifecycle, governance, and other good stuff with me. And today I have Tim Zaitsev of Ridgeline. Ridgeline’s a privately funded fintech startup, and Tim does engineering and architecture over there, and he’s come to join us today to talk everything from GraphQL to just quality of APIs and a lot of other good stuff. Welcome, Tim.

Pleasure to be here, thanks so much, Kin.

Yeah, thanks for coming. So let’s, I always like to start with the basics: what does Ridgeline do?

Yeah, thanks again for this and putting this on, this is an awesome experience for all of us working in the API space. Ridgeline’s an industry cloud platform for investment management. It was founded in 2017 by Dave Duffield, and you may know of Dave as the co-founder of both PeopleSoft and Workday. As a visionary tech entrepreneur, Dave sets up these enterprises to bring innovation and human connectivity, and this time around Dave is working to bring a clean sheet of paper to financial technology and bring the best in class APIs, the most brilliant people in the industry together, to create a secure and agile financial technology platform.

What role does APIs play in doing that?

APIs, this is a great question, because what role do APIs play in our world? In financial technology there’s this behemoth of a space, it’s very segmented, it has such specific technical needs per segment, and where Ridgeline sees the opportunity and where Dave has targeted is the ability to connect these segments together. And today you ask for an export and you might get a CSV sometime later put through some kind of SFTP bucket. APIs provide the access to the data that really isn’t in the industry today.

So why did you, before we dive into, I want to dive into the notions of SFTP and CSV and stuff like that, but before we do, what do you do at Ridgeline, what’s your role, and what brought you to the company?

Yeah, that’s a great question. My role here is technology architecture and really API stewardship, hence the idea here is that we have a team on the cloud engineering side of things that look at how we can expose and provide better guidance and better guardrails and support to the rest of the engineers at Ridgeline. And so we started with this clean sheet of paper, and we said, what are the best API strategies out there today, what companies can we learn from enterprise-wise, and we started to build up a platform that allows product engineers, platform engineers, to build, you know, whatever their idea is to be able to build, we want to give them that platform to give the velocity and those safety nets to know that they’re building safely and securely within the platform.

So what’s so unique? I mean, there’s quite a few fintech APIs out there, what makes what Ridgeline is doing so unique and differentiates you from the rest of the herd?

We’re the first, by no means the first born in the cloud company, but the first fintech company that started with and partnered with Amazon to be born on the cloud. We lean really heavily into serverless, we lean really heavily into security first, so we’ve completed our security analyses, we have SOC 2, we continue to invest heavily into the security space, and the whole time everything is governed by this API concept.

So talk to me about APIs. One of the things that fascinates me about not just the fintech, I see this in other legacy industries, but fintech primarily, you mentioned a CSV file uploaded to an SFTP bucket, that’s essentially an API. I’ve gone into financial companies that were like, we have APIs, and they call that an API. So what sort of technologies, I mean you mentioned the cloud, what other technologies are you, I’m assuming you’re using RESTful APIs, are you guys using GraphQL, what else are you using?

Absolutely, we built from the ground up a connected graph within Ridgeline, and you’re right, SFTP is still quite a nice way to distribute data to and from individual buckets, but the setup and the governance of these things becomes really complicated when you do it at scale. So how we connect many different products that are built within Ridgeline for this space, and how we provide an API to each one that is consistent across each of those products, is a GraphQL API. And so our engineers work in GraphQL, they’re able to ask questions of the graph between multiple different products to provide solutions to our customers, and we don’t stop there. On top of that we put these contracted shapes, internally Ridgeline we call those mappings, and those mappings guarantee that if a shape is mapped it won’t break in the future. The graph, as you know, mutates, and as engineers add to the graph, they also want to subtract from that graph, and what happens when you have a really wide graph is that people will take something out of it or mutate some type and end up rippling these changes through, and customers may be impacted down the line.

So you really, I mean, one of my questions was going to be, why is this better or different than the FTP that’s been done for years and it works, why should people switch to Ridgeline and think about this new API driven world? And it’s going to be scale, because FTP locations, I mean you could scale them, but they’re individual silos. And what I heard you say is it’s scale plus you’re connecting the dots, you have this graph across all of them that exists and you can ask the questions that you need across these buckets, not just within a single bucket, within a single domain. And so, in the RESTful world, at scale within enterprises, some of the friction organizations encounter is they’re having to approach it using domain-driven design, they’re having to start defining these different areas. But it sounds like, and I haven’t heard much conversation about this, you’re approaching the same scale issues already in GraphQL world, and you’re getting more organized about how you make the graph available, but how you carve it up into meaningful buckets.

That’s exactly it. At the end of the day, the graph has infinite power to be able to answer questions about the financial space. If I need a report today, or if I need access to my data in the current financial technology space, I have to go and ask for it, I have to ask someone to collate it and prepare it, and that might be some time. Ridgeline’s approach is the data is there, and we want you to have access to your data, because you know what you’re working on, you know the space, you have clients, you have customers, and you’re advising and you’re providing value, and the Ridgeline investment platform is there to take away the operational overhead. And the graph is a really elegant way for us to continuously add to it and be able to be very agile in how we release new products and new features while ensuring that the rest is stable and safe.

Yeah, I mean that’s been one of the big sales of GraphQL. I talk to a lot of folks who are rest versus GraphQL, GraphQL versus rest, and the big argument for GraphQL is, get out of my way with API design, I just want access to the entire graph, let me query what I need. But once that scales to a certain size, and for people who are new to that graph, they may not understand what questions they need to ask, where they need to query, and then just managing that volume of data. So y’all have started to approach how, you know, domain-driven design and just much more meaningful taking care of a lot of this work that’s needed to help make it more accessible and organized to groups, so that they can stick with what they do best and asking the right questions.

That’s exactly it. At the end of the day, one of Dave’s core philosophies is the employees should be having fun in the work that they’re doing, and it is quite a lot of fun to be able to, like you said, invent and create and be artistic with how I want to design APIs. And if I expose a new API, or a new part of the graph where I append to it, and then we work with the product teams and we create something that’s valuable, it’s just a subset of that graph, well, from then on I’ve had a good time, and we’ve created product.

Yeah, it seems like it’s the best of both worlds to me, and you’re able to scale. And now, what about reliability across this graph, and being able to make sure that if I’m stuck doing what I’m doing on a daily basis, I have to be able to depend on this. So how do you guys approach reliability when it comes to GraphQL APIs?

Reliability was one of the first things that we identified, maybe the second. The first one was kind of a fragmentation within the company, everyone was running their own kind of graph, and you’d have name conflicts and duplication, so that’s probably the first step in reliability. And so now we have set up systems that guarantee that any change to the graph is a safe addition, meaning that if I have a namespace anywhere within Ridgeline, that namespace doesn’t conflict with any other part, any other type, any other name. That was the first step that we built, and we saw stability across the board increase, that was really inspiring. And we took it one step further: if I’ve created a contract for any part of that graph, and I want to make a change to the graph, every one of the contracts that exist today are validated against my change. This is all before I’m making it, before I’m committing that change, so developers know as they open up that pull request and they get instantaneous feedback of, this is going to conflict, this will cause a breaking change, this will cause an impact to the customer, and so that change doesn’t actually make it in.

And they don’t have to be aware of those customers, like they don’t have to know that that person’s using it or anything, this is just a part of their day-to-day kind of DevOps approach to what they do.

Exactly, and we get to the point of, I want to deprecate an API because we’ve versioned it, you know, this contract, there are now multiple that reference various shapes, but I would like to get rid of this one because it’s overhead and I don’t want to maintain all of them. What we’ve done is we’ve been able to deterministically prove in which environment, under which customer, is that contract being used, and when was the last time it was used, and we give that access to the developer, and the developer says, well, it’s currently used by these three customers, they work with their management, with the product teams, and we help those customers migrate off, but we’re never going to commit something that breaks a customer intention.

Yeah, what you really seem to be bringing to the table is everything that’s being delivered along with rest. You know, we have API management, you’re using the word contracts, which I don’t hear much in GraphQL realm, but you’re bringing the benefits of these business contracts, and the shape of those contracts from a schema perspective, and then the change that exists across that. But then you’re marrying that with the wide openness of the graph and the ability of the graph to ask all the questions, there’s no API design getting in the way or any of that. But it’s still, you’re paying attention to the business of it, and this is very much what API management has injected over the last decade. And so you guys are really bringing the management layer and a change management layer on top of the graph.

To make it much more reliable, and to be able to do this not just for one product, not for just a small portion of a graph, but a graph that’s in the tens of thousands of lines, and to be able to continuously add. This is the thing that makes the developers want to continue and makes the product team say, hey, what if, and that’s where we get that velocity, that’s where we get the innovation that comes with being able to do this at scale.

So what does observability look like at this layer? How do I see these shapes and see these contracts and see what’s happening?

That was the observability piece, both from, I think you mentioned it earlier, how do I learn about a graph, how do I know where and what and how. Ridgeline has done it in such a way that that one contract becomes both the documentation and the safety and the security for anyone consuming the API, and that’s one part of it, from observability of how do I use it. And then internally, in terms of managing it and seeing statuses and errors and things like that, the inputs to the system, the responses, the timings, all of that, we have metrics that we get to be able to see what is the p95 of any API, and if it exceeds a certain range, or if there’s a standard deviation or anything like that that occurs, we can actually catch that well and truly before we release that into production, because all the way through there are systems observing the changes to the graph, there are systems observing the testing that’s going on at the API levels.

And that’s in the context of the contract, and so it’s testing, it’s making observability what matters most to those users and to the business from a product perspective.

That’s exactly right. If I have a single transaction in my system and we have an API called fetch transaction, and its response time is 100 milliseconds, when I have 10,000 transactions in the system, that API should still respond in that exact same amount of time. But that becomes really difficult as you add APIs, unless you have those systems in place to provide the visibility, the observability, into this API.

Well, and across the long tail of that, the common queries, the common contracts, but then across even the edge cases and the ones that people still need but might not be able to do, so ensure performance for the primary usage, but also the long tail as well, making sure everyone’s kept happy.

I checked this morning, we have over 700 contracts that we’ve published. These are the documentation, fully ready, available, in use APIs by our customers, and it’s very hard, unless you have a developer dedicated to an API for the rest of the life cycle of the API, to guarantee it without that observability. And so the more you can bake in upfront, the more, and we use the term guardrails, but really the more visibility or observability you can put into the system, the better the customer’s experience ends up being.

And so I mean, API design or RESTful API design really captures how you describe these shapes and contracts, but those are versioned, and depending on the velocity of your team and your organization, you could be supporting that for a while, almost to the point where these contracts become a liability instead of an asset after a while. And so you really bring in, like, this six month, this Q3 going into Q4, it could be one contract, and by Q1 2022, everyone could be moving forward on, that contract could be iterated into having new properties and new aspects and new consumers, and then people are moving forward with that, and developers can see that and stay in that moment and respond to that without the overhead of design and having to maintain that. And then if there’s aspects of that that become irrelevant with these new contracts, it sounds like those can be cleaned up and go away.

And that’s exactly it. Versioning in the RESTful space, you know, slash v1, slash v2, you can choose very cleanly what to do. Where the innovation comes into it is, what if there was only ever one version of the endpoint, the graph, and underneath, every API was unique in a way that if I’m using it, it’s going to be supported, and as I need new features, as I need new functionality, as the product evolves, as we listen to the customers, we create new technology and new APIs, they can start to uptake them without affecting any other customer. And I think that’s where we’re currently at at Ridgeline, and that’s, you know, the thing that keeps me up at night is, how do we continue to evolve this in a way that makes sense to the customer without making it too difficult or too much overhead for them to uptake?

Yeah, and that’s, I mean, accommodate a wide group, because people in the financial space aren’t always the fastest moving, but there’s some that are very fast-moving, and if it’s there they’re going to embrace it and go with it. And you mentioned versioning, that’s how this kind of shapes the space. Some people prefer to call it, you know, there is no versioning, that concept shouldn’t exist, and if you talk to folks like at Netflix and others, they really embrace this, where you’ve got, there’s always one version that you’ve got to support, and you’ve got to move forward, but it’s got to support the long tail, people who don’t move fast, but also the innovators and the rapidly changing. Because they have televisions where the catalog’s baked into the firmware of the hardware, and it’s not going to evolve, but then they have this rapidly changing catalog and viewership and user base, iPads, devices, that are fast moving at the front end of that. And so it sounds like your graph will address that, kind of a financial market perspective, it’ll deal with the slow end, but it’s gonna keep up and actually fuel or drive or be the vehicle for the front end growth.

It’s the graph, and like the service mesh, the API itself, if I don’t want to necessarily build onto the graph, or if I don’t want to only do what we currently have, it supports that. And I think we’ve seen in the industry a lot of people trying to plug in things that don’t necessarily fit into the graph in a GraphQL-like way, and what Ridgeline’s philosophy and the technology here is, let’s make it work for the customer first, let’s make a good experience, and let’s make sure that it’s a consistent feel across every form of the technology under the hood. Because the customer ultimately doesn’t care if it’s a graph or if it’s rest or if it’s PostgreSQL, NoSQL, or anything like that, they just want the product to work and they want access to their data, and they want it to perform. I think we keep that in mind, that’s why it’s more of an API stewardship program, rather than, you know, we are strong about how, let’s find a way to get it to work, let’s do it with all of the constraints with the security in mind, because security matters more than anything when we’re dealing with customer data and especially financial data.

Yeah, the Netflix, they’re no version, and they call them experience APIs, it’s just purely about how they’re experienced and what the experience is, putting them to work. And it’s fascinating how much we all get hung up on GraphQL versus rest versus all these others, and as you said, most people just don’t care, and we really probably as technology folks shouldn’t be arguing over a lot of these details, because it’s just a matter of how it works. So, I know you’re in the financial space, so I have to ask, what’s the role of regulation in all of this? Because that’s another friction area that’s kind of out of some of our control, and no amount of great technology solves that one or makes it go away. What’s the role of regulation and what Ridgeline does?

Regulation, as you said, it feels like friction, we don’t look at it in that way. There are requirements, but it’s really an opportunity to provide and look at the experience in a way that is safe. It sets up these boundaries, just like when we look at Amazon, we look at serverless first, because it constrains you in a way that you can do the right thing. And then what we ask is, how can we do it in a performant way, how can we ensure that we have the audit trails and provide the access, rather than try to in any way fight the regulation or anything like that. We want to really be partners to the regulation, and it’s there for a reason, because someone has gotten hurt or someone has made a mistake that could have been avoided. I think at Ridgeline the beauty of it is we lean into it, and from very early on, chief security and compliance officer, compliance team, and as we launch the customers we get quotes like, we’ve been in the industry for over 20 years, and the energy that the Ridgeline team has brought to the process makes us excited. This is in that same space with regulation, and so I think we’re doing it right. And another quote could be something like, we’ve looked at so many vendors, nobody’s doing what you’re doing. And because we’re not trying to get away from any of it, we’re just leaning into it, and as Jack Lynch said, we’re taking the long view, it lets us build in the right way with regulation in mind.

And how would you say APIs are helping you deal with that? Because it really feels like that’s a significant portion of why you don’t see regulation as friction and as a negative thing, you see it as a positive.

APIs are the only way to interact with Ridgeline. There’s no back door, there’s no, internally if you want to do something, it has to be through the same API that someone calling Ridgeline would do. And so if the only way to do anything with Ridgeline is through an API, then the regulation is supported, because we have that audit trail, we have that support, we have the ability to prove what happened at the time.

So the APIs aren’t just the traditional story of why you do APIs, is, oh, you’re building a website, you’re starting to get your content and data from multiple sources, and your websites become these web applications, and then you’ve got to do mobile applications and then you got all these channels, so you’ve got to do APIs after the fact. And then in that case, when the regulators come calling, oh, well now you’ve got to design something and put something out there. But you, Ridgeline, your approach is just API first, it’s all just an API, and it doesn’t matter whether it’s a Ridgeline customer asking, it doesn’t matter if it’s an internal Ridgeline team querying, looking for something, it doesn’t matter if it’s auditors or regulators, they ask questions of the graph through the API, it’s just another user of the API.

And if we can provide that securely, safely, if we can guarantee the access, then we can partner with the companies and organizations that run on Amazon, and maybe we can make the industry easier to work with, and we can be leaders in this space where people want the regulation and people want that support because of the way we’ve done it.

When you’re able to answer the questions quicker right away, because the graph’s there, you just have to start fine-tuning and optimizing the contracts that are going to be most meaningful to the auditors and people coming in wanting to ask questions, and anybody industry-wide that’s going to want to partner with Ridgeline to be able to ask questions. Anything at the industry level just becomes another set of contracts.

Yeah, that’s exactly it, and we’re at 700 today. As we continue down the road, where were we a year ago, in the hundreds of APIs, and as this continues to expand, it’s just more contracts. And because the systems are there, because the safety net is there to be able to build, once it’s built, it’s supported from then on until we make an active conscious decision to deprecate it or move it out of the support window, then we have all of the observability, we have all of the contracts, everything is there.

And it sounds like regulators could actually come to you with questions, not just the same old questions. This approach, this graph, can really help them keep up and manage change, because that’s all built in, the reliability, the change, all of this is built into the contract process and the evolution on the layer on top of the graph, and so they can start forming what are the next wave of questions they need to ask to be able to understand, you know, what’s going on with a specific client or a specific dimension of the financial space.

That’s huge, and I think that’s where we’ve brought together the best minds of the financial space, we’ve brought together the best minds of the technology space, and it’s an opportunity for us to continue to push forward and integrate with and interact with the regulators, with the different companies, with the different segments. And we’re starting off small, we’re starting off very specifically, and as we continue to do that, we will then grow past the buy side institutional asset management into other customer segments using the exact same technology, but we will have built it, and so every next segment is faster.

Well, and regulation and policy gets laid down, it’s pretty slow. I’ve been working in the US federal government for about a decade now, but API regulations are coming, they’re coming for specific industries, they’re already here for healthcare, and I know they’re working on payments rate policy and regulation right now. And so it sounds like we just need to get to the place where APIs are just the default, everyone’s doing all of the operators in the financial sector are just operating by default through APIs, it’s not a question, we’re already there, we’re not asking, do we need APIs, it’s how do we do them well. But the policy, I mean, do you support the government defining policy at this level, or do you think it should be the financial companies themselves saying, hey, this actually benefits us having these access layers, we can move fast, we can be more competitive, we’re agile, nimble, and it satisfies our regulatory? Do you think it’s government, industry, private led, or a combo of both, would you say?

I would definitely say it’s a combo of both, it’s a collaboration. And again, we’re dealing with investments, we’re dealing with retirement and individual futures. There’s the argument that we can deregulate it, I think we can leave off the table, but the idea that if we provide the access and the support and the confidence, then policy should support, and maybe there’s more policy from a company than there is from a government, that I leave to, you know, the discussions, but at least being a collaboration and at least being able to contribute to safety and security of an individual. It’s a joke, but you know, why do they call money “dough”? Because we all need it, and everyone has to work through it, and we all have to kind of support it.

Yeah, yeah, it’s a critical aspect of our life, and there’s a balance between markets and regulators that’s there to help kind of keep that balance. And I can definitely, I mean, I see the potential of APIs in helping define this policy, but our approach to APIs, the way that you’re defining contracts, the way you guys approach reliability and observability, this is how policy should work and this is how policy should evolve. I can see a natural synergy between your contract approach within the graph working hand in hand with the policy approach, and how we iterate and evolve and then deprecate policy, you know, government policies, things that aren’t needed, well, that was needed in the markets in last decade, but we don’t need that in this decade. And so how can we take a contract-based API approach to defining how government regulators define policy and iterate and move it forward?

Yeah, I think that’s exactly, well said. The APIs will be there to support the need, and maybe it’s because it takes so much effort and it’s so hard to make a change in the space. If we make it easier, if we provide, hey, can we have this view of this data, okay, it’s done, or it’s already available to you, then the whole process can feel lighter and easier, and we can bring joy to everyone in this space.

Yeah, and let everyone do what they do best. So let’s move into some of the more forward leaning aspects of the space. You mentioned serverless, you touched lightly on how the constraints of serverless is something you’ve embraced and is shaping how you do business. Why do you use serverless, what’s the big impact?

Serverless, and even more so the cloud, Ridgeline being born on the cloud and originally starting with a blank sheet, means that we don’t have to think about the server, we don’t have to think about the individual piece of machine that is running that and the access controls to that machine. Serverless takes it one step forward. Our product development teams, our platform teams, can implement technology directly by writing code, that code gets deployed and is then just, it plugs right into the graph. If we look at DevOps, DevOps is the idea that I can write code that affects the infrastructure or the product. At the end of the day, our engineers are writing code, they’re not worrying about the performance over a machine, or if they’re going to have enough scale, or if it’s going to just work when the system scales, they’re able to think about, and the same thing that Ridgeline is doing for the customers, the cloud is doing for Ridgeline. We can do what we know, we can create that platform for our customers.

And in the DevOps reality, I don’t have to be an identity and access management or security expert, there’s policies in place that just get layered on and ensure my code’s only accessing what it needs to access.

That’s exactly right, and we layer on more and more of that as we go, and that is a good thing. The same way that security is guaranteeing that this code can only access this row of data, because the constraints that apply from the industry down to any individual function, AWS and Amazon have done a really good job of giving us those tools, and we work really hand in hand with them. And so Ridgeline is all about the cloud, it is all about the serverless experience, because all those controls are in place, and we get to just enhance them as needed.

Yeah, that’s, I mean, you just connected the dots between the government regulatory policy and the local layer identity and access policy, which is relevant. I mean, I’ve sat in on energy industry OAuth scope meetings, two, three-day meetings where they hammer out OAuth scope when you install solar panels on your roof and it connects to the grid, what data does your electric provider have to share with that installer, have to share with the state, with the regulator, so that OAuth policy governs that. And so what you connected is, how does policy evolve and iterate in the financial space at the government levels, but then how do you connect the dots, trickle down to what data is accessible, how do your logs work, and then a developer in a DevOps reality can just do what they do best within that, and they can trust that the policies are being applied, that they’re not gonna create some security vulnerability or make some major regulatory gaffe that’s gonna cost them their career. So yeah, that’s pretty powerful.

There’s, for me personally, working with compliance, working with security, and making sure that the protection is there, that developer, like you said, doesn’t have to think about, of course we encourage them to and all the training is there so that we ask the right questions, but the platform is there, and if you follow the guidelines that we’ve set out, then it’s secure by default, and all of the availability, all of the permissions are passed down API first to a secure platform, and iterations and change, adding more isn’t a slow process because we have this framework that allows us to know, does it plug in safely or do we need more.

Yeah, and then I’m neck deep in the Gartner MQ Magic Quadrant released today and yesterday, so this is where my head’s at, and one of the things on the Gartner hype cycle is event driven. And I don’t consider just the hype cycle, I mean events for me, event driven approaches have been around for the last 20 years, nothing new, but for the last four or five years it’s a sign of maturity when RESTful API providers hit a point where they have such a high volume, high usage, they need to start, they can’t just stay in tune with the individual requests, they’ve got to go from synchronous to asynchronous, and then they need to tune into the events that are happening across their operation. Just let me pay attention to the events that matter to me. Is that a reality across the Ridgeline approach?

It is, it very much is. Starting with a blank sheet of paper lets us start there as well, and internally it’s fully event driven. You can make synchronous calls as you need to, but also the eventual consistency piece, you can connect these different microservices together, and then for anyone wanting to subscribe to the data, our workflow engines are probably the best example of that today, where I want to do a complex operation that the financial trader will know how to do, and we’ll let them set up this workflow, it’s a very powerful engine, and as that workflow progresses, different pieces of information will come in to our front end. There’s nothing to say that anyone interacting with the APIs won’t get that exact same thing, setting up an event-driven connection. And the opposite is also true, any connectivity to Ridgeline can be done in an event-driven way, where external changes and external feeds and data don’t just have to go in through a specific bucket, but we can get that streamed in to us in a consistent way.

So yeah, so event driven is not just for your consumers, it’s for those that you’re consuming from, so you’re able to keep things real time, keep things asynchronous, and as meaningful, and keep, I mean, financial space, things are moving faster, there’s a lot of data, so I can see that being pretty critical piece. So, I don’t think I’ve asked this question of any of my guests, but the way that you all approach your contracts and embrace change in various regulation, I’m going to ask, is the concept of breaking changes good or bad? And I’ve been thinking about this question, and I think I was on the stance that we should never break the experience for a user, and I changed it just a little bit, I think, yesterday.

We should never have a breaking change unless the change that exists is in a beneficial way, meaning if there is a security risk, or if there is an impact to a policy, and that breaking change prevents that from happening. I think we’ve seen that recently with some of the security vulnerabilities coming out, where all of a sudden something that is stable now breaks, and that’s better than the alternative. So most of the time breaking changes are bad, but there are places for them.

Yeah, I think it just comes down to the business intent, is it to move things forward, is there communication around it, is there bad business value behind it. And they can be good, it’s just most people don’t approach them in any sort of organized way, and they just happen, there’s not a known known, it just happens behind the scenes or on someone else’s watch and it becomes a problem. The financial space, it’s one of the top industries in the world, it’s one of the top industries we talk about in API space. What can other sectors learn from what Ridgeline has learned and is doing in the financial space, especially in the concept of breaking changes?

The communication with the consumers of the API and the access to data really make the difference between trust with the API and the product, and fear. And the quotes and the interactions with our customers and the ability to move quickly is all about that constant communication, go through an API perspective, or announcing two years from now that a change will occur and helping that customer make it through to migrate off, because it takes time to spin up integration and implementation teams, it takes time to spin up infrastructure on the other end. And so the recommendation and what we’ve learned is kind of the same philosophy that Dave has always had, that the employees and the customers matter, and continue to interact and continue to communicate, make it a fun experience.

Yeah, that sums up well my view of APIs and what attracted me to this world. In 2008 I was working at SAP, and I noticed what RESTful APIs were doing, the mobile just hit, the cloud just hit, and I was a database guy, so I had been running large-scale databases for 20 years, and databases are very much a closed-door power center of many organizations, and APIs poked holes in that and opened up and started making you more accountable and more accessible to your consumers and users. It was less of a vault that you just kind of hid in, and I really saw that, and that feedback loop that exists around APIs I think is the most critical aspect. And it’s definitely something I think folks need to consider in any industry, and I work with a lot of industries where they’re like, well, we just want to hear what others in our industry are doing, and I’m like, well, you should think about what Amazon’s doing, what Twitter, you should learn from everybody, because there’s lessons across the board. And that feedback loop, I would say it’s good to hear you say that, because it’s definitely one of the top aspects of why folks should do APIs and do it in this, you don’t have to have a public API in the sense that everyone’s got access to, but you should do it in a very public way so that those who need access can get access in a secure but fast and effective way.

I’d agree with that completely. The future is bright. The more data access we have, and knowing that the security is there and the protections are there to be able to work in the API space, and have it spread to the rest of the industries around financial technology, and even through financial technology, it’s a very exciting future for us.

Yeah, well, we’re coming up on our time. I tend to want to move off of the tech and just the APIs and leave on a more personal note. What do you do when you’re not doing APIs, what interests you?

We have the real benefit of having our headquarters in Lake Tahoe, in Incline Village, and my family and I moved up here two and a half years ago, and my wife and I got married in South Lake Tahoe. And so being able to raise my children, two children, Allegra and Caspian, four and two, there, they’re why I do all of this, I get to create a brighter world and work with amazing people here in Lake Tahoe. And we have an office in Reno and an office in New York, and as we spread out Ridgeline, you know, one of the top US startups, LinkedIn has just said that, and so it’s really exciting to be able to ride my bike with my daughter and go skiing with my son, it’s so nice.

Yeah, you’re in some beautiful country up there. I’m down in Oakland in the Bay Area, so I’m one of those people who come up on the weekends and hang out and do the snowboarding and skiing and other stuff.

So it used to be us, we were in the Bay Area for a lot of years, and it’s fantastic to be able to have those connections to the Bay Area, but then just to be able to settle and really enjoy the work that we’re doing with the people around us, and really contribute to the community and give back to the area.

Yeah, well, I’m definitely envious of your reality up there, because I would say I’m on the other end, my kids are grown now, so we’re kind of enjoying the Bay Area, but coming up there on a regular basis is definitely in the cards, so maybe I’ll come up and we can…

I’d love that, I would love that.

Well, I appreciate your time today, this has been great, very interesting, I love your view of GraphQL, the graph. It was probably one of the friendliest, more sophisticated views of just APIs, and not with all the dogma that usually comes with rest versus GraphQL, so I appreciate you taking me through this today, appreciate the time, and it’s really been a pleasure.

Alrighty, Tim, well enjoy the rest of your day, and we’ll be in touch.