ABC da SOA

O que é arquitetura orientada a serviços (SOA)?

Service-Oriented Architecture (SOA) – ou, em português, Arquitetura Orientada a Serviços – é um termo que descreve duas coisas muito diferentes. As duas primeiras palavras expressam uma metodologia para desenvolvimento de software. A terceira palavra é um panorama de todos os ativos de software de uma empresa, assim como uma planta arquitetônica é uma representação de todas as peças que, juntas, formam uma construção. Portanto, “service-oriented architecture” é uma estratégia que proclama a criação de todos os ativos de software de uma empresa via metodologia de programação orientada a serviços.

O que é um serviço?

Serviços são porções — ou componentes — de software construídas de tal modo que possam ser facilmente vinculadas a outros componentes de software. A idéia por trás destes serviços é simples: a tecnologia expressa de forma que o pessoal de negócio possa entender, e não como um aplicativo enigmático.

No centro do conceito de serviços está a idéia de que é possível definir partes dos códigos de software em porções significativas o suficiente para serem compartilhadas e reutilizadas em diversas áreas da empresa. Com isso, algumas tarefas passam a ser automatizadas – por exemplo, enviar uma query para um website de relatório de crédito para descobrir se um cliente se qualifica para um empréstimo. Se os programadores em um banco puderem abstrair todo este código em um nível mais alto (isto é, pegar todo o código que foi escrito para realizar a verificação de classificação de crédito e reuni-lo em uma única unidade chamada “obter classificação de crédito”), eles poderão reutilizar esta porção da próxima vez que o banco decidir lançar um novo produto de empréstimo que requeira a mesma informação, ao invés de ter que escrever o código a partir do zero.

Para chegar a isto, os desenvolvedores criam um invólucro complexo em torno do código empacotado. Este invólucro é uma interface que descreve o que a porção faz e como conectar a ele. É um conceito antigo, que data dos anos 80, quando a programação orientada a objetos surgiu. A única diferença é a demanda atual por objetos de software muito maiores e mais sofisticados.

Na operadora norte-americana Verizon, por exemplo, o serviço “get CSR” (get customer service record, obter registro de serviço ao cliente) é uma miscelânea complexa de ações de software e extrações de dados que emprega infra-estrutura de integração da empresa para acessar mais de 25 sistemas em quatro data centers ao redor do país. Antes de criar o serviço “get CSR”, desenvolvedores da Verizon que precisavam desta porção crítica de dados tinham que criar links para todos os 25 sistemas — acrescentar seus próprios links sobre a teia complexa de links que já pendiam dos sistemas populares. Porém, com o serviço “get CSR” situado em um repositório central na intranet da Verizon, estes desenvolvedores agora podem usar o simple object access protocol (SOAP) para criar um único link para a interface cuidadosamente elaborada ao redor do serviço. Estes 25 sistemas entram em fila e marcham imediatamente, enviando informação do cliente para o novo aplicativo e poupando meses, ou mesmo anos, de tempo de desenvolvimento dos desenvolvedores cada vez que eles usam o serviço.

Existem muitas maneiras diferentes de conectar serviços, como links de programação customizados ou software de integração de fornecedores, mas, desde 2001, um conjunto de mecanismos de comunicação de software conhecido como web services, criados sobre a onipresente World Wide Web, tornou-se um método cada vez mais popular para integrar componentes de software.

Qual é a diferença entre SOA e web services?

SOA é a arquitetura abrangente para criar aplicações dentro de uma empresa — pense em um projeto arquitetônico — mas, neste caso, a arquitetura demanda que todos os programas sejam criados com uma metodologia de desenvolvimento de software específica, conhecida como programação orientada a serviço. Web services são um conjunto de mecanismos-padrão de comunicação criados sobre a World Wide Web. Ou seja, os web services são uma metodologia para conectar e comunicar. Enquanto SOA é uma estratégia de TI.

Como sei se devo adotar uma estratégia SOA?

