"A confusão dói - integração já não é um luxo, é necessário" - Henrique Ahnfelt

Está em: Imprensa

A noção de integração atingiu uma nova maturidade e, de alguma forma, está a chegar ao fim de um ciclo - integração pela unificação aplicacional (uma tecnologia) passou a integração de documentos (XML) e volta agora à integração aplicacional da diversidade (uma plataforma de partilha de serviços).

É engraçado como a informática consegue manter o cheiro de carro novo, ao fim de 50 anos de utilização ‘industrial’, uns 20-25 de utilização massificada e 10 anos de Internet. Talvez se deva ao seu ritmo desenfreado de desenvolvimento.

Mas a verdade é que esta atitude de coisa nova, não só mas também em conjugação com outros factores, tais como pressões de mercado, necessidades competitivas e outras, estamos em 2004 com uma grande herança na forma de “montes” de sistemas, adquiridos por todas as razões e mais alguma ao longo do tempo, principalmente nos fins dos anos 90.

Por essa altura, ainda uma época de grandes investimentos em desenvolvimentos à medida, a noção de arquitectura de sistemas prendeu-se principalmente com a resolução de três tipos de pressão: i) custos de manutenção da infra-estrutura de sistemas de suporte ao negócio, ii) o acesso multicanal aos sistemas base de negócio e iii) racionalização dos investimentos em desenvolvimento de sistemas. A noção arquitectónica resultante acabou por se concentrar também em três níveis de soluções: i) a centralização de infra-estruturas físicas, ii) a adopção de uma única tecnologia de desenvolvimento e iii) a escolha de uma plataforma de servidor aplicacional (para integrar os canais com os sistemas centrais).

Várias forças têm contribuído para estragar esta imagem. Primeiro tornaram-se incomportáveis os custos de desenvolver internamente tudo à medida. Por um lado porque a base tecnológica do que está feito se torna rapidamente obsoleta, quando os seus fornecedores mudam de paradigma ao triplo da velocidade que nós mudamos de carro. Por outro lado, a haver versões novas para acompanhar a concorrência, só se feito em casa. Acaba por não existir vantagens em desenvolver só numa tecnologia porque tem tudo de ser refeito de raiz em prazos relativamente curtos (tipicamente 3 anos). Segundo, demonstrou-se que o pressuposto não era correcto, ou seja, só porque todas as aplicações são construídas sobre a mesma tecnologia, seja Microsoft ou Java, isso não significa que se integram automaticamente ou que as arquitecturas aplicacionais se tornam iguais. Sistemas desenvolvidos numa lógica de silos funcionais com login, bases de clientes, interfaces humanos, etc. separados têm os mesmos problemas de integração (e manutenção) independentemente da tecnologia ser a mesma ou diferente (pior ainda se são vários integradores externos, na base do ‘melhor em cada concurso’, que fizeram cada um o seu sistema). E a maior parte do tempo de manutenção depende mais do conhecimento da estrutura e funcionalidades das aplicações do que de complexidades inerentes à linguagem utilizada. Terceiro, as pressões do negócio no fim dos anos 90 foram tais que se acabou por estragar a estratégia, em parte por causa dos sistemas ERP e CRM, mas também na implementação de produtos ‘best-of-breed’ para áreas funcionais específicas, tais como portais (Vignette, ATG, Interwoven, etc.) e nichos funcionais (sistemas de rating, gestão de produtos, etc.). Assim, a única coisa que segue a estratégia acabam por ser sistemas de nicho internos. Quarto, o mundo está cada vez mais complexo mas exige coisas cada vez mais simples e convenientes. Julgo que está claro para todos nós que existe uma relação proporcional inversa, eventualmente exponencial, entre a simplicidade do interface ou processo e a complexidade do sistema que lhe está subjacente.

Assim, chegámos a este século com um conglomerado de aplicações na cave, com custos de manutenção que crescem exponencialmente, com requisitos de negócio novos, integrados de forma a que todos os canais falam com o sistema central mas a mão direita não sabe o que faz a esquerda, aplicações que só mudam a martelo (tecnologia obsoleta, funcionalidades que deveriam ser partilhadas estão multiplicadas por n sistemas diferentes e desintegrados), múltiplos repositórios de informação sobre clientes, produtos, processos, etc. e, principalmente, com grande pressão sobre custos.

Está claro, hoje, que no desafio da integração o que está em jogo não é a uniformização da diversidade mas sim a integração dessa diversidade. Como já se referiu parcialmente antes, está em jogo a criação de flexibilidade no sentido de eliminar os entraves que os sistemas colocam: i) a mudanças estratégicas da empresa, na forma, na velocidade e no custo, ii) a capabilidade de integrar transversalmente os canais e oferecer para fora uma imagem e processos coesos e, por fim, iii) a redução dos custos, quer os da manutenção quer os incrementais / marginais que resultam de novos desenvolvimentos.

A solução passa pela transformação do modelo bidireccional da integração tecnológica ad-hoc, que resulta num número de integrações que é o factorial do número de sistemas menos um (para 10 sistemas isso significa 362.880 ligações (!) e cada mudança de regra de negócio tem impacto em potencialmente todas as integrações), para infra-estruturas arquitectónicas de integração em estrela com uma ligação por sistema, com integração de documentos e com integração de serviços – hoje os standards serão XML e Web Services respectivamente.

No entanto, qualidade é qualidade – há integrações que funcionaram em 1998 e há projectos que vão falhar em 2004. Integração de sistemas é um assunto de execução eminentemente técnica mas os factores condicionantes da sua arquitectura são as capabilidades da empresa, não as qualidades da tecnologia – estas são só os factores condicionantes para a escolha de tecnologia. Portanto, enquanto forem técnicos a decidir a estratégia de IT, o mais provável é que o barato continue a sair caro, se bem que com cheiro a carro novo e uma pintura metalizada multi-camada impecável. Mas isso será outra conversa.
Henrique Ahnfelt
Principal - Capgemini
Publicado em: Semanário Económico - 23/01/2004