A very bland, InfoWorld kind of question for the geeks.

Actually, a question for the corporate IT geeks. Many corporate software development shops have self-organized the development functions into a familiar hierarchy: developers, technical leads, project managers, and architects.

The architect's role is one of overall technical vision for a suite of applications or an entire department. The term "technical" vision is necessarily vague or broad, encompassing design, standards, technical leadership, cross-system consistency, etc... Additionally, architects tend to understand how the software systems support the business, requiring knowledge of both business and IT. As departments develop larger, more complex, more critical software systems, the role of architect take a top-down view of the company's software assets. The architect reduces the risk of change-induced failure, and directs the development of new systems integrated with old systems.

But what about the data?

Most corporate software systems are all about moving data around. One department creates some data, another ingests and transforms it, a third aggregates and reports on it, and the finance people use all of it to figure out who owes what to whom.

Just as complex software systems evolve, interconnected in a myriad of ways, complex data relationships evolve, too. Systems are born in isolation, but inevitably start feeding data to, or taking data from, other systems. Often one database holds a system's transactional, day-to-day data, while another, independent database holds the same information in a denormalized, query friendly format, or in a full-blown datamart or data warehouse, taking data from a number of systems, and transforming it for analysis.

Just as an architect needs to understand the relationships between software systems, someone needs to understand the flow of data, storage formats, and business ownership of the information stored in the database.

And this position, one you might call a data architect, is one I don't hear much about.

And that is the question: how does your company deal with these top-down issues of data integrity, ownership, transformation, and analysis? Who is responsible, what are they called, to whom do they report, and what do they do?

Here are some topics that may spur discussion:

• IT departments seem to organize in one of two ways: a centralized, horizontally-sliced, service-based organization, where teams are allocated on a project basis; a decentralized, vertically-sliced organization where teams are dedicated to departments or business areas. How is the position of software or data architect different for these two kinds of IT organization?
• Software development groups are often separated into designers and developers; designers do more of the specification, while developers do more of the implementation. It is a natural progression to move from a design group into an architecture group. Database administration groups are less often organized this way. If your company has a position like a data architect, to what group (development, DBA, analysis, ...) does the position belong?
• The position of software architect is naturally one of setting policy, specifying certain aspects of development. Data architects would have a similar role, specifying standards for schema and database implementation. How can these positions exist without causing tension and antagonism within the developers and DBAs?
• The migration from developer to team leader to designer, or from DBA to system DBA is pretty clear. The progression of skills is clear. Architect and data architect, however, require as much skill in communication, management, and business as they do hard technical skill. The path to an architect position is not as clear; people who make good developers don't necessarily make good architects. How does a department develop these skills in their people?