Simples assim

Veja (e ouça) esses dois clipes. Sem entrar  no mérito do que é bom ou ruim – eu prefiro a Tiê -  as duas interpretações passam mensagens bem distintas, apesar de se tratar da mesma música.

A comunicação falada – especialmente presencial – adiciona vários componentes àquilo que está sendo transmitido, além das palavras em si: a expressão corporal e facial, o tom de voz, o volume e até a possibilidade do feedback imediato, que nos permite eventualmente corrigir algum mal-entendido.

Já a linguagem escrita não tem nada disso, e ainda conta com um agravante: a perenidade. Um email inadequado, uma postagem precipitada no facebook – muitos esquecem inclusive o alcance absurdo da rede social – uma ata de reunião, tudo permanece registrado, podendo ser objeto de consulta no futuro.

Um dia desses chamei um funcionário de minha equipe para conversar sobre uma mensagem que ele havia encaminhado a vários destinatários. Pensei duas vezes antes de fazê-lo, mas acredito que uma das principais atribuições de um administrador é a formação de sua equipe.

Com muito cuidado, tentei explicar que o texto poderia ser melhorado (na verdade, estava muito ruim) e recebi a seguinte resposta:

- Olha, Sérgio, não tem jeito, eu nunca fui bom em português.

Retruquei:

- Eu também não, mas o fato de ler e escrever bastante vai fazendo a gente melhorar continuamente.

Na realidade, muitos dos erros que cometemos não têm muito a ver com o desconhecimento de regras, mas sim com falta de atenção. Argumentei com meu amigo que ele poderia ter evitado pelo menos alguns dos equívocos, que era mais uma questão de atenção ou mesmo de lógica. Falei de algumas dicas básicas, tipo: vírgulas são pequenas pausas, pontos são pausas maiores, crase – um eterno problema – é simplesmente a junção de dois “As”, etc.

Pedi para que meu funcionário pronunciasse mentalmente aquilo que escrevera e voltasse a redigir a mensagem. Resultado: o texto saiu quase perfeito!

Seguem alguns macetes que podemos utilizar no dia-a-dia:

• Quem escreve bem escreve pouco. Isso é particularmente relevante no mundo atual, em que convivemos com excesso de informação;
• Simplifique! Muitas vezes tentamos utilizar termos difíceis sem conhecer o seu significado. É comum a utilização indevida de palavras, apenas pelo que elas parecem representar. Exemplos: assertividade não tem nada a ver com acerto, amiúde não significa detalhamento (a miúdo?), e por aí vai;
• Todo editor de texto tem um corretor ortográfico. Ele nunca vai resolver tudo, mas já filtra os erros mais crassos;
• Algumas coisas são bem chatinhas de aprender, como o uso do porque, do hífen (principalmente depois da reforma ortográfica), do mal/mau, do verbo assistir, do há/a, etc. Aí não tem jeito: pesquise! Com o advento do Google, isso é a coisa mais fácil que existe;
• Gosto muito de uma coluna chamada Dicas de Português, publicada pela jornalista Dad Squarisi no jornal Correio Braziliense (assim mesmo, com “z”).

Bom, melhor ir encerrando por aqui. Quanto maior o texto, maior a possibilidade de errar. Quem sabe já não cometi alguma gafe...  

Desmistificando o BIND

Todas as vezes que converso com alguém de TI sobre BIND, percebo que esse é um conceito extremamente vago para a maioria das pessoas, mesmo em se tratando de analistas e programadores experientes.

Há algum tempo, coloquei numa prova uma questão em que perguntava qual o significado dessa estranha palavra. A maioria dos alunos marcou a opção relacionada à sigla  Binary INteractive Dynamic, algo sem o menor sentido. Na realidade, até existe um acróstico para o termo -Berkeley Internet Name Domain – mas se trata, no entanto, de um servidor para o protocolo DNS.

Estamos falando de outra coisa. Vou tentar explicar tudo em linguagem  coloquial, lembrando que, dependendo da área de tecnologia envolvida, podemos ter significados diversos, mas sempre com o sentido de “ligação”.

Bom, delimitando o escopo, neste contexto vamos tratar de bind como o processo de conexão de um programa com um banco de dados. Utilizaremos o exemplo de um módulo Cobol/SQL acessando o DB2 em ambiente mainframe.

Dentro do código, consideremos duas instruções hipotéticas:
MOVE 1 TO GDA-SDO
EXEC-SQL SELECT NOM FROM DB2XXX.CLIENTE WHERE SALDO = :GDA-SDO 

Ao compilarmos o programa, um dos primeiros passos é a pré-compilação, que varre o código-fonte, identifica as instruções de diferentes linguagens e realiza alguns procedimentos, quais sejam:

1. Extrai do programa Cobol a linha do EXEC-SQL, substituindo-a pela chamada de uma subrotina que irá realizar o acesso ao DB2;

2. O fonte Cobol, após a pré-compilação, ficará mais ou menos assim:

 MOVE 1 TO GDA-SDO

CALL “Interface-DB2” + Parâmetros (incluído na linkedição)

3. Todas as instruções SQL extraídas dão origem a um outro arquivo-fonte, denominado DBRM (Data Base Request Module);

4. Os dois fontes recebem um timestamp com o exato momento da geração dos dois arquivos (um com as instruções Cobol e o outro com o  SQL). Isso é necessário para que, em tempo de execução, quando o programa fizer requisições ao banco de dados, o mesmo se certifique de que tudo faz parte de uma mesma versão. Havendo divergência, o DB2 retorna o “famoso” SQLCODE -805;

5. O bind é simplesmente a criação do plano de acesso do programa ao BD, ou a geração de um executável (o package) a partir do fonte DBRM relacionado. Esse executável normalmente tem o mesmo nome do programa de origem.

Portanto, ao executarmos o programa e este  chegar à instrução SQL, o módulo de carga Cobol, na prática, chama (vide CALL acima) a interface com o DB2 “pedindo” o seguinte:

- Acesse o “package” com o meu nome/timestamp para o meu SELECT com as variáveis que estou lhe passando e me retorne o resultado.

É importante ressaltar que aqui estamos falando de bind “estático”, ou seja, aquele que é realizado previamente à execução, no momento em que o programa é instalado em cada ambiente. Isso é extremamente importante, pois desonera a aplicação de traçar sua estratégia de acesso às tabelas no momento em que o usuário está utilizando o sistema (mais adiante falaremos de bind dinâmico). 

Em cada ambiente produtivo (desenvolvimento, teste, produção, etc) há um bind específico, utilizando o mesmo DBRM.

Mas por que fazer um novo bind em todos os ambientes, ao invés de se reutilizar o package gerado no desenvolvimento? Porque cada ambiente tem seu próprio DB2, com características específicas, e o processo considera diversas informações do catálogo, como a existência de índices, a quantidade de registros da tabela e até a variedade de conteúdos dos campos das tabelas.

Quer dizer que o bind deve ser mais demorado conforme envolva tabelas grandes, pois o DB2 analisa cada linha? Não! Ao se rodar o utilitário RUNSTATS, todas as estatísticas das tabelas necessárias ao bind são consolidadas e gravadas no catálogo do DB2, e essas sim, são utilizadas na geração do package.

Por conta disso é que, como o conteúdo dos bancos de dados é muito dinâmico, faz-se necessário a realização periódica de RUNSTATS e REBIND, para que, a partir do mesmo DBRM, o DB2 reavalie sua estratégia de acesso e gere novo package.

Por fim, quando falamos em bind dinâmico, estamos nos referindo à realização, em tempo de execução, de todo o processo de decisão do DB2 quanto à forma de acesso aos dados, o que pode causar degradação de performance na aplicação, ou mesmo sua indisponibilidade.

Costumo dizer que o bind dinâmico é, na realidade, a ausência de bind, embora não seja bem isso. Até porque, quando uma classe de persistência Java chega ao mainframe via JDBC (Java Database Conector), por exemplo, a primeira execução é bastante onerosa, mas o plano gerado fica em cache e é reutilizado nas chamadas subseqüentes.

Bem, o assunto vai longe, acredito termos abordado o essencial.   

Olhar interior

Um dia desses, a senhora da limpeza se aproximou humildemente e travamos esse insólito diálogo:

- “Seu” Sérgio, eu queria agradecer ao senhor...

- Por que, Elza?

- Porque o senhor conversa comigo.

- Ah, legal. Então, muito obrigado também, pois você também conversa comigo!

- O senhor não entendeu...

- Claro que entendi, por isso estou agradecendo também...

- É que, pra maioria das pessoas, a gente é invisível e, às vezes, se eu não saio do meio, o povo passa até por cima de mim...

Isso não é novidade. Já saiu na mídia uma pesquisa em que um estudioso se fantasiou de gari e relatou uma situação semelhante. Mas presenciar isso pessoalmente me marcou. É a crua constatação de que cada vez mais nos prendemos a estereótipos, consideramo-nos diferenciados ante os mais humildes. Isso pode ser explícito, como a humilhação de um manobrista por um médico, a que presenciei recentemente em uma festa, ou implícita, sutil, como o caso da minha amiga da limpeza.

Esses fatos retratam a nossa incapacidade cada vez maior de encarar a vida com simplicidade, de dar valor às coisas realmente importantes, de colocarmo-nos na situação do outro, de olharmos para as nossas atitudes de forma isenta e serena.

