SOA é um tipo de filosofia de vida, dizem alguns dos CIOs nesta mesa-redonda; mas, a julgar pelo vocabulário empregado (barramento, repositório de metadados, etc.), SOA ainda é vista pelos profissionais de TI como um problema de infra-estrutura. Provavelmente, as duas visões de SOA (e de BPM) estão corretas. BPM e SOA são filosofias de vida, e também são problemas de infra-estrutura.
A mesa-redonda foi coordenada por Wilson Moherdaui, diretor editorial do Informática Hoje, e por Márcio Simões, diretor de redação. Participaram: Antônio Mariano, superintendente de infra-estrutura tecnológica da Liberty Seguros. Cláudio Martins, diretor de TI da General Motors. Fabiano Borges, gerente de desenvolvimento organizacional e de TI do Centro de Gestão de Meios de Pagamento (Pedágio Sem Parar/Pedágio Via Fácil). José Roberto Cardarelli, gerente de TI da Aços Villares. Leão Carvalho, diretor-presidente da Prodesp Tecnologia da Informação. Manel Benazet, CIO regional da Telefônica na América Latina. Márcia Arruda, gerente de desenvolvimento web da SulAmérica Seguros. Marcio de Souza Tibo, superintendente de suporte ao desenvolvimento da Prodam. Rodrigo Evangelista de Castro, gerente nacional da Caixa Econômica Federal. E Walkiria Shirrmeister Marquetti, diretora da área de tecnologia de negócios do Bradesco.

IH — Quais são as vantagens e dificuldades trazidas por BPM e SOA?

Manel — Desde janeiro, sou o CIO regional da Telefônica na América Latina, responsável pelas 18 operações da Telefônica do México para baixo. Antes disso, durante três anos fui o responsável pela Telesp em São Paulo.
Estamos substituindo os sistemas legados de todas as operadoras. Muitas eram estatais, com sistemas legados importantes. Queremos substituir, em todas as operações, blocos de sistemas por sistemas únicos. Abordamos o tema da arquitetura. Já fizemos alguns testes de conceito no Peru, no Brasil, no Chile e na Argentina. Fizemos algumas experiências melhores, outras piores.
Fundamentalmente, começamos pelos sistemas de tramitação e pelos sistemas de barramento, os que grudam todos os sistemas com função específica.
Já implementamos, com tecnologia BPM e com uma abordagem de SOA, sistemas de tramitação de pedidos e de ordem de serviço, para apoiar as operações do dia-a-dia. Fizemos isso em três operações; pretendemos fazer em sete. No caso de sistemas de apoio ao negócio, mandamos neste momento uma equipe ao mercado, um monte de fornecedores participam; faremos a implementação no primeiro semestre de 2008.
Precisamos fazer ainda grandes coisas para dizer que temos maturidade em SOA, mas já constituímos esse projeto com repositório, gestão de componentes. Até já conseguimos reusar alguma coisa, mas não tiramos muito proveito do reuso.
Esse é um dos grandes problemas: precisamos de muita disciplina depois da SOA para tirar proveito de todo o investimento.

IH — Falta fazer o quê? Que grandes coisas?

Manel — É complicado alinhar processos como os nossos em âmbito global.
O funcionário costuma se virar com os sistemas, principalmente legados, e costuma conhecer as restrições dos sistemas. Então ele muda os processos por fora, sem necessariamente pedir mudanças no sistema.
Quando vemos a necessidade de apoiar o negócio com sistemas baseados em processos, e quando os funcionários acham que não devem informar as mudanças nos processos, vira um pesadelo mudar o modo como disparamos esse serviço em campo. Os funcionários mudaram coisas no meio, mas não informaram. Num primeiro momento, essas mudanças não-informadas não provocam impacto; mas aí nós mudamos os processos e essas mudanças não-informadas provocam impacto sistêmico.
A empresa deve entender que, para mudar processos de forma estruturada e para aproveitar os investimentos feitos em BPM e SOA, a disciplina com os processos precisa ser germânica. Mas somos muito latinos.
Esse é um dos nossos desafios. Algumas mudanças nos pegam de surpresa, porque afetam coisas das quais nem tínhamos conhecimento, porque alguém em algum momento mudou uma parte do processo e não informou.
Eu brinco sempre: precisamos dessa disciplina germânica para depois desfrutar da condição de latino, para criar.
Temos também desafios importantes na segurança, no repositório; esses temas ainda não estão sólidos.

Márcia — Há um tempo atrás, a SulAmérica descentralizou a informática. Durante uns anos, os funcionários da TI trabalham debaixo das unidades de negócios, das BUs. Como eu trabalho na unidade de negócios de saúde, durante uns anos eu fiz parte do time da BU Saúde. Nesses anos, conseguimos mostrar à diretoria de cada BU que poderíamos fazer algumas coisas. Por exemplo, tomamos a iniciativa de componentizar a informática.
Há uns dois anos e meio, convertemos todos os nossos componentes de Visual Basic em Java, pensamos em reuso, pensamos que nos comunicaríamos com nossos fornecedores por meio de componentes, sempre conversando no mesmo padrão e no mesmo modelo. Demoramos em torno de um ano para converter todos esses componentes.
Ainda temos um pouco de legado, ainda temos VB (que convertemos para .NET).
Nesse período, tocamos uma iniciativa de BPM. Os usuários queriam saber onde estava o reembolso deles dentro da SulAmérica. Na web, tudo o que dizíamos era: em análise, em análise. Montamos um fluxo de documentos, e conseguimos dar uma resposta melhor para o usuário por meio do site.
Então, essas duas ações nós já implementamos.
Mas sentimos falta de algumas coisas. Por exemplo: fazia parte do projeto de componentização criar um banco de componentes, aos cuidados de arquitetos, para que realmente tivéssemos reuso. Precisávamos de investimento, mas ninguém da BU conseguia ver nada de palpável nisso. Então, a BU dizia: em vez de fazer isso, vamos implementar aquela tela lá na ponta.
Não abandonamos a iniciativa, mas ela anda a passos de tartaruga.
Quanto ao BPM, é algo já implementado na SulAmérica; nossa tecnologia fala com a plataforma alta e a baixa. Montamos um robô para levar e trazer informações da plataforma alta.

Rodrigo — A Caixa vem estudando BPM e SOA faz dois anos; uma das dúvidas é como começar. Os fornecedores de tecnologia prometem muita coisa, e ao longo do tempo a gente se frustrou com algumas das promessas.
Logo no começo nós definimos uma estratégia para vender BPM e SOA dentro da Caixa. Elegemos um projeto campeão e desafiamos os fornecedores a mostrar que isso funciona. Se a tecnologia funciona num projeto campeão, a gente consegue vender isso mais fácil para os executivos da Caixa.
Para escolher o projeto campeão, mapeamos a estratégia empresarial da Caixa, a estratégia para os próximos cinco anos, e identificamos os projetos críticos para suportar essa estratégia empresarial.
No processo crítico escolhido, aplicamos BPM: desenhamos o processo, simulamos, otimizamos e automatizamos o processo. Nesse momento da automatização, surgiu uma outra tecnologia, a SOA. Percebemos que tudo o que queremos automatizar, numa empresa como a Caixa, de 146 anos, com 500 sistemas corporativos, já está implementado em algum lugar.
Nosso trabalho foi identificar os serviços nos sistemas legados, conectá-los numa infra-estrutura de barramento, que suporta a tecnologia SOA, para utilizá-los como serviço.
Integramos plataformas alta, média e baixa, integramos sistemas legados com tecnologia Java, Cobol e Visual Basic, integramos os bancos de dados DB2, Oracle, Sybase e SQL Server.
Na nossa avaliação, é um projeto de maturidade 5, numa escala de 1 a 7; só não chegamos ao nível 6 ou ao nível 7 porque ainda não usamos a tecnologia grid.
Em termos de resultados, reduzimos o tempo de execução desse processo campeão, do começo ao fim, em mais ou menos dez vezes, com uma série de benefícios a mais em relação ao processo anterior. Antes, o operador precisa acessar mais de um sistema; hoje ele usa uma única interface. Já conseguimos medir os resultados e a facilidade na operação. E com isso a gente consegue vender BPM e SOA para a Caixa.
Nos preocupamos agora com o número de transações. Estamos chegando à marca de 1.200 transações por segundo.

Mariano — Na Liberty, sou muito mais ligado à arquitetura em si do que ao desenvolvimento. Desde o ano passado a gente discute SOA e BPM na Liberty; cada país tem uma independência muito grande em termos de tecnologia. Logo, a discussão sobre qual tecnologia adotar e como implementá-la depende de cultura para cultura. No Brasil, somos arrojados na tecnologia, mas, durante esse processo de discussão, descobrimos que não vale a pena entrar forte, em especial na SOA.
Então resolvemos otimizar nossa arquitetura, baseada em Java e .NET, e transformar tudo o que temos em serviços de infra-estrutura e em serviços aos negócios, serviços que sejam consumidos pelas aplicações que viermos a desenvolver. Já temos alguns exemplos de sucesso.
Temos um processo de sinistro importante para a operação da Liberty, e já automatizamos esse processo com um workflow muito bem escrito. Essa é a primeira parte do BPM: um workflow bem estruturado.
Não temos gestão de conteúdo, nem orquestração, nem facilidade para testes, testes de alteração nos fluxos do negócio, que os produtos de BPM nos oferecem.

Fabiano — Nossa empresa é jovem, tem sete anos, está crescendo, e convivemos até agora com uma solução caseira minimalista. Vivemos um conflito entre as demandas da empresa e nossa capacidade de atendimento. Problema de arquitetura foi o passo para falar seriamente de SOA na empresa; com a dificuldade de atendimento, ficou mais fácil mostrar o problema.
Começamos então a falar de processos para os negócios, sem recorrer à figura do analista de negócios (até parece que o analista de sistema é um ser humano incapaz de se comunicar com o negócio).
A tecnologia fez um pouco esse meio de campo entre a tecnologia e a empresa, por causa de XML, por causa dessas adições de significado, de semântica.
Curiosamente, ao dar uma resposta com a tecnologia, vemos problemas na empresa: precisamos alinhar a TI aos negócios, como diz o clichê (como se a tecnologia vivesse alienada do negócio), mas vemos que precisamos alinhar o negócio à estratégia.
Por que tudo isso? Porque não fizemos a lição de casa: os processos não estão bons ainda, não estão maduros.
Então, hoje nós tocamos um projeto de SOA, partindo da infra-estrutura. Ora, já que precisamos ajudar a empresa a estabilizar sua visão dos processos, vamos então atacar pelo não-funcional.
Estamos fazendo um trabalho de desenho e redesenho de processos de negócio, de mapeamento, isso numa gestão conjunta, eu e o gerente responsável pela área de processos e de qualidade. No futuro, a idéia é convergir SOA com BPM.
Fazemos tudo isso patrocinados pela presidência da empresa. Por exemplo, congelei o backlog [a lista de projetos na fila de espera] para dar foco nesse trabalho de SOA. Meu compromisso é agir rapidamente e incluir esse backlog como requisito funcional no novo sistema. Esse desafio pode custar minha cabeça.

José Roberto — Na Aços Villares, iniciamos em 2006 um trabalho bastante focado em BPM. Montamos um grupo pequeno, debaixo da TI, para mapear os processos de negócio.
Um incômodo nessa área: o usuário chega dizendo que existe um problema no sistema, mas, quando vamos desvendar, ele mudou o processo e o sistema não foi desenhado para essa nova condição.
Por isso estamos criando uma base de conhecimento dos processos, ainda embrionária. Criamos um modelo para alguns processos.
Nos últimos três anos, a Villares investiu num ERP, fortaleceu as áreas de negócios, e, com base nessa iniciativa, estamos mapeando os processos, definindo a cadeia de valores. Precisamos analisar e montar um plano global de arquitetura para a empresa. Se não fizermos isso bem, nunca vamos quebrar o ciclo, de atender às demandas. Precisamos criar um repositório de serviços, ou de elementos de serviços, mas para isso preciso mudar um pouco o perfil da equipe de TI, para ficar mais próximo de um arquiteto.
Começamos com projetos de impacto, que sejam carro-chefe, porque na indústria concorremos com os investimentos no forno, na linha de produção. É difícil vender essa idéia de BPM e de SOA numa mesa em que outro diretor de negócios pede dinheiro para algo muito mais palpável.
Então, nossa estratégia é ter a visão completa, mas trabalhar por partes, para criar esse repositório, esse barramento de serviços.

Cláudio — Nesse negócio de fabricar carros, é vital sobreviver no mundo globalizado, porque os nossos competidores estão espalhados pelo mundo inteiro. É uma dificuldade organizar uma empresa que opera em 167 países.
Eu considero SOA uma filosofia.
Outro dia, um sistema ficou for do ar por um tempo considerável, então eu falei para o executivo da área: vamos fazer isso por um processo manual. Ele falou: não vamos não, porque não dá; do tamanho que está esse negócio, no manual ele não funciona mais, então vamos esperar.
Então, a TI não é mais uma unidade de serviços; ela é uma peça fundamental na operação de qualquer empresa. Sem a TI, muitas unidades da empresa não funcionam mais.
Desde que eu comecei na área de TI, deve fazer uns 32 anos, a gente fala de otimização dos processos, de mexer no processo antes de fazer o sistema. Mas, sem o pessoal de negócios do nosso lado para especificar claramente o processo, com SOA ou sem SOA, vamos ter problema na hora de construir a solução.
Uma coisa interessante da SOA: não precisamos trocar o legado por um sistema novo. SOA não significa remover, mas reutilizar. Já gastamos muito dinheiro removendo legados. Mas, até que a SOA esteja estável e até que demonstre seu valor, a gente vai continuar tentando remover os legados, porque a GM tem 126 anos.
Mas, quando a gente fala de SOA, fala de barramento, repositório, evento. Para mim, isso é infra-estrutura de TI; se eu falar disso com o pessoal de negócios, não consigo vender SOA. Acho mais fácil discutir com ele outras coisas. Até porque essa SOA não está funcionando direito, pelo que sei. O pessoal fala em barramento e não sei o quê, mas, quando põe o barramento para funcionar, começa a dar congestionamento dos dados.
Numa empresa como a minha, para colocar SOA e substituir tudo o que temos, vai levar talvez uns 20 anos. Nesse meio tempo surge a SOA 2, a SOA o Retorno. Precisamos aproveitar as coisas boas nessas arquiteturas, e ir tocando.

Walkiria — No Bradesco, a área de tecnologia mantém profissionais lotados nas unidades de negócios, capturando necessidades, identificando oportunidades, e formatando os pedidos para a construção de soluções.
No tema SOA e BPM, gosto mais de discutir os conceitos, do que discutir as questões tecnológicas, até porque os projetos fracassam porque não fica claro o que se pretende atingir com o projeto.
Na verdade, dentro do banco, discutimos essas questões há anos, mas os negócios ficam mais complexos, e as discussões ficam mais complexas também.
Há dez anos a maioria dos bancos faz análise de crédito praticamente em real time; isso exige rever os processos, as políticas, as variáveis de avaliação do crédito, e exige adicionar ferramental.
No Bradesco, discutimos até a semântica, para colocar cada função de negócio numa linguagem única. Isso faz parte do desafio contínuo de evolução da arquitetura. Tiramos a linguagem técnica para discutir os processos de negócios. Hoje, todos os executivos do banco têm uma visão clara do modelo macro de arquitetura.
A gente usa a palavra alinhamento nessa discussão, mas, na verdade, é uma construção em conjunto, lado a lado, inclusive a construção do linguajar.
Outro ponto crítico, concordando aqui com o Manel, é garantir a evolução do modelo, para que ninguém desenvolva alguma coisa por fora. A governança dessa arquitetura precisa ser forte; toda nova necessidade precisa ser discutida e apreciada. Mas uma visão compartilhada da arquitetura facilita o trabalho de governança, pois sabemos que, se mexemos em alguma coisa aqui, vamos interferir em alguma função de negócio ali.
Um ponto delicado é a estrutura: com essa nova filosofia, surgem novos papéis — o gerente de projetos, o arquiteto. Surge a necessidade de capacitar o pessoal.

Marcio — A evolução dos conceitos e das tecnologias é meio em espiral, e não cíclico. Eles passam de forma diferente pela gente; a gente olha e parece que a gente conhece, mas eles vêm com alguma coisa diferente. Em parte, isso acontece porque nós, os profissionais de TI, sempre buscamos novas soluções e novas tecnologias para resolver velhos problemas, os velhos problemas que não conseguimos resolver: agilidade, produtividade, qualidade, e outros problemas dessa ordem.
Não é que o problema não mude. O problema também se sofistica, se torna mais exigente. E é assim que eu vejo SOA e BPM. Na Prodam, pela convivência com os legados e pela diversidade de processos, planejamos alguns projetos-piloto.

Leão — Na Prodesp, criamos há pouco tempo uma área de sistemas internos. Temos uma fragmentação de sistemas muito grande dentro da Prodesp, e estamos trabalhando para acabar com essa fragmentação. Andamos tão ocupados tentando organizar a vida de nossos clientes que não tivemos tempo para organizar a nossa própria vida.
Então, essa é uma frente importante de trabalho, não só para os sistemas, mas também para os processos. Tenho falado isso para o pessoal da Prodesp: antes de dizer para os outros o que eles têm de fazer, vamos ver se conseguimos fazer a mesma coisa internamente, vamos usar a nós mesmos como um grande piloto, até para mostrar as metodologias utilizadas.
Levantamos os nossos principais processos e fizemos uma lista. Um deles precisava urgentemente de solução: era o nosso processo de licitação. Já conseguimos fazer em dois, cinco dias de trabalho o que antes levava 25, 80 dias de trabalho.
O pessoal usava computador, e todos os sistemas da empresa estavam à disposição do grupo, mas faltava compreender melhor os problemas alheios. Isso era mais crítico do que colocar fluxos dentro dos sistemas. O importante é o processo; a tecnologia é o suporte para que o processo funcione.
Mas os clientes da Prodesp dentro do estado não estão acostumados com isso: eles estão acostumados com a Prodesp fazendo sistema. Isso não é uma crítica, porque é fácil criticar. Deve ser assim em vários outros órgãos do Brasil. É impressionante o que tem de legado no governo.
E não existe uma visão do todo. Por isso temos de falar de SOA e de BPM.
Sempre que somos chamados, sugerimos o enfoque de aglomerar os processos, ou seja, de aglomerar os problemas que precisamos resolver, antes de sair correndo para enfrentar um por um.
Não há resistência interna dentro da Prodesp, o que ajuda bastante, porque encontrei lá pessoas ansiosas para trabalhar com esse tipo de coisa.
O cliente da Prodesp compra serviço da Prodesp porque não tem escolha; evidentemente, isso gera tensão. Se a gente faz alguma coisa errada... Então, estamos tentando ganhar o pessoal pela qualidade, mostrar que é prestação de serviço mesmo.
Estamos aprendendo como abordar a revisão dos processos, não na teoria, porque na teoria todo mundo sabe, mas na prática do governo.

IH — E como funciona a comunicação, a divulgação desses projetos complicados, sofisticados?

Manel — Fizemos um primeiro projeto para acreditar, para aprender. E depois até fizemos vários projetos assim. Tivemos de procurar na TI gente capaz de falar desses projetos sem cair nos barramentos, nos orquestradores. Dissemos para os outros executivos que precisaríamos deles para fazer um investimento grande e transformar a empresa, simplificar nossa vida, para mexer nessa quantidade de interfaces entre sistemas legados — e nem todas estão mapeadas, porque são o fruto de muitos anos de trabalho.
Nesse momento, temos líderes em cada uma das 18 operações regionais, com uma liderança mais forte supra-regional.

IH — Alguma empresa aqui mudou o organograma e, em vez de chefe de departamento, agora tem chefe de processo?

[TODOS — Não.]

Leão — Na Prodesp, montamos uma célula, com uma pessoa de tecnologia, uma de jurídico, uma de suprimentos, e o dono da demanda. Com todos sentados em torno da mesa, o trabalho sai mais rápido. Então, não eliminamos o processo, que permanece igual, mas eliminamos as interfaces, diminuímos o tempo que leva para a informação fazer o percurso.

Walkiria — Uma arquitetura bem desenhada ajuda a visualizar tudo isso, porque vamos sempre ter os departamentos especializados.

Rodrigo — A Caixa tem os vários departamentos num único processo, mas como os departamentos já existiam de longa data, cada departamento criou o seu sistema. E o atendente usava oito sistemas para fazer aquele processo de ponta a ponta.
A SOA nos proporcionou vislumbrar o processo do início ao fim, independente de departamentos, plataforma, banco de dados, etc.

José Roberto — Estamos pensando em montar uma área de apoio aos processos, como um escritório, para apoiar os gestores. Cada gestor muitas vezes enxerga só a sua área, mas não o que vem à jusante e à montante — muitas vezes as interfaces são obscuras.

Leão — Estou sugerindo na Prodesp a montagem de um grupo especializado em regras de negócio, inclusive com local físico separado, para assim dizer: aqui está a enciclopédia de regras de negócio do governo do estado.
Se a gente não sabe isso, a cada vez que contratamos um terceiro para nos fazer um sistema, corremos o risco de entregar um pedaço dessa memória de regras de negócio para o terceiro.

Rodrigo — Eu gostaria de compartilhar duas preocupações com vocês sobre BPM. Praticamente todo mundo trabalha com fábricas de software.
Se nós não soubermos reutilizar, as fábricas de software certamente saberão, e vamos pagar mais de uma vez pelo mesmo serviço.
Vejo muitos casos e muitos fornecedores falando de SOA, mas, quando vou olhar direito, não é SOA, é componentização. Isso é ruim. Precisamos diferenciar o que é SOA do que é componente; o nível de abstração é diferente.
Na Caixa, começamos com a modelagem do processo. Como era esperado, ele passa por oito departamentos, com oito sistemas diferentes. Quem é o dono do processo? É um conflito. E quais são as otimizações a fazer? Aí vem um trabalho de negociação: um produto entra, porque faz parte da estratégia empresarial; o outro não entra. É outro conflito.
Depois de mapear e de otimizar, então identificamos onde estão os serviços, em todo o legado, para fazer a implementação.

Cláudio — Com a reengenharia, nós acabamos com o O&M, quando na verdade a necessidade de manter os processos vivos e documentados ainda existe. Como vamos passar de novo por essa fase da SOA? Colocando os processos com os metadados corretos dentro do repositório, assim a gente mantém o conhecimento da empresa.

Fabiano — Temos essa visão clássica de primeiro definir tudo, ouvir tudo o que o usuário quer, e depois construir tudo. Quando assumi a área de TI, com meu kit de PMBoK nas mãos, vi que tinha entrado numa organização que se transforma o tempo todo. Resolvemos, para usar um clichê de mercado, abraçar a mudança. Existem várias técnicas, como a extreme programming. Isso deu certo.
Não dá para definir tudo antes por um motivo muito simples: o usuário precisa da construção para entender o que ele quer. Com a SOA, me parece, viabilizamos essas coisas, porque fica mais fácil transformar os processos.