What Enterprise Architecture Looks Like in a Fast-Paced Tech Company

My career at Capital One started in 2002 when I helped create our very first Enterprise Architecture (EA) organization. Over the years, EA has played a key role in leading our technology revolution at Capital One. I left my EA role for a few years to lead an initiative to create Tech College—an internal program to invest in our associates by helping them upskill and reskill as we introduced new technologies.

After building Tech College, I was asked to come back to our Technology organization to revamp EA. I knew this was not going to be easy, but times had changed and we needed an overhaul of our EA function. Enterprise Architecture as a function varies from company to company. There are many definitions offered by various publications, consulting companies, and research companies. After quickly scanning the industry and interviewing our CIOs and Divisional leaders, myself and John Andrukonis, Enterprise Chief Architect , came up with an action plan to build the new EA function from the ground up, and without external influence.

Our first step was to change our brand narrative. We called our new organization Architecture and Technology Advancement, and formed what we now call “Capital One Architecture.” We wanted the new name to speak to the fact that we are a single architecture body regardless of where we report to in the organization.

But we didn’t stop there.  We made many additional moves to prepare ourselves for the future:

• From many architecture titles to one “solution” - All our architects wear multiple hats and do whatever it takes to architect solutions and advance our technologies. We no longer distinguish between Business, Data, Application, Infrastructure, and Security architects. We are all solution architects at the end of the day.
• From governance to leadership - Architecture governance is a critical function to the success of our organization, but we don’t spend most of our efforts on traditional governance. Instead, we spend a lot of time reviewing and modernizing our architecture standards and building automation to monitor them. The automation of policy monitoring helps ensure compliance with our standards and allows us to better allocate our governance resources. This gives us the time to focus on the most impactful, cross-cutting initiatives—our “big rocks” as we call them. These are high priority architecture initiatives like cloud migration, data transformation, execution architecture (containerization) and holistic monitoring solutions.
• From multiple frameworks to the Grand Unifying Theory - We moved away from established architecture frameworks like TOGAF, FEAF, Zachman, etc., and use them now mainly as sounding boards. Instead, we implemented what we call a “Grand Unifying Theory” (GUT). Under this theory, all things at Capital One must work together to create a well-managed, efficient, and effective experience. This ensures that the hundreds of applications, developed by thousands of Capital One associates, on behalf of our millions of customers, are all well-integrated. This begins with our ability to convey our architecture and decisions in a consistent way through a Unified Domain Model (UDM). UDM is an evergreen model with shared capability domains that can be used by the entire enterprise. With GUT (our theoretical model) and UDM (our practical model) we are better able to communicate our work, explain how things come together, and also how they stay together.
• From buying EA tools to building intelligent solutions - So, what EA tools do we use? None. There are many great EA tools on the market today, and they have only gotten better over the years. In fact, in my 16-year career at Capital One, I implemented three such tools with great success. But my team’s approach has changed. We no longer consider EA tools a commodity, we see them as strategic solutions that help us reach our destination. Instead of vendors driving our architecture strategy, we leverage internal engineering know-how to build what we need, when we need it. We rely on a small delivery organization with handpicked engineers to build architecture intelligence solutions. And instead of “architecting” everything, we engage in what we call MVA (Minimum Viable Architecture) and JITA (Just In Time Architecture).
• From lukewarm reuse to becoming maniacal about common capabilities - Who doesn't like building new stuff? And what do you give an organization that has everything? And how do you change a culture that rewards cool, new stuff? This is where common capabilities come into the picture. We established a new framework to promote reuse by categorizing common capabilities in four areas: shared systems, shared components, shared platforms and shared code.

We also introduced four dispositions: required, preferred, available, and emerging. This helps teams know when to file an exception, as shown in the diagram below.

• We built a tool to promote reuse and inner-sourcing - And we didn’t stop there. We built an internal tool that discovers solutions already available.  If someone wanted to reinvent the wheel, they would know it already existed. We called this tool Discoverability. It searches multiple sources and brings results to our associates about our common capabilities, applications, APIs, patterns, streams, code, etc. Today, Discoverability promotes inner-sourcing and reuse at Capital One.

We've come a long way since forming Capital One Architecture, and even further from the early days of EA in 2002. I expect the transformation we’re undergoing to continue as we fine tune our practice, moving onto newly identified “big rocks” and evolving our architecture intelligence organization. I can tell you, this is an incredibly exciting time to be part of Capital One's architecture journey.