SOA não é tecnologia

O termo service-oriented architecture (SOA), ou arquitetura orientada a serviços, ainda não estava na moda em 2002, quando a TrueCredit, subsidiária da empresa de verificação de crédito TransUnion, começou a implementar um portal corporativo. As metas do CIO Scott Metzger eram simples: identificar processos de negócio e funções de TI a serem fornecidos através do portal e reutilizar software onde possível para reduzir o custo de desenvolvimento e acelerar a implementação.
Mas Metzger logo percebeu que o esforço ia além desta aplicação – era uma desculpa excelente para começar a mapear os processos de negócio mais importantes da empresa e criar uma arquitetura que permitiria a TI desenvolver e modificar as aplicações de suporte facilmente à medida que as necessidades do negócio mudassem. Chame de SOA ou do que quiser, diz Metzger, mas, para ele, a mudança de mentalidade iniciada com a aplicação portal representou uma virada no relacionamento de TI com o negócio. “Agora temos uma relação muito mais próxima com o negócio. É uma ótima maneira de unificar a organização”, afirma. Uma pesquisa realizada em março de 2006 por CIO e Computerworld mostra que 77% das empresas usuárias de SOA buscam maior flexibilidade no negócio.
Em seu momento eureca!, Metzger também vislumbrou uma estratégia-chave que o guiou em sua iniciativa SOA desde então: “Não se trata de um road map de tecnologia, mas de um business plan. Encontre uma maneira de articular o real processo de negócio independente de qualquer tecnologia. Assim você protegerá melhor seu investimento em SOA no longo prazo”. Em 2002, Metzger criou um gerenciador comum de portal e serviços para fornecer os vários serviços da empresa, incluindo processamento de crédito, gerenciamento de pagamentos e monitoração de crédito, internamente e para clientes externos.
Dada a importância dos processos em SOA, os CIOs devem abordar questões arquiteturais ao mesmo tempo em que consideram adquirir ou implementar uma infra-estrutura SOA, segundo Ron Schmelzer, analista sênior da ZapThink, empresa de pesquisa sobre SOA. “Você pode comprar uma infra-estrutura SOA, mas ela não será tão útil quanto poderia se não houver um plano arquitetural baseado em processo de negócio”, acrescenta.
Este foco em processo ao invés de na tecnologia específica permite que SOA cumpra a promessa do verdadeiro alinhamento entre TI e negócio. Por outro lado, impõe novos desafios aos CIOs, desafios estes que acabam por expandir as habilidades de TI em áreas antes cronicamente subdesenvolvidas: processo e planejamento arquitetural. As equipes também serão expandidas. Em resumo, os CIOs que esperam lidar com SOA da mesma maneira que sempre lidaram com implementações de tecnologia se arriscam a serem surpreendidos.

Desafio 1: implementar em etapas, mas elaborar um plano de longo prazo
SOA envolve anos de esforço para alcançar seu resultado máximo. E é por isso que os entrevistados da pesquisa de CIO/Computerworld citaram como principal preocupação o  desafio de migrar para uma arquitetura SOA e, ao mesmo tempo, satisfazer as necessidades de negócio atuais (63%).
O truque não é implementar SOA de uma tacada só, visto que, quando a maioria dos esforços expressivos finalmente estiver concluída, talvez as necessidades do negócio tenham mudado e grande parte da implementação esteja ultrapassada, de acordo com Sandra Rogers, diretora de programa para SOA, Web services e integração na empresa de pesquisa IDC (subsidiária do IDG, que publica CIO). O ideal é criar a arquitetura e implementar serviços específicos em fases, talvez enfocando um domínio de aplicação de cada vez ou escolhendo projetos com base na urgência do negócio. “Você pode criar de maneira incremental”, observa Suzanne Peck, CTO para o Distrito de Colúmbia, EUA. Em 1999, Peck começou a reorganizar 370 sistemas legados em nove grupos funcionais, como preparação para um novo SOA. Os serviços incluem novo código e interfaces baseadas em Web services para código legado, bem como novas aplicações compostas.
Mas, até você desenvolver a arquitetura subjacente, não poderá criar nada. “É importante pensar muito bem, logo no início, de que modo você vai gerenciar a versão 2 [de seus serviços] e além”, diz Metzger. “É importante entender a volatilidade de um processo de negócio específico.” 
Qualquer organização que esteja implementando SOA deve criar um modelo arquitetural básico para um aspecto gerenciável do negócio e aplicar este modelo de maneira oportuna a projetos individuais, usando-os para testar o modelo e implementar SOA em partes, explica Schmelzer, da ZapThink. Esta arquitetura inclui identificar todos os processos de negócio, as interações entre eles, as aplicações e funções específicas (existentes e necessárias) para implementá-los e o fluxo de lógica de negócio e dados para executar os processos de negócio. A identificação destes elementos permite que você entenda funções comuns que possam ser padronizadas em todos os processos e descubra quais são os requisitos de adequação regulatória, segurança e gerenciamento.