Paying Respect to The Data Architect

Data architects hold the potential for being valuable change agents. In reality, at best, most have only been empowered as change advocates.

When relational technology was the rage, it became important to ensure data integrity because relational DBMSs enabled referential integrity (RI), and the data architect would be the champion of RI. Then, when client/server hit the scene, capturing and designing business rules into the data architecture on the server was the focus, and, once again, the data architect would champion business rules integration with the data architecture. Today, with the growth of Web development, the focus is once again on data architecture.

As you can see, adopting e-business isn't the only reason to think about architecting critical core data assets, even though Chandras seems to suggest that. But clearly, better reasons preceded it. The longer you wait to get serious about data architecture, the more difficult and costly it becomes.

The time to think about building a house from a blueprint is not after the house is built. How much of the company's core data infrastructure design can you effectively salvage or correct when over the years you've built a large house of interdependent data and process cards? At best you can document the existing "architecture" to help you control what you have and then begin the slow process of redesign. No one should be misled into thinking that Web development should drive that process.

Data architecture: It's not just for e-business, it's for the business.

Robert Takoushian
AdvancePCS
Scottsdale, Ariz.

Chandras Responds:

I enjoyed reading Mr. Takoushian's letter, written, as it would appear, by someone who has much experience in data architecture. Rather than give a point-by-point response, let me state the context of the article.

The article is not written for data architects, but instead for other stakeholders in software projects on either side of the table, and for database architects (DBA) and data analysts who have been conditioned to think of their role in narrow terms. I have met many a client, project manager, or colleague who does not understand why the project needs a data architect when it already has a DBA - and some of these colleagues were DBAs! It's indeed true that while data architects hold the potential for being change agents, they are generally perceived merely as change advocates - and it's this perception that the article partly aims to change.

I chose to focus the article on e-commerce projects - but there is nothing in the article that suggests data architects are required for e-commerce projects only.

Data architects are required (to a varying degree) wherever there is data. But in this dot-com age, I have seen that some e-commerce projects are at greater risk for want of a data architect. Typically (though of course not invariably) these projects share some characteristics: They are venture-capital financed, face an impractical short time to market, and have not yet fleshed out the detailed business model when the software development (or integration) begins. In such cases, it is doubly important to ensure that someone has the responsibility, accountability, and accompanying authority for data. I suspect that many of the dot-com crashes owe a significant part of their failure to the fact that they did not have a designated and experienced data architect in charge of data and database matters. It's particularly this category of software projects that the article addresses.