Muito já se falou e continua falando sobre modelagem de dados, porém gostaria de focar num ponto do cenário de TI e de negócios que a meu ver pode recebera luz e por que não de um pouco de reflexão?
O que vai aqui neste artigo é um pouco de conhecimento de TI misturado com a experiência própria em diversos clientes em situações que vão desde de manutenção em base de dados até integração com módulos de outros executáveis e aplicações web como nota fiscal eletrônica.
Frequentemente tenho que efetuar manutenção em diversas bases de dados sejam elas baseadas em tecnologia Microsoft ( SQL Server,Access,Foxpro), Oracle ( Oracle e MySQL ) bem como outras como Firebird (Borland ), IBM(Informix,DB2) e por aí vai…
No momento desta manutenção temos sempre em mente o que vamos ter que mudar,qual código sql aplicar,quais esquemas usar, mas isto não basta.
Assim como um profissional de uma oficina – que tem seus quadros de ferramenta e trabalhos sempre a mostra e disponíveis,o profissional de TI deve se preocupar em ter facilidades de trabalhos semelhantes para não dizer idênticas no sentido de documentação,acesso,visual gráfico e legibilidade clara do processo que deve ser alterado durante sua rotina de manutenção.
Para conseguir isto os profissionais e aqui não mais só os de TI, mas também e principalmente aqueles que vão utilizar o sistema de informação precisam conhecer não só da regra de negócio mas também de como os dados e os tratamentos de exceção são vistos pelo sistema de gerenciamento de banco de dados que sedia o negócio a ser alterado.
Sei que muitas vezes em função do perfil profissional nem o desenvolvedor ou o DBA têm plena abrangência do negócio bem como o profissional que analisa o negócio ( analista de negócios ) tem conhecimento técnico em banco de dados; porém vale lembrar que a modelagem não é uma linguagem excessivamente técnica, aliás não é linguagem e sim uma ferramenta visual para discussão de como os dados são armazenados e interagem nas rotinas que provêm o funcionamento do negócio em si.
Para ilustrar, esta semana mesmo tive um exemplo claro de como a junção de conhecimentos e mais uma modelagem auxiliam no esclarecimento e até na divisão de tarefas para completar uma nova implementação nas rotinas de uma empresa.
Estávamos em três pessoas, dois de TI e um homem de negócios, e eu havia deixado pronto uma modelagem simples com documentação também simples sobre os esquemas de dados que sofrem alteração de status, ou seja elementos de transição-estado.
Em cerca de 2 horas de reunião decidimos as tarefas e como a base de dados poderia ficar, com implementações simples.
Para que isto ocorresse foi fundamental ter conhecimento da base, documentação minima e conhecimento do negócio.
Estes conhecimentos são adquiridos de várias formas e uma delas é através de treinamento, seja com intuito de reciclar ( mudando a abordagem ), seja no intuito de fortalecer o uso ( mudando a forma de trabalho ).
Todos temos como fato que nossos conhecimentos são passíveis de mudança, principalmente no cenário atual de globalização, onde é vital o uso de informação segura e confiável.
A única recomendação que faço ( me permito esta ousadia ) é que o nível de comunicação seja o mais claro possível para cada interlocutor nas reuniões de negócios e uma forma de auxiliar é utilizando mais esta ferramenta além de outras que vamos falar futuramente.
Para reflexão:
