Enterprise architecture governance: A career in fintech

My journey to the cloud began many years ago, before the word “cloud” existed (at least in the technology context it does today). As a high school student, I wanted to be an engineer. Why? I had no idea. I was a strong math student and I was ambitious. I took courses in the now obsolete software language Fortran. My highly theoretical electrical and mechanical engineering studies at Swarthmore College confounded me to such a degree that I sought practical hands-on internships to help it make sense (a subsequent summer job pressing explosives that detonate automobile airbags was enough to convince me that mechanical engineering, in particular, wasn't the path for me). 

I eventually migrated to what I saw as the vastly more practical “economics and finance”. The next 23 years were spent at Fortune 20 companies, in rewarding roles ranging from managing banking and payment company risk to working as a federal financial regulator. 

Technology has always been present in the most efficient financial organizations—woven into the organization's fabric somehow. For example, mitigating operational risk and implementing process improvements, more often than not, involved working with engineering to automate workflows (automating cumbersome manual tasks using whatever tooling and developers I could rope into a project became my go-to “superpower”). 

Finance and technology are intertwined at their core—Capital One is a bank with technology in its DNA, so it is quite appropriate that my two professional passions are now combined in my full-time role managing enterprise architecture governance.

When making the move toward the technology industry, I took some time to consider what areas I found the most dynamic. I enjoy starting with the big picture—thus, enterprise architecture felt like the best fit. 

Enterprise  architecture is the practice of defining the “north star” or strategic direction for an organization's technology strategy—it involves balancing the introduction of new technical capabilities to the enterprise in a well-managed, risk-aware manner. More specifically, enterprise architecture governance creates standards that application architects, solutions architects, and developers utilize when developing new applications and new features.

How does or should the voluminous portfolio of software applications align with business strategy? Is the organization building the right applications in the right way? When purchasing third-party applications, how best to ensure they meet architecture standards? 

The objective is to provide visibility and structure where there might otherwise be a potential “spaghetti diagram” or confusion of platforms, applications, and components that comprise any organization. In many ways, architecture governance is the same job as any bank risk manager—it must provide transparency and traceability so that technological investments are based on known risks. I love this role because it is both strategic and practical—I have visibility into the entirety of Capital One’s technology strategy and application portfolio, making decisions daily that better enable us to achieve business goals efficiently.

Who are the “alphabet soup“ of financial regulators and what do they do? The SEC, OCC, FDIC, CFPB, FHFA, CFTC, NCUA, Treasury, and the Federal Reserve, to name a few, all have established priorities as they assess banks to ensure consumer protection of assets. These risk priorities have taken the form of ever-evolving frameworks. Acquiring a deep understanding of these regulatory frameworks and areas of risk focus is key to developing a successful enterprise architecture risk management program. How can we “architect for auditability”? What emerging risks are looming as operations continue to evolve in complexity and size as banks begin to leverage cloud capabilities fully?

Furthermore, each financial crisis brings new regulatory requirements—a continuous game of whack-a-mole in an attempt to protect customers and their money best. For example, the Sarbanes-Oxley Act  authored and enacted in response to major corporate financial scandals, had a massive impact on banking operations when it was established in 2002. The Dodd-Frank Wall Street Reform and Investor Protection Act was born in 2010 following the mortgage crisis. Thus, effectively managing enterprise architecture governance requires continuous monitoring and understanding of bank regulatory expectations and priorities—and building architecture solutions with risk and governance in mind.

*Considerations for enterprise architecture governance within financial institutions

With technology in general, and enterprise architecture in particular, learning the language is often half the battle—this is similar to the complexities of learning finance. There are an exponentially massive number of cloud solutions (e.g. database, storage, infrastructure) that must be considered by  enterprise architecture governance, let alone the nuances of software application development language and concepts. A clear understanding and communication of architecture’s roles and responsibilities goes far in terms of the ability to mitigate risk.

When requiring architects and developers to comply with architecture standards, one must make doing the right thing as easy as possible. Similarly to risk management, there is always the chance that risk efforts are seen as a “check the box” exercise. Enterprise architecture governance should not be seen as the “police”—enforcing standards that may not make sense given different use cases. Personally, I spend a significant amount of time partnering with architects and engineers reviewing architectural objectives and determining when exceptions may be required, when the standards themselves may need revision, or providing support and explanation around the “why” of architectural requirements.

I hope my learnings have shown that there are exciting opportunities for risk managers within the technology industry. As an increasing number of financial institutions move to the cloud and leverage their full potential, and as the “spaghetti diagram” of bank technology operations continues to grow in complexity and size, the need for people with finance and risk training to help drive technology governance has never been greater. We especially bring value to architecture teams (and data governance, cyber governance, machine learning governance and artificial intelligence governance) as the technology industry moves towards greater regulatory oversight and as the portfolio of software applications and platforms continues to grow. 

There are myriad future opportunities for enterprise architecture governance to utilize risk to help architects. I look forward to continuous learning and keeping an ear to the ground about trends in enterprise architecture (e.g. enabling modernization and ensuring reusability concurrent with development speed). At its best,  enterprise architecture governance can and should serve as a change-driving force across the organization.

If you enjoy learning about and establishing the future technology direction, a career in enterprise architecture governance may be for you.