Sendo uma estratégia arquitetural, SOA envolve muito mais do que o mero desenvolvimento de software. A criação de uma arquitetura baseada em um portfólio de serviços demanda que os CIOs elaborem um “case” convincente para uma arquitetura corporativa, uma metodologia de desenvolvimento centralizada e uma equipe centralizada de gerentes de projeto, arquitetos e desenvolvedores. Também requer um CEO e uma equipe executiva dispostos, que preparem o terreno para que o pessoal de TI possa mergulhar em processos core da empresa. Entender estes processos e conquistar adesão para o compartilhamento corporativo são a pedra angular de uma transformação do negócio baseada em SOA.

Governança é vital. Para que os serviços sejam reutilizados na empresa, tem de haver uma metodologia de desenvolvimento de software única e centralizada de modo que áreas diferentes não criem o mesmo serviço de maneiras diferentes ou usem conectores incompatíveis. Tem que haver um repositório centralizado para que os desenvolvedores saibam onde procurar serviços — e TI saiba por quem eles estão sendo utilizados. Os serviços têm de ser bem documentados para que os desenvolvedores saibam para que eles servem, como integra-los e as regras para usá-los. Algumas empresas, por exemplo, cobram taxas de utilização dos serviços e criam acordos de performance para garantir que os serviços funcionem bem e não sobrecarreguem a rede corporativa.

A maioria das empresas que avançou no caminho para SOA criou um grupo de arquitetura centralizado para escolher processos que serão capacitados para serviço e consultar áreas diferentes da empresa para criar os serviços específicos. O grupo centralizado também cria um mecanismo conveniente para governança. Se todas as solicitações de serviço têm de passar pelo grupo de arquitetura, as metodologias de desenvolvimento de serviço, os projetos e os acordos de performance podem ser gerenciados mais facilmente.
As empresas que tiveram mais êxito com SOA até agora são as que sempre tiverem êxito com tecnologia: grandes empresas com grandes budgets para TI cujo negócio é baseado em tecnologia (serviços de telecomunicação e financeiros). Elas também tendem a ter líderes de negócio envolvidos com a área de TI e dispostos a apoiar seus projetos. Para empresas sem estas vantagens, SOA talvez não seja tudo o que promete.

Para empresas menores, empresas que apostaram alto em pacotes de aplicativos integrados e empresas que já adotam estratégias sólidas de integração de aplicativos, SOA não tem a ver com “quando”, mas com “se”. Os CIOs têm de ser cuidadosos porque, na arquitetura orientada a serviços, os elementos “desenvolvimento de serviço” e “planejamento de arquitetura” são distintos, porém não independentes — precisam ser considerados e executados paralelamente. Serviços que são criados isoladamente, sem levar em conta as metas de arquitetura e de negócio da empresa, podem apresentar pouco potencial de reutilização (um dos benefícios mais importantes da SOA) ou fracassar por completo.

Quais as vantagens da SOA?

Antes de mais nada, os benefícios de da arquitetura orientada a serviços devem ser contextualizados. Se sua empresa não for grande ou complexa, isto é, se não tiver mais de dois sistemas primários que exijam algum nível de integração, é improvável que o modelo proporcione grandes benefícios. Em meio a todo o hype atual em torno da SOA, esquece-se facilmente que a metodologia de desenvolvimento em si não traz vantagens – é o efeito que ela tem sobre uma infra-estrutura redundante e complexa que o faz. Os arquitetos dizem que a criação de um bom aplicativo orientado a serviços envolve mais trabalho do que a tradicional integração de aplicativos. (Pesquisas mostram que SOA está sendo usada para integração tradicional de aplicativos na maioria das empresas.) Assim, o desenvolvimento da SOA gera um custo inicial extra. Para que este trabalho produza benefícios, portanto, SOA tem que eliminar trabalho em outro ponto qualquer, já que a própria metodologia não gera benefícios para o negócio. Assim, o primeiro passo é descobrir se existem aplicativos redundantes e mal integrados que poderiam ser consolidados ou eliminados como resultado da adoção. Se este for o caso, então há benefícios potenciais.
Para entender o panorama geral dos benefícios apregoados por SOA, você precisa examiná-lo em dois níveis: primeiro, as vantagens táticas do desenvolvimento orientado a serviços e, segundo, as vantagens da SOA como estratégia de arquitetura global.