É o tal negócio: a ignorância é o segredo da felicidade; o conhecimento, do tormento. 

Melhor não pensar demais nessas coisas...     

Cadu

Cerca de cinco mil adolescentes participam do Programa Menor Aprendiz do BB de norte a sul do País. Além da capacitação profissional, a orientação dá foco também em princípios éticos e responsabilidade socioambiental. 

Em 2008, o menor da Gerência de Projetos da DITEC era o Carlos Eduardo, um moreninho magro, inteligente e adorado por todos. Além da preocupação com sua formação profissional, procurávamos integrar o Cadu nas atividades sociais que realizávamos.  

Cadu gostava muito de futebol e nas olimpíadas internas da diretoria era o nosso meia-atacante, infernizando a vida dos adversários com sua habilidade e velocidade.

Quando ele me disse que nunca tinha ido a um estádio, prometi levá-lo tão logo aparecesse a  oportunidade.  

Um dia, chamei o Cadu e informei:

- Amigão, eu gostaria de levar você para o melhor jogo que houvesse aqui em Brasília. Infelizmente, o time que poderia proporcionar o maior espetáculo pra você assistir – o meu Fortaleza – não vai se apresentar aqui tão cedo. Portanto, quarta-feira que vem vou lhe levar para um joguinho de segunda categoria no Bezerrão, ok? Se você quiser ir, peça autorização aos seus pais.

Seus olhos brilharam. Cadu era muito bem informado para saber que naquele dia o estádio do Gama seria reinaugurado com a presença simplesmente dos dois maiores jogadores do mundo na época, Kaká e Cristiano Ronaldo. O jogo era Brasil e Portugal, ganhamos por 6 a 2 e nossa seleção deu show!

Hoje, alguns anos depois, meu amigo Cadu já encerrou seu estágio, virou atleta e está na batalha.

Com certeza, o Banco, as dezenas de amigos que conquistou e aquele inesquecível 19 de novembro de 2008 o acompanharão por toda a sua vida!

Bases Corporativas - Um Caso de Sucesso

Nos anos 90, a TI do BB já era referência em termos de sistemas informatizados e processamento de grandes volumes de informação. No entanto, ainda não havia, na prática, um conceito consolidado de bases corporativas.

Em 1997 o Banco do Brasil colocava em produção o aplicativo CLIENTES que, apesar de rodar no “jurássico” terminal 3270, representou um marco na história da tecnologia da informação da empresa. Além de extremamente funcional e ajudar as agências na realização de negócios, o grande diferencial do CLIENTES era transparente para a maioria dos seus usuários e se encontrava na revolução do sistema que rodava por trás de sua camada de apresentação.

Na esteira do Programa Arquitetura da Informação – PAI – um conjunto de sistemas conhecido como COPO (Clientes, Órgãos, Produtos e Operações) foi concebido como embrião das Bases Corporativas, um moderno conceito de gerenciamento de informações, do qual o BB foi mais uma vez pioneiro, em se tratando de grandes empresas do segmento financeiro brasileiro.

Um dos pilares dessa estrutura foi a base de clientes. Até então, o Banco do Brasil utilizava o sistema BDC – Base de Dados Cadastrais – uma estrutura  descentralizada (eram dez SGBDs espalhados pelo país, sem comunicação entre si), sem garantia de unicidade, e que exigia a replicação de informações em seus diversos sistemas transacionais e gerenciais.

Num esforço sinérgico de diversas áreas, tendo à frente as Diretorias de Tecnologia e de Crédito, O Banco do Brasil iniciou então o desenvolvimento do Projeto MCI – Mercado Interno – que contemplava vários avanços, como a centralização das informações, regras rígidas que garantiam a unicidade do cadastro, reuso dos dados e até uma filosofia praticamente inexistente à época, notadamente em se tratando de mainframe: o conceito de serviço.

O sistema foi implantado em tempo recorde e seus benefícios superaram todas as expectativas. O MCI atravessou incólume o bug do milênio e até hoje suas informações são consumidas por centenas de sistemas nas diversas plataformas do BB.

Sua implantação resultou em economia de storage e tempo de processamento, aumento na confiabilidade dos dados, alto grau de reuso e baixa manutenção. Externamente, ganhamos em credibilidade, melhoria da imagem do Banco junto à clientela e incremento dos negócios.

Podemos afirmar com convicção que esse foi o primeiro exemplo efetivo de MDM - Master Data Management, ou Governança de Dados - do mercado bancário brasileiro, permitindo ao BB o gerenciamento de dados complexos, a proteção da informação, a melhoria de controles contábeis e o subsídio à decisão de negócios. 

O MCI virou benchmarking, ganhou prêmios e foi copiado pela concorrência nos anos que se seguiram.