How DevOps is shaping Financial Services #3: The impact of technical debt

Financial Services interview #2

In this series of blog posts, we speak with database professionals from Financial Services organizations around the world to better understand how DevOps is shaping the sector. On the way, we dig into key current factors including the rise of technology upstarts in fintech and insurtech, the speed of digital transformation and the ever-increasing threat of cyberattacks.

In the third in the series, we speak with Josh Smith, DBA at Spokane Teachers Credit Union (STCU), the Inland Northwest’s largest and most successful credit union, serving more than 170,000 members at 21 branch locations, with $2.6 billion in assets.

Can you tell us a little about your background in the Finance sector?

I started my database career at STCU back in 2013, and now manage and maintain more than 20 servers, both physical and virtual, which are running upwards of 60 SQL Server instances from SQL Server 2005 to SQL Server 2012.

My passion for data doesn’t stop at work. I’m the Founder and President of the Inland Northwest Data Professionals Association, which is dedicated to providing resources, training and mentorship for seasoned, aspiring and accidental data professionals.

What do you think is the biggest challenge facing the sector at the moment?

In my role I primarily work with vendor solutions and products, so I don’t know that I necessarily have the insight to answer for the industry overall. But from my personal experience I’d say that it’s technical debt.

My vendor databases are uniformly terrible. I’ve got databases with issues that run the gamut from bad naming conventions to architectures that are unable to take advantage of improvements in SQL Server, because minimal attempts have been made to improve the database deficiencies. I have databases without primary keys, missing foreign keys or with tables or columns created outside of the ANSI standards. If, as a client, the usage of the database starts to degrade due to these defects, there is generally little recourse to improve performance beyond trying to solve it with hardware.

The Finance, Insurance, and Banking sectors have historically been slow in adopting new technologies and processes. What do you think has been the consequences of that, particularly in your role?

For me, it’s back to the technical debt, but more generally it’s how to bridge that gap between the old systems and something better. Whether it’s getting product architecture closer to current best design practices or building support products that have to plug into existing enterprise estates, it’s about finding ways that are both supportable and able to interoperate with older, less ideal systems. In fact, this should probably have been my answer to the previous question around the biggest challenge facing the whole industry.

Digital transformations have been at the top of many CTO to-do lists across all sectors. Is this something you’re seeing within the Finance sector as well?

I think the majority of finance organizations have some sort of initiative underway. How this is interpreted differs slightly from company to company, depending on what’s driving them. For some, it’s moving applications out of the local enterprise estate into a vendor-hosted environment. For others, it could be moving from local data centers into public clouds like Azure. It’s great that these organizations are driving digital movement as a result of responding to business or customer needs, but the term digital transformation does tend to cover a large spectrum of activity, so can sometimes be perceived as a buzzword.

Given the rise of cyberattacks across the sector in recent years, what would be your advice for someone tackling compliance and security in their database processes?

Review all data access methods, particularly those that exist outside the context of the applications themselves. Eliminate anything that is not needed, then ensure that all access is documented and occurs in a way that can be audited.

When granting access outside of normal channels (i.e., in applications), do so in a way that allows access in the most limited way possible, like granting access to distinct tables rather than read rights to an entire database.

It’s also a good idea to introduce processes for requesting access that create and retain records of themselves, including justification for access outside of normal channels. Ideally your data is already catalogued, so your data access and permissions can be reviewed, including what types of sensitive information a user can access. If you don’t have a data cataloging effort in place, continue to advocate for one until it’s started.

Next steps

If you’d like to find out more, read the first two posts in this series:

You might also be interested in the insights revealed in Where Financial Services businesses should focus their digital transformation efforts in 2023, and the selection of resources on our Finance page.