Vantagens do desenvolvimento orientado a serviços:

1. Reutilização de software.

Se o pacote de códigos que constitui um serviço tiver o tamanho e o escopo certos (um grande “se”, dizem os veteranos em SOA), então ele poderá ser reutilizado da próxima vez que a equipe de desenvolvimento precisar de uma função específica para um novo aplicativo que queira desenvolver. Digamos que uma empresa de telecomunicações tenha quatro divisões diferentes, cada qual com seu próprio sistema para processar pedidos. Todos estes sistemas executam determinadas funções similares, como verificações de crédito e buscas de registros de clientes. Mas, tendo em vista que cada sistema é altamente integrado, nenhuma destas funções redundantes pode ser compartilhada. O desenvolvimento orientado a serviços coleta o código necessário para criar uma versão de “verificação de crédito” que possa ser compartilhada pelos quatro sistemas. O serviço pode ser uma porção de software totalmente nova ou um aplicativo composto, consistindo de código de alguns dos sistemas ou de todos eles. De qualquer forma, o ‘composite’ é envolto por uma interface que oculta sua complexidade. Da próxima vez que os desenvolvedores quiserem criar um aplicativo que exija verificação de crédito, vão criar um link simples para o novo aplicativo. Eles não precisam se preocupar em conectar aos sistemas individuais — na realidade, nem precisam saber como o código foi incluído ou de onde ele vem. Só precisam criar uma conexão para ele.

Em uma empresa que desenvolve constantemente sistemas novos que se apóiam em funcionalidade similar — uma empresa seguradora com muitas divisões diferentes, cada uma com produtos ligeiramente diferentes, por exemplo, ou uma empresa que está sempre adquirindo outras — o tempo economizado nas tarefas de desenvolver, testar e integrar esta  mesma funcionalidade de software é uma vantagem.

Mas a reutilização não é garantida. Se desenvolvedores em outras partes da empresa não souberem que os serviços existem ou não confiarem que eles são bem construídos, ou se as metodologias de desenvolvimento variarem dentro da empresa, os serviços podem definhar e não se repetir. As empresas adeptas da reutilização desenvolveram mecanismos de governança — equipes de desenvolvimento centralizadas, metodologia única de desenvolvimento e repositórios de serviços — para aumentar suas chances de reutilização.

Às vezes, porém, o serviço simplesmente não é bem projetado. Ele não realiza operações suficientes para ser amplamente aplicável na empresa ou tenta realizar operações demais. Ou os desenvolvedores não levaram em conta que outros possam querer usar o serviço de maneiras diferentes. Para profissionais experientes no assunto, o dimensionamento adequado dos serviços —  também conhecido como granularidade — é tanto uma arte quanto uma ciência, e a má-granularidade pode reduzir drasticamente as possibilidades de reutilização. Pesquisas do Gartner estimam que apenas algo entre 10% e 40% dos serviços são reutilizados.

2. Aumentos de produtividade.

Se os desenvolvedores reutilizam serviços, os projetos de software podem andar mais rápido e a mesma equipe de desenvolvimento pode trabalhar em mais projetos. A integração se torna mais barata (no mínimo 30%, de acordo com estimativas do Gartner) e mais rápida, eliminando alguns meses dos ciclos de desenvolvimento de novos projetos. Shadman Zafar, vice-presidente sênior para arquitetura e e-services da Verizon, diz que seu catálogo de serviços dispensou-o de montar uma equipe de projeto para o desenvolvimento de um processo de pedido de linha telefônica porque os serviços necessários para compor o processo já existiam. “Com integração ponto a ponto, teríamos uma equipe de projeto central criando a integração geral e equipes locais para cada um dos sistemas ao qual precisávamos integrar. Com o processo de pedido de linha telefônica, tínhamos uma única equipe focada quase que inteiramente em teste de uma ponta a outra”, explica. Isso poupa tempo e recursos e melhora a qualidade de novos aplicativos, porque o teste não é mais o último obstáculo de um processo de desenvolvimento de aplicativos exaustivo; ele é o foco.

