Uma visão diferente sobre o papel do BDA
Hoje no Brasil posso dizer que estamos transcendendo já aos poucos a faze da orientação a Dados. Não que isso seja necessariamente uma coisa ruim. Para certas situações o bom e velho ORACLE Designer e conjunto com o ORACLE FORMS produzem uma solução viável. Mas o ponto que eu quero chegar com isso é que nos estávamos em um paradigma orientado a dados.
Não digo por si só um paradigma orientado a dados mas estruturado também. Não tenho como objetivo neste post falar sobre OO. Mas sim falar em paradigmas. Utilizar uma linguagem como Java ou C# não deixa o sistema OO por si só. Utilizar classes ou até mesmo interfaces também não deixam o seu sistema OO?
O que deixa um sistema OO?
É a maneira que você pensa. É como você faz o Design da coisa toda. Uma coisa que me marca muito é que uma prova cabal sobre a transadencia da faze de dados a uma outra faze é a questão do banco de dados. Muitas vezes é lá que o bixo pega. Muitos sistemas quando são colocados em produção geram diversos problemas e muitas vezes é lá que a coisa estoura.
Então atravessado dos anos isso gerou uma certa preocupação redobrada nas empresas em relação a suas bases de dados ou melhor ainda e como serão utilizadas. Nesse momento surge a preocupação com a máquina e com a licença muitas vezes.
O pensamento forte no Banco de Dados
Então nesse contexto surgem as consultorias sobre banco de dados. Existem consultorias muitos boas sobre banco de dados, de facto, com uma qualidade técnica muito boa. Mas nesse caso existe uma grande gap. Esse gap é o paradigma que falei no inicio do post.
Que paradigma é esse?
É o desenvolvimento de software. As empresas e gerentes de projetos, passam muito tempo se preocupando com coisas do tipo:
Como disse no inicio do post é no banco de dados que os problemas surgem, mas é não interação mal feita entre o DBA e os desenvolvedores e arquitetos que os problemas surgem. Muitas vezes por problemas de comunicação.
Eis que existe um relaxamento quanto ao processo
Infelizmente muitas empresas confundem ter um processo com ter burocracia. Ter processo não significa ter burocracia, significa ter uma meio efetivo para fazer as coisas. Diferente de como alguns consultores CMMI dizem você não precisa ter dados históricos de tudo. Mas diferente de como alguns agilistas dizem também não é necessário rasgar tudo.
Claro que o pessoa de Banco de dados tem que participar de vários projetos, mas a sua interação não pode ser só por e-mail e para resolver problemas. Sem contexto ninguém faz nada de qualidade!
Como dar contexto ao um DBA?
Se você usa Scrum um pequeno ato que dá bons resultados e colocar o DBA a participar dos processos do Scrum como a reunião diária e o processo de fechamento e abertura de Sprints. Se você não usar Scrum mas tem algum processo baseado em timebox fechado pode realizar workshops sobre o sistema e deixar que o pessoal que cuida do banco de dados participar. O importante é ter mais comunicação, assim o DBA pode antecipar problemas e com isso melhorar a qualidade do seu sistema de produção.
O Scott Ambler tem um processo muito bom que se chama Agile Data, nesse processo ele descreve bem como pode ser a interação dos DBAs com o pessoal do desenvolvimento e da boas dicas de como fazer isso de maneira efetiva.
O Scott particularmente tem um bom conhecimento sobre processos envolvendo banco de dados, recomendo que vocês olhem os livros dele também, ele tem um de refactoring de banco de dados muito bom.
Que pontos podem ser melhorados?
Vários. Mas em especial você pode começar a conversar mais com o seu DBA e explicar mais o sistema para ele, o objetivo de cada modulo, a visão geral da arquitetura, os principais requisitos do sistema, etc...
Depois pode tentar aplicar os padrões de refactoring e versionamento de banco de dados com o Liquibase. Por fim pode aplicar testes no banco de dados. Não digo só testes de carga mas testes unitários também.
São muitos os desafios para integrar o desenvolvimento com o pessoal de banco de dados, mas só vamos conseguir isso com um bom processo, e aplicando isso de forma evolutiva e incremental, pois essa cultura não existe em muitas empresas.
Não digo por si só um paradigma orientado a dados mas estruturado também. Não tenho como objetivo neste post falar sobre OO. Mas sim falar em paradigmas. Utilizar uma linguagem como Java ou C# não deixa o sistema OO por si só. Utilizar classes ou até mesmo interfaces também não deixam o seu sistema OO?
O que deixa um sistema OO?
É a maneira que você pensa. É como você faz o Design da coisa toda. Uma coisa que me marca muito é que uma prova cabal sobre a transadencia da faze de dados a uma outra faze é a questão do banco de dados. Muitas vezes é lá que o bixo pega. Muitos sistemas quando são colocados em produção geram diversos problemas e muitas vezes é lá que a coisa estoura.
Então atravessado dos anos isso gerou uma certa preocupação redobrada nas empresas em relação a suas bases de dados ou melhor ainda e como serão utilizadas. Nesse momento surge a preocupação com a máquina e com a licença muitas vezes.
O pensamento forte no Banco de Dados
Então nesse contexto surgem as consultorias sobre banco de dados. Existem consultorias muitos boas sobre banco de dados, de facto, com uma qualidade técnica muito boa. Mas nesse caso existe uma grande gap. Esse gap é o paradigma que falei no inicio do post.
Que paradigma é esse?
É o desenvolvimento de software. As empresas e gerentes de projetos, passam muito tempo se preocupando com coisas do tipo:
- Que banco de dados vão usar
- Que licença elas vão precisar
- Quanto ira custar por mês
- Que empresa ira dar consultoria de DBA
- Quanto tempo será o SLA
Como disse no inicio do post é no banco de dados que os problemas surgem, mas é não interação mal feita entre o DBA e os desenvolvedores e arquitetos que os problemas surgem. Muitas vezes por problemas de comunicação.
Eis que existe um relaxamento quanto ao processo
Infelizmente muitas empresas confundem ter um processo com ter burocracia. Ter processo não significa ter burocracia, significa ter uma meio efetivo para fazer as coisas. Diferente de como alguns consultores CMMI dizem você não precisa ter dados históricos de tudo. Mas diferente de como alguns agilistas dizem também não é necessário rasgar tudo.
Claro que o pessoa de Banco de dados tem que participar de vários projetos, mas a sua interação não pode ser só por e-mail e para resolver problemas. Sem contexto ninguém faz nada de qualidade!
Como dar contexto ao um DBA?
Se você usa Scrum um pequeno ato que dá bons resultados e colocar o DBA a participar dos processos do Scrum como a reunião diária e o processo de fechamento e abertura de Sprints. Se você não usar Scrum mas tem algum processo baseado em timebox fechado pode realizar workshops sobre o sistema e deixar que o pessoal que cuida do banco de dados participar. O importante é ter mais comunicação, assim o DBA pode antecipar problemas e com isso melhorar a qualidade do seu sistema de produção.
O Scott Ambler tem um processo muito bom que se chama Agile Data, nesse processo ele descreve bem como pode ser a interação dos DBAs com o pessoal do desenvolvimento e da boas dicas de como fazer isso de maneira efetiva.
O Scott particularmente tem um bom conhecimento sobre processos envolvendo banco de dados, recomendo que vocês olhem os livros dele também, ele tem um de refactoring de banco de dados muito bom.
Que pontos podem ser melhorados?
Vários. Mas em especial você pode começar a conversar mais com o seu DBA e explicar mais o sistema para ele, o objetivo de cada modulo, a visão geral da arquitetura, os principais requisitos do sistema, etc...
Depois pode tentar aplicar os padrões de refactoring e versionamento de banco de dados com o Liquibase. Por fim pode aplicar testes no banco de dados. Não digo só testes de carga mas testes unitários também.
São muitos os desafios para integrar o desenvolvimento com o pessoal de banco de dados, mas só vamos conseguir isso com um bom processo, e aplicando isso de forma evolutiva e incremental, pois essa cultura não existe em muitas empresas.
