É quase consenso no mercado brasileiro: bancos sabem comprar tecnologia e mantê-la funcionando como ninguém. Pois o leitor ficará consolado ao saber: nas palavras de profissionais de TI de bancos importantes, administrar software bem é um desafio interminável — e é caro. Na área de TI, software é o segundo maior item de custo num banco, atrás apenas de telecomunicações; seu preço tem aumentado nos últimos anos, ao contrário de outros itens de custo em TI; quase sempre, é composto por centenas de aplicativos, utilitários e bancos de dados distintos, cuja interligação consome 80% do orçamento do banco com desenvolvimento de sistemas. Nesta mesa-redonda, organizada pelo Informática Hoje em parceria com a Febraban, algumas idéias merecem destaque: os pacotes de software vêm com uma arquitetura embutida, o que impede as empresas de caminhar para uma arquitetura homogênea; Linux é barato (não é grátis), mas os software profissionais que funcionam com Linux não são; focar a discussão em sistemas operacionais é um erro, pois eles representam uma parte pequena do custo, quando comparados com os aplicativos; e o principal, ao escolher software, é escolher o fabricante que responde pelo software.
Participaram da mesa-redonda, coordenada pelo diretor editorial do Informática Hoje, Wilson Moherdaui, e pelo editor executivo, Márcio Simões: Carlos Eduardo Correa Fonseca, diretor setorial de tecnologia e automação bancária da Febraban e diretor de tecnologia do banco ABN-Amro Real; Paolo Battaglia, superintendente de suporte a mainframe do Unibanco; Cesar Teixeira Mendes, diretor de tecnologia da informação do Banco Real; Mauricio Ghetler, diretor de tecnologia do Banco Santos; José Osmar dos Santos, gerente geral de processamento de dados do Banco Sudameris Brasil; Shie Chen Fang, líder de groupware da Serasa; Marcelo Spaziani, executivo para o setor de finanças da IBM Brasil; e Peter Issar Alves, vice-presidente de marketing e vendas da Giga Information Group do Brasil.

IH — Qual é o desafio de especificar, comprar e manter a posse de software em instituições financeiras? Qual tem sido a experiência de vocês todos?

Fonseca — De tão importante, o tema será analisado numa série de palestras do Ciab 2003, chamada A Caminho de 2020. Há vários pontos a considerar: o custo do software tem crescido e quando os fabricantes oferecem soluções mais baratas, caminham no sentido de tentar amarrar os clientes na solução para cobrar depois; o software on demand, um bonito discurso que na prática ainda não deu em nada; cada pacote tem sua arquitetura e quase nunca é a arquitetura da instituição financeira; juntar dois pacotes é dramático, cada um tem suas tabelas de referência, procedimentos contábeis; desenvolvimento interno versus terceirização é outro dilema, cada vez mais a gente lê sobre grandes terceirizações na literatura; e arquiteturas abertas versus proprietárias, é outro grande dilema. Não vale usar o Linux para arrombar a porta da Microsoft e depois colocar um monte de penduricalhos proprietários em volta, como a gente tem visto. Acho que a gente deve colocar a bandeira do software realmente aberto, esse é o ponto.

Battaglia — O software é um dos maiores custos dos bancos. A busca de redução desse custo é crítica, árdua e difícil de conseguir. Muitas vezes você define uma arquitetura, tenta casar o software com a arquitetura, mas os custos dessa integração acabam extrapolando o custo do serviço como um todo. No ambiente distribuído, é difícil criar e seguir uma arquitetura porque tem sempre pacotes novos entrando na empresa, por causa das fusões. Então, esses são os dois pontos que mais incomodam os bancos: o custo do software e a busca por uma arquitetura única, que nós imaginamos traria benefícios em termos de qualidade e de custos.

