The Chief Data Architect

By on

Architectby Michael Brackett

Over the years many titles have been proposed and used for primary data management positions, such as data administrator, data guardian, data czar, data custodian, and so on.  A recent title is data governor, presumably to manage the data governance function.  However, data cannot be governed—only people can be governed.[i]  Another recent title is data scientist, presumably for managing big data.[ii]  However, that implies that a data scientist is not needed for small data.

The whole scenario of primary data management titles seems to be searching for a title that works, then keep that title—a scenario known as silver bullet titles.  That scenario is simply another form of the ongoing hype-cycles in data management.  It avoids precise definitions of position responsibilities and position location in an organization.

The scenario continues with proposals for the creation of a Chief Data Officer (CDO).  The good news is that the proposal finally admits that the Chief Information Officer (CIO) has no, and is not, properly managing the data resource.  The proposals also recognize the difference between data and information, meaning the CDO manages the data resource and the CIO manages the production of information from that data resource.  However, the bad news is that the proposals likely won’t work any better than previous titles.

The CIO evolved from the Chief Financial Officer (CFO) largely because data processing originated in Finance in most organizations.  As data processing evolved into Information Technology (IT), the CIO position became part of IT.  The problem is that the CIO and IT never adequately managed data as a critical resource of the organization, as evidenced by the huge quantities of disparate data that are blocking efficient use of the data resource to support the operational and analytical business information demand.

Information Technology, including the CIO, is typically hardware and software centric.  It is primarily concerned with hardware and software acquisitions, physical data structures, and the manipulation of data to produce information.  It is seldom interested in the formal design and development of a high-quality data resource within a single organization-wide data architecture.

That orientation is not likely to change with a CDO.  The CDO retains the Officer concept and will likely remain oriented toward hardware and software acquisition, database management, and the physical manipulation of the data.  The CDO will not likely have a major orientation toward the formal design and development of data as a critical resource of the organization based on business needs.  Very little will have been gained.

The question becomes What can be done to resolve the disparate data situation so that the business information needs are met?  Specifically, What should the title be and where should data management be placed within public and private sector organizations to ensure that an organization’s data resource is properly designed and implemented to fully support the operational and analytical business information demand?

The answer is the establishment of a Chief Data Architect.  The Chief Data Architect was introduced in the mid-1990s to face challenges of managing an organization’s data as a critical resource and to build a single organization-wide data architecture, according to formal concepts, principles, and techniques, and within which an organization’s data are formally designed and managed.[iii]

An architect is one who designs and advises on the construction of something; one who plans and achieves a difficult objective; a master builder.  The Chief Data Architect is an architect that expedites and facilitates the design and development of a high-quality data resource, within a single organization-wide data architecture, to meet an organization’s current and future business information demand.  The Chief Data Architect must understand the business and be Of the business, by the business, and for the business.

The Chief Data Architect is responsible for analyzing the business needs and synthesizing a solution.  They must follow the sequence of business understanding, to logical data resource design, to physical data resource implementation.[iv]  They must avoid any brute-force-physical development effort, stop the burgeoning data disparity, and resolve the existing data disparity.

Data architects work for the Chief Data Architect and are responsible for the detailed design and development of the data resource.  Data modelers work with the data architects to produce complete models of the data architecture, including formal names, comprehensive definitions, proper structures, precise integrity rules, and robust documentation.  Data architects typically have people skills and data modelers typically have the tool skills.  Both must be skilled at portraying the business needs in a manner that is readily understandable to business professionals based on their perception of the business world.[v]

The Chief Business Architect thoroughly understands the business activities and works with closely with the Chief Data Architect to design and develop the data resource.  They expedite and facilitate the development of a single organization-wide business activity architecture and for resolving the business activity disparity, which is often larger than the data resource disparity.  They ensure that business professionals step up to the task of clearly explaining their data needs.

Information Technology manages the hardware, system software, databases, system upgrades, backup / recovery, data storage and retrieval, performance, migrations, and so on.  Database professionals within IT work with the data architects and data modelers for physical implementation of the logical design without compromising that logical design.

A small organization may have only one Chief Data Architect.  A medium size organization could have a Chief Data Architect and one or more data architects and data modelers.  Larger organizations could have a Chief Data Architect, senior data architects and data modelers, and junior data architects and data modelers.

The Chief Data Architect must be located at an executive level in the business, not in IT, to ensure that design and development of the data resource progresses from business needs, to logical design, to physical implementation.  The position must be equivalent to the directors of finance, human resources, and facilities management, and must have responsibility across all business functions.  Data architects and data modelers may be assigned to the Chief Data Architect, or to specific business functions or subject areas.  They can be permanently located or assigned as needed depending on the size of the organization, its structure, and the workload.  The basic principle is that they must follow formal data resource design and development rules, just like following finance rules, human resource rules, or property management rules.

Several guidelines are available for the primary data management responsibility.  Public and private sector organizations have a better chance of successfully managing their data as a critical resource of the organization when:

The primary responsibility for managing data as a critical resource is located in the business rather than in IT, and is separate from the Chief Information Officer.

A Chief Data Architect is assigned that primary responsibility which extends across all business functions.

The design and development of the high-quality data resource is driven by the current and future operational and analytical business information needs, and is based on formal concepts, principles, and techniques.

The data resource is designed and developed within a single organization-wide data architecture, avoiding multiple independent and competing data architectures, and preventing data disparity.

The data resource is designed and developed from business needs, to logical design, to physical implementation, avoiding any brute-force-physical approaches.

Business professionals are actively involved in the design and development of the data resource.

Database professionals are actively involved in the physical implementation and operation of the data resource without compromising the logical design.

A teamwork approach is established between the design, development, and implementation of the data resource, and the preparation of information from that data resource.

The primary responsibility for data resource management—managing data as a critical resource of the organization—must go to the business, because IT, including the CIO, has not adequately managed data as a critical resource.  A Chief Data Architect must lead data resource management, must be located at an executive level, and must have responsibility across all business functions.  The Chief Data Architect expedites and facilitates the analysis of business information needs, the logical design of a data resource that supports those needs, and the physical implementation of that design.

The CIO has responsibility for the development of information from the data resource.  Database professionals will remain in IT as long as they properly implement the logical design.  Otherwise, that function must go to the business under the Chief Data Architect.

Data management professionals and business professionals must actively promote and support the creation of a Chief Data Architect if they ever expect to develop a high-quality data resource that fully support their operational and analytical business information demand.  Organizations that don’t establish a Chief Data Architect have a greater chance of failing.



[i] Michael Brackett, Can Data Really Be Governed. DATAVERSITY, May 29, 2012.

[ii] Michael Brackett, Is Big Data A Meaningful Term. DATAVERSITY, February 26, 2013.

[iii] Michael Brackett, Data Sharing Using a Common Data Architecture. John Wiley & Sons, New York, 1994.

[iv] Michael Brackett, The Five Horsemen of Disparate Data. DATAVERSITY, November 29, 2012.

[v] Michael Brackett, The Umwelt Principle. DATAVERSITY, January 29, 2013.

We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept