
Integração de software
• John L. Forman
A Lei de Moore diz que a evolução do hardware é de tal ordem que a cada 18 meses dobra-se a capacidade computacional dos processadores caindo pela metade o seu preço. Essa curva tem sido observada já há diversos anos e deve assim permanecer por pelo menos outros dez.
No software a evolução não acontece no mesmo ritmo, mas ainda assim o passo é acelerado. Eu diria que a cada dez anos passamos por uma completa reformulação de como software e sistemas são desenvolvidos. Pensando em termos de sistemas operacionais podemos ver que o intervalo entre o surgimento e o declínio quase que absoluto dos “líderes” de mercado se aproxima bastante deste número de anos. Lembram-se do CPM e do DOS? No caso do Windows, o nome continua o mesmo, mas o código: Quanta diferença!
Em cima de diferentes sistemas operacionais foram também sendo desenvolvidos outros tantos componentes, tais como bancos de dados, aplicações etc. A cada novo ciclo evolutivo do software, mais vantajoso se tornava informatizar um determinado departamento ou setor da empresa. Até que em um determinado momento começou a não fazer mais sentido ter sistemas espalhados e independentes. Como justificar a digitação de uma mesma informação repetidas vezes em inúmeros sistemas de uma mesma empresa?
Foi nessa época que começaram a ganhar espaço os sistemas de ERP. Prometiam aplicações capazes de satisfazer uma organização de ponta a ponta, acabando com o problema de integração de dados tão logo fossem completamente implantados. Milhões foram gastos em iniciativas desse tipo, até porque a conversão de sistemas heterogêneos em um suposto sistema unificado é tarefa para mais de ano. Mas durante tal transição a empresa ou corporação precisava continuar operando...
Por conta disto, eram comuns ajustes específicos no ERP para atender particularidades de uma determinada organização. Nada melhor que um sistema personalizado desde que o ERP não fosse nunca evoluir. A cada nova versão do ERP as “customizações” desenvolvidas sob medida passavam de solução à dor de cabeça, tumultuando a implantação da nova versão que precisava ser compatibilizada com tais “customizações”. Não foram poucos os projetos de implantação de ERP que jamais foram concluídos.
Mesmo nas organizações onde sistemas de ERP entraram em operação plena começaram a surgir novas necessidades incapazes de serem atendidas pelo ERP. Por um motivo ou por outro, fato é que um novo sistema específico acabava sendo desenvolvido, sistema este que precisa trocar dados com o ERP. Já no caso de fusões e aquisições, como fazer para garantir a comunicação de dados entre dois ERP diferentes, utilizados por companhias que se fundiam em uma única corporação?
Como podemos ver, o problema de integração de dados, apesar de significativo avanço, continua sem uma resposta definitiva. Até porque não se trata apenas da integração de dados, mas também da integração de aplicações e até mesmo da integração de corporações. No mundo globalizado e interconectado de hoje, é preciso que empresas sejam capazes de trocar informações permanentemente, muitas vezes sem intervenção humana.
No Brasil, onde inúmeros negócios somente agora começam a considerar o uso de computadores, pode-se dizer que a integração é um problema menor. Quem adquire uma solução integrada de um único fornecedor a principio não teria que se preocupar com nada, já que o fornecedor já teria resolvido este problema. Mas ai o problema pode ser de outra natureza: ficar irremediavelmente atrelado as soluções daquele fornecedor de software. Qual seria a contingência num caso desses? Existirá alternativa possível uma vez que a concentração do setor de software se torna cada vez maior?
E mais, essa questão de integração, apesar do número crescente de padrões abertos para troca de dados, continua razoavelmente imatura. Dentre as ofertas de sistemas abrangentes e integrados, a imensa maioria não foi concebida e construída de forma integrada. São na realidade sistemas independentes que estão sofrendo manutenção que permita algum tipo de integração, ainda que demandando a replicação de dados e equipamentos, e muitas vezes comprometendo performance e/ou confiabilidade.
Mas é claro que o mundo da TI não poderia deixar um problema sem resposta. Surge no horizonte uma nova esperança: SOA. Ou melhor, Services Oriented Architecture, que pode ser traduzido para Arquitetura Orientada a Serviços. Diversos fabricantes de software dirão que isso não é uma esperança e sim uma realidade. Com o advento da internet seria possível agora integrar qualquer sistema a uma camada intermediária de serviços (web-services).
Desse modo seria possível construir uma camada ao redor da funcionalidade de qualquer sistema, atual ou legado, disponibilizando essa funcionalidade através de um serviço web. Isso resultaria em uma quantidade enorme de serviços web, disponíveis para serem utilizados na criação de aplicações flexíveis e integradas. Seria necessário apenas coordenar a interligação e execução desses serviços, e para tanto está se criando toda uma notação para representação de tais serviços ou funcionalidades, que em última análise seriam os processos de negócio de cada organização.
Temos então o BPMN, ou Business Process Management Notation, bem como o BPEL, ou Business Process Execution Language. Em tese, a integração de qualquer corporação seja internamente, seja com seus parceiros de negócio, passa pela modelagem dos processos de negócio dessa corporação. Cada elemento de cada processo poderia ser mapeado em serviços web, sejam eles construídos desse modo, ou na verdade o encapsulamento na forma de um serviço web, de uma funcionalidade qualquer, de um sistema já existente.
Tanto o J2EE quanto o .Net permitem a criação de soluções como as acima descritas. Agora com a aproximação da Sun e da Microsoft, ambas as arquiteturas possivelmente se tornarão ainda mais compatíveis. Mas o esforço para disponibilizar sistemas legados em serviços web também não é pequeno. A evolução continua e certamente este mercado se tornará mais maduro. Não duvido que a integração via SOA vai resolver uma série de problemas que atualmente são enfrentados pelas grandes corporações quando precisam integrar seus sistemas e operações. Mas é bem possível também que novos problemas surjam, estimulando mais um ciclo evolutivo e a criação de soluções para problemas que hoje nem sequer existem.


• John L. Forman é diretor da Tecso Informática. Engenheiro de Computação pela PUC-RIO (1988) com mestrado em Engenharia de Software também pela PUC-Rio (1992). Pós-graduado em Gestão Empresarial pela COPPEAD/UFRJ (1995). Especialista na gestão de projetos de desenvolvimento de Software, especialmente nas áreas de Educação e Saúde. Membro titular da Sociedade Brasileira de Informática em Saúde, atualmente é vice-presidente da Associação das Empresas Brasileiras de Tecnologia da Informação, Software e Internet - Regional do Rio de Janeiro (Assespro-RJ), bem como do Sindicato das Empresas de Processamento de Dados, Software e Serviços Técnicos de Informática do Estado do Rio de Janeiro (Seprorj).
Clique aqui para mandar uma mensagem para esta coluna
|