IH — O preço do software está aumentando ou o orçamento tem diminuído, e então o preço fica mais relevante?
Battaglia — Claramente o preço do software tem aumentado.
Mendes — Há outras coisas: é muito comum você receber versões de software que não são compatíveis com as versões anteriores, então você tem que reescrever ou adaptar uma série de coisas para atender a nova versão. O custo dessa adaptação é muito alto. Outra coisa é a disponibilidade. Não pode haver interrupção dos serviços bancários. Acho que instalar um software que você mesmo desenvolve dá mais tranqüilidade, porque os hackers se concentram em procurar brechas nos software que todo mundo usa.

Ghetler — Eu acho que qualquer plataforma de software é viável, é só uma questão de gastar um pouco mais ou um pouco menos. Acho que a preocupação maior é se o software vai ter futuro, se amanhã nós vamos encontrar o fabricante novamente. Hoje, a questão não é saber se Java com Microsoft SQL Server funciona — pois se Cobol com VSAM funcionava, por que não? Então, a questão é prever o destino do mercado. Para mim, acho que, em três ou quatro anos, vamos falar de uma briga apenas entre Linux e Microsoft. Outro ponto é que o que carrega o sistema operacional nas costas não é o nosso gosto, são os aplicativos que rodam nele. Se eu tenho um aplicativo Cobol falando com um VSAM, e tudo funciona bem, não vou mudar para Linux nem para Microsoft, continuo no mainframe. Vale sempre o aplicativo. A terceira questão é o on demand para a área financeira, o Carlos Eduardo (Correa Fonseca) comentou bem. Eu nunca vi um sistema de conta-corrente on demand, um sistema de cobrança on demand, um sistema de pagamento on demand. Outro ponto é a viabilidade do sistema de licenças — esses Linux, especialmente Red Hat e UnitedLinux, não mostraram a viabilidade até agora. Não tem nada viável a longo prazo. E se o negócio acabar? Nós fazemos sistemas para durar 20 anos, não podemos pensar numa empresa que não se viabiliza economicamente. E tem outra coisa: a gente paga barato a licença do Linux, mas aí que banco de dados vai colocar? Põe um Oracle. Não resolve muito, a gente sai da frigideira e cai no fogo. Ou seja, a gente não consegue software aberto no que mais nos dói, que são os software aplicativos e os de gerenciamento de banco de dados. O sistema operacional não é o que pesa no meu orçamento.

Santos — Vivemos um paradoxo: somos bombardeados por novas tecnologias, novos desafios, demanda por produtos, mas, ao mesmo tempo, no nosso mercado temos que ser conservadores. Temos a preocupação de ser piloto de novas tecnologias, e não cobaia de novas tecnologias. É isso no caso do software aberto. A cada relatório de custos da Microsoft, os financeiros me perguntam: “Conta aí, e esse negócio de software gratuito?” Aí você tem que entrar no tema do custo total de propriedade: o custo está no treinamento, no suporte, nas migrações.

Fang pan class="txtbold11">— Acho que o que se deve mensurar, para saber se o software é caro ou barato,
é qual o valor agregado que esse software que estou comprando vai trazer para a empresa. Vai compensar? É uma decisão muito difícil. E quanto ao Linux, a minha visão é:
existem software gratuitos, mas empresas como a nossa só compram software que estão garantidos por uma empresa idônea.

Spaziani — A partir de 1994, a IBM adotou a estratégia do software aberto, porque o grande desafio, como vocês disseram, é a integração. A IBM participa de mais de 50 consórcios de definições de padrões abertos, como Java e Linux. A estratégia da companhia é desenvolver para o mercado, e não o que a gente acha que é bom. O SPB deu certo porque escolheram um padrão de mensagens, mas vocês ficaram com a conversão desses dados internamente, para se adequar ao modelo escolhido pelo Banco Central. Vem aí o SPB-2, o valor por transação vai diminuir, o volume de transações vai aumentar, e alguns bancos já têm dificuldade com os volumes por causa da plataforma que escolheram. Como eu ganho escala? Esse é o problema. Queremos que o cliente da IBM, se está rodando em Intel e precisa crescer, passe para uma máquina Linux, que pode ser IBM ou não, ou que passe para o mainframe, pode ser mainframe com Linux, pode ser iSeries com Linux, pode ser OS/400 com Windows NT. A melhor plataforma é a que for mais conveniente para a empresa. Segundo dados de consultorias, hoje as empresas gastam 80% do orçamento de desenvolvimento para manter os sistemas e 20% para criar novos aplicativos. Por quê? Por causa da complexidade da integração. Quanto maior o custo de manutenção de um sistema complexo, maior a exposição a uma falha, então é um risco. Como a gente diminui a complexidade? Com padrões. Quanto ao e-Business On Demand, a questão é que as empresas não podem investir para atender o pico da demanda, e ficar com a infra-estrutura parada depois. Nenhuma empresa sobrevive com esse custo. Então, é disso que estamos falando, é transformar a empresa em on demand, que paga pelo uso.

