Ridgeline's Biggest Tech Bets

I get some crazy looks when talking to prospective engineering candidates about what Ridgeline is trying to achieve. After all, we’re attempting to replace a suite of decades old, entrenched, back-office enterprise applications in the asset management market. On a modern, unified platform. As a startup. HQ’d in Tahoe. Who can blame them for being skeptical? Technology is a fundamental part of our strategy for meeting these challenges. This post will outline some of our biggest tech bets — the 90 percent of the iceberg you can’t see.

Ridgeline sees an opportunity to significantly impact how an entire industry runs their businesses. This audacity comes straight from our founder and CEO, Dave Duffield, who has seen this same story play out before. Dave has previously been at the helm of companies that fundamentally changed the enterprise software landscape. His successes have been most famous for three things: happy customers, even happier employees, and killer technology.

Ridgeline is following the same playbook. As the company’s chief technology architect, I’m most excited about the opportunity to design this enterprise platform from a clean sheet of paper — solving some incredibly complex engineering challenges with some really cool tech, and making key decisions about security, configurability, reporting, data, UX, and so on — purely for the value we can provide to customers. Here is a quick look at what we’re cooking up.

Embracing Cloud-Native with Serverless Technology

The major cloud providers (Amazon Web Services, Google Cloud Platform, Microsoft Azure, and so on) have significantly impacted how technology companies are built today. These leaders have truly commoditized the provisioning and management of infrastructure needed to support most tech companies.

We’re seeing a lot of enterprises (both well-staffed and well-funded) decide that managing their own infrastructure is not worth the cost and headache and instead opting to move to the public cloud. Lucky for us, Ridgeline was born in the new “cloud-native” era. Not only have we avoided the need to replatform or migrate to a cloud provider, but we can actually design our architecture tailored to our cloud provider of choice, AWS.

Like many other cloud providers, AWS has countless whitepapers and online resources that guide teams like ours on how best to use their managed resources to maximize availability, scalability, security, and reliability while minimizing cost. We’ve been able to stand up moderately complex applications with a few lines of infrastructure code without compromising the robustness of our overall system.

We’ve taken our cloud strategy one step further with our adoption of serverless technology. The “serverless technology” trend often gets mischaracterized as a particular cloud’s managed Functions as a Service (FaaS) offering, like AWS’s Lambda or GCP’s Google Cloud Functions products. However, serverless encompasses way more than the compute layer. Serverless is an umbrella term for cloud-provided services that meet the following criteria:

• No managed servers
• Dynamic scalability
• High availability
• No idle capacity cost

When opting for “serverless” cloud products, we delegate the responsibility of operating our infrastructure to AWS, freeing us up to focus on what we’re good at — building features and functions for our customers. Amazon has the resources to focus on making our infrastructure work for us, and it is our job to make sure we put the pieces together to build amazing products for asset management companies.

A Modern Data Strategy

Historically, most architectures were limited to a single database paradigm, often relying on some beefed-up relational database to solve all of the business’ data and reporting needs. However, we know that enterprises are immensely complicated, and their data models are even more so. Not everything naturally fits neatly into a row/column store, but that’s what we often had to work with. We’ve become pretty skilled at writing nested SQL queries. Oh, and good luck trying to change your model after a few years — you’ll need a new set of tables for that.

More recently, key technical innovations have empowered engineers to rethink how data should be treated. Lower storage costs, faster networks, and database virtualization have enabled architects to outgrow the single database paradigm, opting for more distributed data architectures. Cloud providers have made this style even more appealing. AWS provides a vast array of managed databases tailored for different datasets: row/column-based, key/value-based, time series-based, graph-based, and even one for emerging blockchain-based use cases. This is a game changer for many reasons. But most importantly, it enables us to have greater control and flexibility around how we model data. No longer are we forced to solve every data problem with the same tool.

Equally as important as how we store data is how we expose it to our customers. We obsess over more and more ways we can make data conveniently available to our users. As an example, all data that is shown in tables in our UI can be exported as a .csv or .xls file. For more advanced data needs, we’ve been building GraphQL-based APIs to enable firms to extend our application and integrate it into their existing stack. We also plan to expose the event-driven nature of our architecture through webhooks to enable push-based external integration architectures.

Microservice Team Culture

Ridgeline’s team-building philosophy is that smaller teams with a greater sense of ownership are the most effective. Our organization will continuously expand to keep up with the ever-growing feature list we need to deliver to the market. Simultaneously, our “squads” will continuously divide to keep them effective.

For a squad to be viable, it requires a certain set of roles to function. In addition to staffing each squad with typical roles (product manager, technical lead, quality assurance engineer), we’ve embraced the DevSecOps movement. Each squad will have an operations- and security-focused engineer that will liaise with a cross-functional group to share ideas and best practices and to bring back new findings to their home squads. This gives the entire team shared foundations for the product that they deliver.

One of the most exciting things about this organizational style is how it enables engineers to take on responsibility. Smaller teams means every engineer has the potential to make a big impact. Our founder likes to say, “hire the best people and get out of their way”. To ensure they feel comfortable making decisions, technical leaders make sure we have the proper guardrails in place to learn and experiment safely. For example, we lean heavily on automated static analysis tools to check for coding anti-patterns, security vulnerabilities, and obvious bugs. We complement those automated checks with a two-step code review process that should catch more nuanced issues before changes hit the master codeline.

Continuous Learning

Ridgeline strives to be a leading global provider of investment management enterprise applications. We also hope to provide enterprise technology thought leadership based on what we’ve learned from other great technology companies — whether through success or, more often, failure. As we tell our employees, we will not always get it right on our first try, and that’s okay. What’s more important is that we learn from the past and push to be better every day.

I will continue to write about how we’re progressing on our journey and welcome your own stories, questions, and lessons learned. My next post will outline our strategy for internal application services and how they enable our engineers to build, test, and integrate at a rapid pace. It’s an exciting time to build an enterprise cloud company. And we’re just getting started.