ABC da SOA

Como equilibrar a necessidade de planejamento de arquitetura em SOA com a necessidade de provar o valor para o negócio rapidamente?
Planejamento arquitetural consome tempo. O desenvolvimento orientado a serviços, baseado em princípios de programação conhecidos e padrões de tecnologia amplamente disponíveis (SOAP, HTTP e assim por diante), pode ser muito mais veloz. Mas os dois têm que acontecer paralelamente, ensinam os especialistas. “Fazemos projetos de desenvolvimento conforme o necessário e, paralelamente, temos um projeto plurianual, mais longo, de mapear os processos e criar serviços no nível corporativo”, diz Kurt Wissner, diretor de arquitetura corporativa e desenvolvimento da American Electric Power (AEP). “As pessoas precisam ver o benefício da SOA muito rapidamente. É por isso que gosto de projeto; do contrário, você não tem nada tangível para vender a ninguém sobre a razão de fazer o que está fazendo.” Ajudaria ter o plano arquitetural e o mapeamento de processo implantados antes de criar os serviços (para aumentar as chances de reutilização), mas o planejamento de arquitetura não apresenta retorno no curto prazo, o que pode ser devastador. “Tentei um plano ambicioso demais em outra empresa e fracassei”, lembra Wissner. “Criamos um grande plano de arquitetura de milhões de dólares que duplicou o que já tínhamos. O plano não apresentou muito valor em relação à integração ponto a ponto tradicional e nossos esforços não deram em nada. Se você já começa com a empresa inteira, são muitos os riscos de fracassar.”
Ao abordar o planejamento empresarial em porções menores na AEP, Wissner pode se recuperar mais facilmente de revezes. “Tivemos tropeços, mas conseguimos tomar atitudes corretivas porque não era nada muito grande”, diz.

Como sei quais serviços vão gerar mais valor em troca do meu investimento?
Quando estiver em dúvida, comece com processos que envolvem clientes, afetam diretamente a receita e abordem um ponto nevrálgico da empresa. De acordo com pesquisa realizada em 2006 pelo Business Performance Management Institute, mudanças em necessidades e preferências de clientes são o principal motor de mudança em processos de negócio ou de adoção de novos aplicativos, seguidas por ameaças competitivas e novas oportunidades de receita. “Aplicativos de ponta são os que fornecem o maior valor para o negócio e têm um bom conjunto de requisitos de mudança que surgem com muita freqüência”, diz Daniel Sholler, vice-presidente de pesquisa do Gartner. “Se você puder aprimorar estes aplicativos em 10%, é melhor do que aprimorar aplicativos de nível mais baixo em 50%.” Obviamente, acrescenta Sholler, a SOA pode não fornecer mais valor do que um bom aplicativo empacotado, por exemplo. “Mas, se é algo que você mesmo teria que criar de qualquer forma, então tem que ser orientado a serviço.”

Como SOA vai afetar meu grupo de TI?
Se você tem uma empresa descentralizada, prepare-se para lutar. SOA leva à centralização. Na realidade, pede centralização. “Você precisa ter alguém liderando, você precisa ter um indivíduo ou uma pequena equipe gerenciando a arquitetura”, aconselha Mike Falls, engenheiro sênior de sistemas da Fastenal, empresa de suprimentos industriais e de construção. “Se for cada equipe por si, elas podem acabar adotando maneiras diferentes  de criar serviços. Você precisa de um grupo, um conjunto de pesquisas e alguém para garantir que os grupos de desenvolvimento se atenham à metodologia de desenvolvimento de serviço.”
À medida que o portfólio de serviços cresce, o processo de desenvolvimento pode começar a assemelhar-se a uma linha de montagem. “Transforma-se em uma fábrica”, diz Wissner, da AEP. “Você tem equipes de projeto diferentes através das quais canaliza o trabalho e elas podem aumentar e diminuir conforme o necessário.”
Depois que a “fábrica” SOA está produzindo a todo vapor, prepare-se para acrescentar mais gerentes de projeto, analistas de negócio e arquitetos à medida que a produtividade dos desenvolvedores aumenta, diz Haal, da ProFlowers. “Dois desenvolvedores agora podem fazer o trabalho de seis”, observa. “Isso significa que os arquitetos e gerentes de projeto estão se esforçando para acompanhar o trabalho dos engenheiros. Provavelmente estamos realizando 50% de trabalho a mais do que há três anos.”
Estes programadores precisam entender programação orientada a objeto e aplicativos distribuídos — o que implica investimentos em treinamento. Segundo pesquisa de CIO/Computerworld, apenas 25% dos entrevistados têm as equipes de que necessitam para adotar arquitetura orientada a serviços — 49% planejam ter ou já têm programas de treinamento para que a equipe atual trabalhe a todo vapor.