IH — Mas isso basta para vocês, usuários?

Ghetler — Não. Sobre o SPB: você fala de plataformas abertas, mas logo em seguida fala do IBM MQSeries, que hoje está dentro do WebSphere, mas que é proprietário — por que não dá para pagar pelo uso? Você falou também sobre as plataformas Intel e em soluções mal feitas de SPB.

Spaziani — Não falei que eram mal feitas.

Ghetler — Mas são mesmo.

Spaziani — Falei que tem algum risco com a escalabilidade. Em nenhum momento falei da qualidade da solução.

Ghetler — Exatamente nesse aspecto. Eu trabalho com plataforma Intel. O que eu percebi do mercado é que criam soluções de baixa responsabilidade para a plataforma baixa. Mas o SPB é uma solução de alta responsabilidade. Eu gostaria de lembrar que os melhores resultados que a IBM consegue no Transaction Processing Performance Council, o TPC, consegue com plataforma Intel, não com ambiente AIX. E trabalha com ambiente multiprocessado Microsoft, engraçado que não é com Linux. Então, quem sabe fazer, e vocês sabem fazer, consegue chegar a um nível de transações muito elevado. Outra coisa é o Java. Vocês se apóiam muito no Java, mas a empresa responsável pelo Java, a que tem os direitos, teve 60% de prejuízo em dólar no ano passado. Deus ajude que ela não vá à falência, mas o fato é que o Java é dela, ela pode descontinuar, pode vender os direitos, e amanhã ou depois alguém pode processar a IBM por causa do WebSphere, como a SCO está processando a IBM por causa do Linux. Quem sabe ao certo? E cadê as soluções de conta corrente em J2EE? Eu gostaria de ser apresentado a essas soluções, se possível rodando em Linux.

Spaziani — Sobre as licenças, a gente tem outras políticas para o ambiente distribuído. Essa é uma decisão da companhia. Não quer dizer que eu vou cobrar tudo pelo on demand. Mas não há surpresas no modelo de cobrança da IBM, temos políticas claras de cobrança, seja ela qual for.

Ghetler — Mas há plano de abrir o código por exemplo do MQSeries ou de mudar a forma líquida de cobrança?

Spaziani — Não sei te dizer. Mas você falou em TPC: a IBM não só não tem nada contra a Intel, como investe muito na plataforma. E somos a empresa que tem mais profissionais certificados em Windows. Temos uma relação profissional muito boa com a Microsoft. Quanto ao Java, hoje tem muita gente especializada em Java, os desenvolvedores têm investido muito em Java e em Linux, pela flexibilidade. É o que posso dizer: tudo o que os desenvolvedores querem é uma solução que rode em qualquer hardware ou software.

Ghetler — Tem mais desenvolvedor de Java e de Linux do que habitantes na face da Terra. Mas, ao mesmo tempo, nenhuma boa alma pode nos fazer um sistema financeiro. Talvez não estejam batendo na minha porta, alguém avise se viu um sistema financeiro em Java. Para mim é como cabeça de bacalhau. Em Cobol tem de montão, em Visual Basic tem de montão, em Delphi tem. Pior ou melhor, tem. Pode não ser o que a gente gostaria, mas tem para vender.

