This article is part of a continuing series on the evolving role of the chief data officer (CDO). In a previous installment, I examined how organizations establish the CDO function and navigate early stakeholder dynamics. Here, I go deeper into a specific case: how Zions Bancorporation built its data governance program from the ground up, what drove the decision to formalize the CDO role, and how the organization is using structured data management to address compliance requirements, improve data quality, and develop the customer intelligence capabilities that will define its competitive position.
This article originally appeared in the March/April 2017 issue of IT Pro, published by the IEEE Computer Society.
Zions Bancorporation traces its origins to Zions Savings Bank, established in 1873 in Salt Lake City during a period of significant economic turbulence in the United States. On its opening day, the institution attracted $6,000 in deposits -- roughly $130,000 in today's terms -- and went on to weather the Great Depression and multiple financial downturns over the following century. Through acquisitions in the 1990s and into the mid-2000s, the bank grew into a diversified institution with approximately $60 billion in assets.
That growth created a data management challenge common to organizations that expand through acquisition: each acquired entity brought its own systems, standards, and terminology. The resulting patchwork of independently operated platforms and inconsistent data definitions made enterprise-wide analysis difficult and increased the burden on teams responsible for regulatory reporting and capital planning.
The immediate catalyst for formalizing data governance was the Dodd-Frank Wall Street Reform and Consumer Protection Act, signed into law in 2010. For banks with assets exceeding $10 billion, the legislation required annual stress tests demonstrating sufficient capital reserves to sustain operations during periods of economic contraction. The Federal Reserve draws data extracts from these institutions and runs them through its own models. If the available capital is determined to be insufficient, the stress test is rejected and the bank must publicly resubmit a revised capital plan. The stakes for data accuracy are not abstract -- they are regulatory and reputational.
The corporate finance team at Zions began modeling these stress tests and quickly discovered how heavily the process depended on the quality and consistency of available data. Executive leadership recognized the growing demand and, with a number of large technology replacement projects already underway -- including a multiyear initiative to replace the core lending system -- concluded that a formal data governance program was needed to manage the organization's information assets more cohesively. A consulting engagement led to the recommendation to appoint a dedicated CDO.
The CDO role at Zions went to Brandon Thomas, an internal leader with a long tenure at the bank and a background that spanned business operations, analytics, and technology. He had led an analytics team and had working knowledge of SQL programming, but the more important qualification was his deep understanding of how the bank actually operated across its various lines of business and its organizational culture.
This points to something worth emphasizing about the CDO function generally. The role is fundamentally a business-oriented position, not a technology one. A CDO who approaches data governance primarily through an IT frame of reference will struggle to connect the work to outcomes that business leaders care about. Thomas's value was precisely that he could translate between the data domain and the business domain -- understanding what the organization needed and articulating data initiatives in terms that aligned with those needs.
At the time of his appointment, Zions had governance activities occurring at the departmental level but lacked a unified, enterprise-wide approach. Thomas was positioned to change that.
Rather than building governance as an IT-managed compliance function, Zions structured it around business ownership from the start. Ten subject areas were identified as the foundation of the governance framework, spanning finance, accounting, risk, customer relationships, and consumer and commercial lending. A senior representative from each area was appointed to serve on the data governance council.
These were not mid-level contributors. Council members included the head of human resources, the head of retail banking, the controller, and senior finance leadership. Their seniority mattered: it gave the program organizational credibility and ensured that data decisions were made with genuine authority. Each council member served as the de facto business owner of data within their subject area -- the representative voice articulating what the business needed from its information assets.
Council members in turn appointed data stewards responsible for the day-to-day management of data within their domains. Eight full-time stewards were named initially, each assigned to a specific subject area. These individuals were not appointed arbitrarily. They were already doing significant data management and curation work informally. The governance structure formalized and recognized what they had been doing, integrating their efforts into a unified framework and giving their work institutional standing.
Governance council meetings were held monthly in the early stages to build momentum. As the program matured, the cadence shifted to every six weeks, with most ongoing work handled at the stewardship level through informal channels -- instant messaging, phone calls, and direct coordination among the steward community. Strategic issues escalated to the council. Routine questions and data entry discrepancies were resolved by stewards without formal escalation.
Foundational governance work begins with a deceptively simple task: ensuring that everyone is using the same words to mean the same things. Zions developed terminology dictionaries with agreed-upon definitions and usage guidelines, addressing questions that seem straightforward until you try to answer them consistently across a large organization. How is a customer defined? At the household level, the business level, or the individual level? How are elements of financial statements classified? What constitutes a complete record versus an incomplete one?
These definitions vary across business units in ways that create significant problems when data from multiple sources must be combined for reporting, analysis, or regulatory submission. The bank started by standardizing the data elements used in regular regulatory reporting -- a logical entry point given the direct stakes involved -- with Thomas working alongside senior management to identify which elements most needed standardization.
Data sources were also categorized and documented with usage parameters covering privacy and security requirements, data provenance, ownership, downstream dependencies, and quality measures. Given the scope of this effort, the initial work was scoped deliberately to the most critical data elements rather than attempting to govern everything at once.
Seven categories of data quality were established, covering dimensions including completeness, transparency, accuracy, and accessibility. Each category was defined with specificity for the Zions context, and each governance council member contributed to defining what the category meant within their subject area. Completeness in accounting carries different implications than completeness in retail banking -- and acknowledging that difference explicitly, rather than applying a single definition across the enterprise, was an important design decision.
Data quality was evaluated from two vantage points: before and after the data warehouse. Most organizations have more robust data lineage visibility downstream of the warehouse, because transformations that occur after data enters a structured environment are easier to track than the complex upstream processes that precede ingestion. Upstream quality issues are harder to identify and harder to address, given technical constraints, vendor limitations, and the process complexity of source systems.
When quality issues were identified, the response pathway depended on the nature and scope of the problem. Isolated issues were routed to the relevant data steward for resolution. Recurring or systemic problems that required cross-departmental process changes or significant remediation resources were escalated to the governance council. This tiered structure kept the council focused on strategic and systemic issues rather than being drawn into routine operational problems.
A significant portion of data quality challenges at Zions originated in the bank's acquisition history. Each charter bank had operated with its own standards and terminology, and when the enterprise data warehouse was first assembled, normalizing those differences required substantial effort. The stewardship network that the governance program put in place addressed this ongoing challenge by giving users a clear path to answers: when data appeared inconsistent or ambiguous, a steward could provide context, clarify how the data was entered or used, and resolve the discrepancy without requiring formal intervention.
Thomas framed the governance program around two complementary orientations: defense and offense. The defensive dimension is the one that typically motivates governance investment -- reducing risk, enabling regulatory compliance, and improving data quality. These are necessary outcomes, but they do not generate organizational excitement on their own.
The offensive dimension does. For Zions, the primary offensive play was a master data management solution for customer data, designed to give the enterprise a unified, comprehensive view of each customer relationship. Business intelligence teams, data scientists, governance personnel, and the data warehouse would all contribute to and draw from this central customer hub. The benefits would flow in multiple directions: better visibility into the full scope of customer relationships, more systematic verification of personally identifiable information, improved ability to tailor marketing and promotional offers, and more consistent service delivery across touchpoints including teller platforms and call centers.
Thomas was direct about the strategic stakes: a bank that is not strong in analytics will not remain competitive for long. The community-bank orientation of Zions -- where each affiliate conducts its own marketing, tailored to its regional customer base -- makes the ability to identify customer segments, model profitability, and anticipate needs particularly important. A unified customer data hub creates the foundation for the kind of customer intimacy that drives loyalty and reduces service costs over time.
Sustaining organizational engagement with a governance program after the initial launch energy fades is one of the harder leadership challenges in this space. Thomas's approach at Zions offers several useful lessons.
The first is to build the governance structure around people who are already doing the work. The stewards appointed to the program were not new to data management -- they had been managing and curating data informally for years. Formalizing their role and connecting them to a broader community of practice made the governance program an extension of existing behavior rather than an imposition of new requirements. When governance is built on top of what already works, it is more likely to be sustained.
The second is visible executive sponsorship calibrated to the program's maturity. Early in the Zions program, senior management visibility was high, which gave the initiative credibility and organizational priority. As the program developed its own momentum and governance began to be absorbed into normal business operations, that close executive attention appropriately reduced. The transition from high-visibility launch to embedded practice is a sign of success, not diminishing importance.
The third is connecting the governance work to concrete business outcomes. Abstract concepts around data quality and stewardship will not hold the attention of business leaders for long. The CDO's job is to translate those concepts into results that show up in operations, in customer experience, in regulatory submissions, and in the analytical capabilities the business depends on. Data is the operational fuel of every modern enterprise. Helping the organization understand and act on that reality is the CDO's core contribution.
This article was originally published in IT Pro by the IEEE Computer Society and has been revised for Earley.com.