Entrevista concedida ao Fernando Ike

O que é um Arquiteto de Dados?

A pessoa responsável pela arquitetura e administração dos dados de uma organização. No caso, a arquitetura envolve desde a arquitetura de sistemas de bases de dados até a modelagem dos dados e sua manutenção; e a administração seria mais especificamente a manutenção dos modelos e dicionários de dados.

Qual a interação de um Arquiteto de Dados e um DBA? Ou é a mesma coisa?

Muitas vezes, em organizações menores ou menos estruturadas, a administração de dados é efetuada pelo Administrador de Bases de Dados. Mas normalmente, o DBA deve se ocupar da administração diária dos bancos de dados físicos e seu conteúdo, efetivamente uma administração dos Sistemas Gestores de Bases de Dados. Enquanto o AD deve se ocupar do projeto das bases de dados e sua estrutura lógica, não se envolvendo diretamente nos aspectos físicos.

Ok. corrigindo, Administrador de Base de Dados.

Tanto faz. Databank era o uso até os anos 70, que ficou fixado no Brasil. No resto do mundo se usa base.

Com essa afirmação, é possível supor que o AD seria o chefe de DBA (vou manter a sigla por enquanto…)?

Não, eles colaboram em níveis hierárquicos similares. Imagine um novo sistema. O arquiteto de dados será responsável pelos aspectos lógicos, principalmente a modelagem da estrutura da base; o DBA participará do projeto físico, como questões de distribuição, processamento e armazenamento. Um não trabalha sem o outro, e enquanto o projeto lógico deveria teoricamente determinar o físico, restrições tecnológicas podem (embora indesejável) determinar aspectos do lógico.

Como você afirmou acima, as vezes o DBA acaba executando algumas funções que estariam com AD, no Brasil tem mercado para um Arquiteto de Dados?

Ainda restrito e subvalorizado, mas tem. Empresas que têm na informação seu principal meio de trabalho costumam contratar ou formar um quando amadurecem. Bancos, empresas de informação de crédito, seguradoras e até corretoras de seguros, mesmo fornecedores de programas (é o caso de meu empregador atual).

É verdade que há retrocessos, como o advento da terceirização; assim, há o caso de uma multinacional fabril que terceirizou a mão de obra, de modo que a mesma vaga, que antes percebia determinada quantia CLT, hoje percebe a mesma quantia mas em regime PJ, sem correção significativa.

Outro fator detrimental é o foco em produtos, não em conceitos e processos. Assim, a mesma multinacional já deixou de contratar ótimos candidatos por falta de experiência em determinada marca de ferramenta de administração e diagramação, sendo que o candidato em questão tinha experiência suficiente em mais de uma ferramenta completamente equivalente.

Resumindo, ainda é um mercado bastante imaturo, o que leva a situações como as recomendações do AD serem vencidas por meras impressões e preconceitos de pessoas sem experiência com dados, opinando simplesmente do ponto de vista de vícios de programação por exemplo.

Então é possível afirmar que para um Arquiteto de Dados não é necessário ter conhecimento em vários banco de dados?

Em princípio não. Entretanto, devido à imaturidade de vários SGBDs — citem-se por exemplo, mas não exaustivamente, suporte deficiente a tipos de dados em Oracle, MS SQL Server, Sybase e MySQL, e problemas graves de desempenho e consistência neste último —, muitas vezes é conveniente que o AD possa compreender essas especificidades e trabalhar com o DBA e os desenvolvedores para adaptar a arquitetura e o modelo de dados às circunstâncias tecnológicas.

Não citou o PostgreSQL, ele é um boa referência para quem quer iniciar uma carreira como AD?

Uma das melhores, no mesmo nível do IBM DB2. São os SGBDs que têm o melhor suporte tanto ao padrão ISO SQL:2003 (o 2006 ainda não se fez sentir no dia-a-dia) quanto ao modelo relacional — ambos com restrições, mas ainda assim superiores a todos os concorrentes mais óbvios.

Entretanto, sendo uma área de atuação eminentemente lógica, recomenda-se, mais que determinados SGBDs, o futuro AD tenha um bom domínio tanto do modelo relacional, quanto de outros aspectos da teoria da gestão de bases de dados, e inclusive do padrão ISO SQL:2003 em si. As referências padrão, pela atenção que dão aos aspectos lógicos, são as obras de Chris J Date, embora polêmicas em vários aspectos que chegam a suscitar reações apaixonadas contra e a favor de vários praticantes de prestígio.

Esse é um ponto interessante, pois reflete alguns aspectos teóricos que envolvem o DBA. Um AD necessariamente deve ser um DBA também?

Não necessariamente. Entretanto, justamente devido a todas as restrições tecnológicas atuais, é interessante que o AD tenha a capacidade de adaptar-se a circunstâncias, o que pode ser facilitado se ele tiver tido alguma experiência com aspectos físicos, seja como DBA, programador, analista de sistemas, SysAdmin… isso lhe dará mais empatia com posições eventualmente divergentes na negociação de projetos de arquitetura de dados e modelagem, e possibilidade de dialogar com os problemas físicos reais ou imaginários freqüentemente trazidos por outros profissionais.

Pensando que uma empresa irá contratar uma consultoria para área de banco de dados, o que a mesma economizará contratando um Arquiteto de Dados ao invés de ter somente DBAs?

Nem tudo na vida são economias. Embora o principal foco do AD não seja monetário, porque o resultado do seu trabalho dificilmente é mensurável nesses termos, há muitos erros de projeto caros que podem ser minorados pela presença de um AD, ou pelo menos de um DBA com preocupação pelos aspectos lógicos.

Um dos aspectos do trabalho do AD é a normalização, que evita duplicação de dados que normalmente torna o desenvolvimento do sistema como um todo, mesmo na fase de programação, mais complexo, frágil, lento e arriscado, podendo também gerar custos de manutenção e operação como freqüentes anomalias de atualização, consumo exagerado de recursos de sistema, problemas de escalabilidade &c.

Um exemplo foi uma operadora de telecomunicações brasileira que tinha um consultor ao custo de ao menos nove mil dólares por mês (valor mínimo cobrado pela consultoria, possivelmente muito mais naquele caso específico) para resolver casos de inconsistência de dados. Além desse gasto muito simples e mensurável, essas inconsistências geravam grandes problemas de insatisfação de clientes. Não é difícil imaginar alguns desses problemas tornando-se questões mesmo de relações públicas, no caso de uma operadora de serviços públicos.

Há que se considerar também a questão da eficiência: embora alguns DBAs possam desempenhar funções de AD com razoável competência, será um uso ineficiente do recurso humano, que perderá foco em sua função tradicional sem realmente se concentrar na de AD.

O outro lado da moeda é que, devido ao baixo nível intelectual de muitas equipes de desenvolvimento impedi-las de compreender questões lógicas de conseqüências não inteiramente óbvias e imediatas, o peso da opinião de um DBA praticante pode ser maior que a de um AD. Entretanto, uma equipe com esse problema certamente terá muitos outros problemas igualmente óbvios e imediatos.

É um problema de maturação do mercado de TI no geral.

Aliás, ou de maturação ou, às vezes dá impressão, decadência…

Dê duas ou três dicas rápidas para quem quiser trabalhar como AD.

1. Concentrar-se num sólido conhecimento conceitual;
2. Abstrair problemas específicos de SGBDs, mesmo que depois sejam necessárias adaptações;
3. Desenvolver uma visão ampla, que contemple desde as regras de negócio (== restrições de integridade) até questões de desempenho e manutenção da aplicação.