Alves — É impressionante. Por incrível que pareça, TI é complexo e a gente não vê a possibilidade de que esse grau de complexidade venha a diminuir, muito ao contrário. Mas eu vejo entre meus clientes, bancos inclusive, escolhas baseadas quase exclusivamente no componente custo. Mas integração é um fator-chave também. Só que é difícil quantificar as outras questões-chave numa linguagem de negócios, então o foco acaba ficando no custo.

Ghetler — Quando a gente discute J2EE versus .NET, acho que estamos discutindo a coisa errada. Tanto um quanto outro não tratam da camada de negócio, tratam só da apresentação. A questão é o banco de dados. Quem vai garantir, no futuro, que essas camadas de apresentação terão compatibilidade com o que está dentro do banco de dados, com as regras de negócio lá dentro, as stored procedures? Hoje não escrevemos mais a lógica de negócio dentro do programa, o programa só vai no banco de dados e lê a stored procedure. Para mim, a camada de apresentação fica cada dia mais irrelevante, o problema fica nos bancos de dados.

Fang — Mas e os web services?

Ghetler — Web services dá para usar entre empresas, mas não internamente, para acessar os bancos de dados, porque é ineficiente. Internamente vamos usar JDBC, DCOM, alguma coisa assim. Mas, quando eu chego no banco de dados, não consigo portar Oracle para DB2, nem DB2 para SQL Server. Então, eu tenho Java, mas continuo preso no banco de dados. Quem vai me salvar?

IH — Alguém tem a resposta?

Fonseca — Eu lhe dou uma recomendação importante: não use em hipótese nenhuma stored procedures... [risos]

Ghetler — Mas, veja bem, aí compromete o desempenho gravemente.

Fonseca — Eu sei. Sem dúvida nenhuma, software é uma das coisas que menos evoluiu nos últimos anos, talvez tenha até retrocedido. É inacreditável.

Ghetler — Agora tudo é incompatível mas você não enxerga. Graças aos web services, há uma camada que esconde a incompatibilidade.

Fonseca — O desespero com a colcha de retalhos que é a tecnologia está chegando a tal ponto que a alta administração das empresas tende a fugir do problema.

Ghetler — Eu troquei todos os sistemas do meu banco ou quase todos por conta de uniformizar os bancos de dados. Só isso já me deu a paz necessária para dar a informação para o meu cliente. É só isso que eu queria. Sinceramente, os fornecedores precisam se concentrar em resolver os nossos problemas, e não os problemas deles. Por favor, me dê uma ferramenta para migrar stored procedures de um banco de dados para outro. Isso nós não temos, o que nos obriga a adotar um monte de soluções no mercado que são meia-sola. E, na apresentação, se a gente vai usar J2EE ou .NET, olha, é a mesma coisa.

IH — Sobre o orçamento de software, vocês gastam mais com o que fazem internamente ou mais com o que compram no mercado?

Ghetler — Meu banco é pequeno, então eu mais compro do mercado do que faço. Tento me basear no mercado; se tem no mercado, vou comprar no mercado.

Battaglia — Pois alguém já inventou a roda.

Mendes — E aí tem a questão do pacote, se o fornecedor vai ser ágil o bastante para te atender. Isso tem que ser levado em conta na hora de comprar, ou você pode perder o time to market.

Ghetler — Tem um grande problema: antes, ninguém imaginava que uma Enron, uma MCI Worldcom, pudesse cair. Antes, a gente não desconfiava das empresas. Hoje em dia, isso é uma preocupação presente. Eu sempre me preocupo com o modelo de negócios do fornecedor. Show me the money! Eu tenho que imaginar como aquela empresa estará ganhando dinheiro amanhã ou depois.

Battaglia — E não incorrer no erro de comprar software pelas novidades mais atraentes, porque você pode nem precisar delas e elas podem não acontecer.

Alves — A Giga tem uma pesquisa: quase 65% daquilo que os fabricantes dizem para os usuários de TI entra por um ouvido e sai pelo outro. Hoje, os fabricantes têm mais dificuldade de provar por A mais B que a solução dele é a melhor que tem no mercado. Então, no frigir dos ovos, a melhor solução é sempre aquela que realmente venha a atender a necessidade do meu negócio.