Sem Parar:arquitetura ágil

Diante do crescimento acelerado do Grupo STP, que administra o sistema de pagamento automático de pedágios e estacionamentos Sem Parar/Via Fácil, a empresa optou por ter uma arquitetura de TI orientada a serviços. Mas, diferente do que ocorre normalmente, as soluções operacionais ainda não existem e estão sendo criadas para compor o modelo de camadas. Como se não bastasse essa inovação, o departamento de TI resolveu criar a série por meio de desenvolvimento ágil.

Fabiano Borges, gerente de desenvolvimento organizacional e tecnologia da informação do Grupo, diverte-se com a quantidade de quesitos inusitados em seu projeto: “Estamos estimulando o caos organizado, nossas paredes estão repletas de anotações e gráficos e há muito compartilhamento.” 

O grande objetivo de toda a “confusão” criada por ele é o ganho de agilidade e velocidade. “Temos a meta de chegar ao final do ano com velocidade de modificação de software 50% menor. Isso será um benefício não só desenvolvimento ágil, mas principalmente da SOA. Ao invés de tijolos, teremos blocos pré-fabricados,” prevê. Segundo ele, a maior qualidade do desenvolvimento ágil é – apesar do nome do modelo- a qualidade e não a velocidade: “Com o usuário mais perto e mais chances de acertar.”

O projeto de SOA da Sem Parar não tem nada a ver com a tradicional história de integração de sistemas legados. “O que fazemos é um projeto grande de novas plataformas de aplicações. Todas nascem com uma visão orientada a serviços porque assim teremos um ambiente homogêneo e mais simples de progredir conforme os negócios e os produtos da empresa evoluírem,” explica Borges.

Nesse processo, a elevação do faturamento – de R$ 1,7 bilhão, em 2006, para R$ 2,1 bilhões em 2007, com crescimento de 23,5% – é um bom indicativo do nível de pressão que a área de TI sofria para entregar aplicativos, quando decidiu que deveria investir em uma mudança cultural radical e partir para o desenvolvimento ágil.

A idéia é favorecer projetos para pequenas implementações e que proporcionem feed-backs para os demais. “O primeiro passo foi olhar a infra-estrutura de software desejada. Durante um mês e meio, não desenvolvemos nada, fizemos planejamento e hipóteses” detalha Borges.

Segundo ele, a equipe manteve em mente a idéia de desacoplamento dos componentes. A noção de arquitetura em que todos os elementos sejam totalmente desacoplados e que as informações fluam por meio de mensagens.
 
“Queríamos uma arquitetura em camadas não só na infra-estrutura, mas também na decomposição das características de negócio para permitir composições. É a idéia de lego de negócios para evoluir para BPM,” afirma o gerente de TI da Sem Parar.

Ao mesmo tempo em que a TI faz seus planos e inicia o desenvolvimento dos aplicativos, rola paralelamente no Grupo a revisão do BPM, que gera os requisitos para futuramente serem implementados na plataforma.

E, enquanto parte dos processos são implementados, outros estão em fase de desenho, em uma espécie de ciclo de retro-alimentação. “Quando recebemos indicações de processos, tentamos ver como se generaliza, para que se tenham os layers adequados e seja bem apoiado na plataforma, além de possibilitar que processos da mesma categoria sejam gerados rapidamente,” afirma.

Segundo ele, a criação da SOA por meio de desenvolvimento ágil tem sido, principalmente, generalizar os requisitos atuais para assimilar novas versões e modificações de negócio que ocorrerão no futuro.

O projeto da Sem Parar é uma “jornada de longo prazo” e deve ser concluída no final deste ano. Essa primeira fase abrange todo o ciclo de processamento de transações, desde os conveniados até o final do processo de negócio.

No próximo ciclo, o departamento que caminhar para sistemas que respondam a um modelo de negócio mais genérico. “Hoje falamos de passagem, mas precisamos mudar o conceito para transação porque no futuro processaremos a venda de outros produtos. Atualmente, vendemos seguro, mas ainda tratamos de maneira diferente,” explica o gestor.

Em paralelo, outra frente da TI tratará do cadastro de clientes, como se fosse um CRM. “Queremos que ele deixe de ser uma parte do processo, mas um domínio dedicado,” afirma Borges, “o restante são integrações com ERP, logística de identificadores, mas são de apoio”.