3. Maior agilidade.

Mesmo que os serviços não sejam reutilizados, podem agregar valor se facilitarem a modificação de sistemas de TI. Na ProFlowers.com, por exemplo, não existem aplicativos redundantes ou múltiplas unidades de negócio clamando por serviços. Mas, com a divisão do processo de pedido de flores em serviços discretos, cada componente pode ser isolado e modificado conforme o necessário para lidar com os picos de demanda que acontecem em datas festivas, segundo Kevin Hall, CIO da ProFlowers. Quando a ProFlowers tinha apenas um aplicativo monolítico encarregado do processo, uma única alteração no processo ou um crescimento do volume de transações (no dia dos namorados, por exemplo) exigia que o sistema inteiro fosse recriado.

No novo sistema, os servidores reagem aos picos de atividade durante cada fase do processo de pedido, transferindo capacidade para o serviço específico que está precisando mais dela. O sistema está muito mais previsível e não houve interrupções desde que o processo capacitado por serviço foi implantado, no início de 2002, de acordo com Hall. “Visto que podemos escalar horizontalmente [mais servidores] e verticalmente [dividindo os serviços], não tenho que comprar hardware de acordo com as cargas mais altas”, afirma.

Vantagens de uma estratégia SOA:

1. Melhor alinhamento com o negócio.

A arquitetura orientada a serviços é o panorama geral de todos os processos e fluxos de negócio de uma empresa. Significa que o pessoal de negócio pode visualizar, pela primeira vez, como a empresa é construída em termos de tecnologia. Quando projetos de TI são apresentados em termos de atividades e processos de negócio e não na forma de aplicativos complexos, o pessoal de negócio pode apreciar e suportar melhor os projetos de TI. “Quando eu disse que tínhamos 18 versões de ‘verificação de crédito’ ligeiramente diferentes embutidas em aplicativos diferentes, em agências diferentes, os diretores das agências entenderam por que era problemático e apoiaram a criação de uma única versão que fosse usada por todos”, recorda Matt Miszewski, CIO para o estado de Wisconsin.

A visão grandiosa da SOA é que, quando TI capacitar plenamente para serviços os processos importantes de um negócio, o pessoal de negócio poderá assumir controle sobre modificar e mesclar os diferentes serviços em novas combinações de processo próprias. Mas esta visão ainda está a muitos anos de distância.

2. Uma maneira melhor de vender arquitetura para o negócio (e TI).

Há tempos a arquitetura corporativa tem sido o conceito que não ousa dizer seu nome. Alguns CIOs chegam ao ponto de não usar o termo com os colegas por medo de assustá-los, perdê-los ou simplesmente entediá-los. Arquitetura corporativa sempre foi uma empreitada grande, complexa e cara. Seu ROI, com freqüência, é nebuloso para o negócio. Padronizar, mapear e controlar ativos de TI não torna o negócio claramente mais flexível, capaz ou lucrativo. Como resultado, os esforços de arquitetura de TI muitas vezes fracassam ou se tornam completamente centrados em TI. A arquitetura orientada a serviços proporciona o valor ao negócio que, na velha arquitetura corporativa, raramente passava de uma vaga promessa. Reutilização, maior produtividade e agilidade em TI e uma infra-estrutura de software ajustada para processos de negócio específicos são as iscas para vender uma iniciativa de arquitetura corporativa para o negócio. Mas lembre-se de que arquitetura não é para todos. Empresas pequenas ou empresas extremamente descentralizadas talvez não consigam justificar uma equipe centralizada de gerentes de projeto, arquitetos e desenvolvedores.

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.

Fonte: CIO

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

Deixe um comentário

O seu endereço de e-mail não será publicado.