Retomada

Olá,

Retomando nossos trabalhos, proponho sugestão de leitura, relacionada a modelagem de SOA:

UML and SOA a beginners guide
Using UML service components to represent the SOA architecture pattern
Elements of Service-Oriented Analysis and Design
Service-oriented modeling and architecture

Nossa reunião de 20.03.2009

Evoluindo nos temas da reunião anterior, estabelecemos que a documentação deve ser constituída de uma documentação técnica e uma administrativa. A primeira para uso interno e a segunda para uso de gestão e por aqueles que vão consumir o serviço.

Será necessário estabelecer um catálogo de serviços similar ao modelo corporativo e a área potencial a manter a gestão desse catálogo é a de AD, por conta da larga experiência que a equipe tem em manter esse tipo de ativo.

Definiu-se que a responsabilidade do serviço é da área de negócio, assim, quem consome o serviço é que deve verificar inicialmente se há algum erro no uso do serviço. A área de negócio que provê o serviço deve ser acionada apenas se for constatada alguma inconformidade com a definição do serviço expressa no contrato.

Mais candidatos a serviços foram identificados, como webdoc, cartão e estruturas replicadas. Problemas que hoje são decorrentes da integração via banco de dados provavelmente poderão ser administrados muito mais facilmente com a estratégia de serviços.

Seria interessante documentar os seviços no repositório do PowerDesigner, talvez com diagrama de componentes ou outros a serem definidos, de modo a manter a catalogação em um único local. O Márcio deverá ser ouvido sobre isso na próxima reunião. O Leandro irá propor alguns templates de documentação.

Na sequência de reflexão sobre orientação a serviços, seria também interessante disparar, quando do momento de implantação de serviços, um mapeamento dos processos afetados de modo a identificar gargalos.

A Keia apresentou um material sobre "Desafios na Implementação de SOA" com mais alguns temas de reflexão, que ela deixará no repositório na intranet.

Acordamos que o processo de solicitação de uso de serviços restritos por um agente externo deve seguir o mesmo rito e procedimentos já consolidados para replicação (ofício etc.) . Uma versão dos documentos de replicação precisarão ser adequados para isso.

Para solicitações internas, serão empregados os mecanismos internos já em uso atualmente para replicação (e-mail, reunião, SSU etc.)

Precisamos evoluir a documentação de:

• Políticas de Acesso
• Contrato
• Documentação Administrativa
• Documentação Técnica
• Catálogo de Serviços
• Matriz de Responsabilidades

Com relação à implementação do caso-piloto, solicitaremos ao pessoal de infraestrutura um conjunto de máquinas separadas para o ambiente de produção. Algo como um sub-cluster para o SOA. O ambiente de desenvolvimento precisa ser preparado também.

Precisamos, além disso, definir o endereço de entrada dos serviços, que uma vez divulgado, preferencialmente não deve ser alterado.

Por enquanto é isso.

EAI - Enterprise Integration Patterns

Aqui há uma tentativa de síntese de 65 padrões de integração elaboradas por Gregor Hohpe e Bobby Woolf. Tem muita propaganda do livro deles poluíndo a tela, mas vale dar uma olhada, no mínimo para tentar identificar esses padrões no nosso ambiente:

http://www.eaipatterns.com/toc.html

Cursos on-line de SOA

Nesse post tem alguns links para um curso on-line sobre SOA da IBM:
http://architecture-journal.blogspot.com/2007/07/cursos-de-soa-da-ibm-on-line.html

e aqui um do Sang Shin da Sun, que infelizmente já está no meio do caminho:
http://www.javapassion.com/webservices/index.html

Alguém se candidata?

Material do I3Gov

O I3Gov é uma iniciativa da Secretaria de Logística e Tecnologia da Informação (SLTI) do Ministério do Planejamento, Orçamento e Gestão, com o objetivo de implementar de uma Arquitetura Referencial de Interoperabilidade de Sistemas (uma customização de SOA). Mais informações em:

http://i3gov.softwarepublico.gov.br/

Há um material bastante interessante e bastante pertinente para a nossa próxima reunião de sexta (20.03). Vale a leitura:

Estruturação de WebServices e evolução do catálogo de serviços

Como descrever um Serviço Web

Nossa reunião de 06.03.2009

Em nosso primeiro encontro de março o Leandro apresentou a solução do Extrator Lattes-USP como um exemplo palpável de solução baseada em Serviços Web.

Na discussão que se seguiu, dentro da filosofia de buscarmos uma abordagem realista e com os pés no chão, deliberamos trabalhar o tema de um Serviço de Pessoa, começando pela questão de como servir uma fotografia a partir do código de pessoa. Esta é uma demanda que já existe, motivada pelo desenvolvimento do sistema de acesso aos restaurantes universitários pelo CIAGRI. A solução atual, de geração de arquivos e disponibilização para download, além de ser muito onerosa, não permite a flexibilização oferecida por uma consulta on-line.

Além disso, ficou claro que o desenvolvimento de serviços deve estar diretamente associado à cada àrea de negócio e que é importante desenvolver capacidades e competências dentro de cada área.

Nesse sentido, a Eunice apontou que seria interessante verificarmos qual é o cenário atual e o posicionamento do tema de Serviços Web em relação à BEC e à Fazenda.

Uma vez focado o escopo do trabalho (serviço de disponibilização de foto), para a próxima reunião em 20.03.09, precisamos explorar uma série de temas associados ao Serviço:

• como documentar?
• o que documentar?
• como especificar?
• onde prover?
• como prover?
• como estabelecer segurança e políticas de acesso?
• qual o workflow da solicitação de acesso a esta nova forma de serviço?
• quais os canais de comunicação?
• quem são os responsáveis no DI?
• como fica a responsabilidade na USP?
• como o serviço vai ser construido?
• quanto tempo vai levar?

no fundo, no fundo, é o velho 5W2H... Estamos avançando, agora com um problema real pela frente.

E, com relação ao tema dos estilos arquitetônicos, considerando nossa complexidade de negócios e nossa participação nas cadeias de serviço, ora como fornecedores ora como clientes, é bem provável que tenhamos mais de um estilo convivendo. Haverá muito espaço para discussão e será um grande desafio combinar harmoniosamente o "big SOA" e o "little SOA", mas o "uso criativo da tecnologia" está lá, grafado na nossa visão. E é assim que vemos o mundo.

Avante!

Palestra SOA

Gestão de Processos de Negócio (BPM), SOA e Arquitetura Corporativa

Palestra Noturna - 31 de Março - 19h30 as 21h00

Resumo:
A importância do gerenciamento dos processos de negócio vem fazendo com que o interesse das empresas se torne a cada dia mais abrangente. O "M" da sigla BPM, que um dia foi apenas "Modelling" e que se transformou em "Management", mostra que diversos aspectos para além da modelagem passaram a ser alvo de interesse, estudo e aplicação corporativa.

Entretanto, pode-se argumentar que a linha principal de desenvolvimento dessa visão mais abrangente concentrou-se nos últimos anos, em aspectos mais "técnicos" da área de BPM. Questões como monitoramento de performance on-line de processos, geração automática de código de execução de processos etc. tiveram um grande desenvolvimento. Também avançou o conceito de Arquitetura Orientada a Serviços (SOA), sempre tratado ao nível das aplicações. Mas talvez não se possa dizer o mesmo do amadurecimento das porções mais voltadas à compreensão do negócio da empresa como um todo.

Nesse sentido, são fundamentais os conceitos e técnicas de modelagem da Arquitetura Corporativa, que procuram ir além dos processos de negócio, relacionando-os com os demais elementos da organização. É a compreensão da Arquitetura que permite, por exemplo, a análise de impactos e a redução de riscos nas mudanças nos processos de negócio. Por conta da visibilidade que a Arquitetura Corporativa provê, ela é obrigatória por lei em todas as
agências federais do governo dos Estados Unidos.

Esta palestra apresentará os conceitos de Arquitetura Corporativa, sua ligação com BPM e dois dos principais frameworks usados pelo mercado (TOGAF e Zachman).

Conteúdo
* O que são BPM e SOA
* O que é Arquitetura Corporativa
* Como SOA e BPM se inserem no contexto da Arquitetura Corporativa
* Principais frameworks de Arquitetura Corporativa
* Por que investimentos em SOA e BPM são arriscados sem a Arquitetura Corporativa


Público Alvo
Gerentes de Projetos, Coordenadores, Líderes de Equipes e quaisquer profissionais envolvidos com a necessidade de garantir o sucesso de projetos.

Palestrante
Átila Belloquim é Vice-Presidente da SUCESU-SP e Sócio-Diretor da GNOSIS – IT Knowledge Solutions. Mestre em Administração pela FEA-USP e graduado em Ciência da Computação pelo Instituto de Matemática e Estatística da mesma universidade (IME-USP).

Investimento
Nao Associado SUCESU-SP R$ 30,00
Associado SUCESU-SP R$ 0,00

Informações
Tel.: (11) 3556-6651
eventos@sucesusp.org.br

Localização
Auditório SUCESU-SP - Rua Tabapuã, 627 - Térreo, saiba como chegar
Estacionamento Sugerido: Rua Jesuíno Arruda, 676 (não conveniado para o evento em questão)

Achei este artigo do CIO bem interessante, ele é bem simplisinho e para quem ainda está com algumas dúvidas, do que é SOA, por que precisamos usar um serviço, quais as vantagens disso esse artigo esclarece
ABC da SOA

Sobre o que mesmo estamos falando?

Já que estamos na fase de trabalhar conceitos, reuni aqui um material interessante para discutirmos não só na próxima reunião, mas nas próximas semanas.

Vamos lá: o que você responde quando perguntam em casa qual é o assunto das reuniões quinzenais das sextas de manhã? Uma abordagem bem humorada é: How I Explained REST to My Wife.

Como logo vamos ter que tocar no debate entre os estilos arquitetônicos, em contraponto ao que já vimos, seria interessante também dar uma olhada em:

Representational State Transfer (Wikipedia)

Rest web services

E, para provocar reflexão, O debate SOAP vs REST e RESTful Web Services vs. “Big” Web Services:Making the Right Architectural Decision.

Esses estilos também tem suas boas (e más) práticas. Com relação ao REST, uma boa introdução é: Implementing REST Web Services: Best Practices and Guidelines

A lista certamente não acaba aqui, por isso, aguardo mais links e mais debate.

Até.

Nossa reunião de 20.02.2009

Em nossa última reunião de fevereiro, a Bianca apresentou um resumo de sua monografia "Proposta de Utilização de uma Arquitetura Orientada a Serviços para Integração de Sistemas", com uma ótima exposição de conceitos, incluindo exemplos e proposições de aplicação real em nosso ambiente. Muito bom!

A seguir, iniciamos uma reflexão sobre os próximos passos, quais abordagens devemos seguir e que esperamos do grupo e do trabalho. De inicio, posso dizer que uma abordagem bem realista, com os pés no chão com relação às necessidades, demandas e recursos e a expectativa de que o trabalho não fique apenas no âmbito da especulação, mas sim no da realização de produtos, foi um ponto de convergência.

Estamos avançando e, à medida que esses temas forem se tornando mais claros para o grupo, mais consistentes e homogêneos, iremos divulgá-los aqui.

Na próxima reunião, agendada para 06.03.2008, o Leandro apresentará um caso real de serviço web em funcionamento: o extrator do Lattes-USP.

Até lá.

Artigo "O Tsunami SOA" em pdf

Pessoal, criei uma pasta no diretório DOCSDI da Intranet p/ guardarmos o material sobre SOA (enqto não arrumamos local mais adequado).
Por hora, eu disponibilizei lá o artigo Tsunami SOA em pdf, além do capítulo do livro que a Keia comentou.
;)

Abraços!

Capítulo do livro Design Patterns de Thomas Erl

Baixei o cápítulo 12 deste livro com alguns exemplos de Design Patterns. Está no transfer Keia

O Tsunami SOA

RELATÓRIO ESPECIAL PARA LÍDERES CORPORATIVOS
V I S Õ E S E A N Á L I S E S D O S E D I T O R E S D A C I O
Ainda com poucos usuários reais, a
arquitetura orientada a serviços atrai
as atenções de todo o mercado de TI. Este
especial elaborado pelos editores da CIO
traz informações para você decidir se já
é hora de apostar no novo modelo
Só se fala nela. Considerada a grande promessa para
dar mais agilidade, reduzir custos e aproximar de
uma vez por todas a tecnologia dos negócios, a arquitetura
orientada a serviços é, nos últimos anos, a
vedete do mundo de TI. Analistas, fornecedores e
CIOs apuram os ouvidos quando o assunto é SOA.
As razões são muitas. Uma delas é o prestígio
que o novo modelo de construção de aplicativos -
se é que se pode resumir assim o conceito - traz
para o executivo de TI que o adota. Uma pesquisa
realizada pela revista CIO nos Estados Unidos mostra
que tanto o CIO quanto a área de TI ganham
poder e budget ao aderir à SOA.
A presença no comitê executivo é um exemplo.
Entre os executivos que partiram para a arquitetura
orientada a serviços, 74% estão no board. Dos
que ainda não acreditam em SOA, apenas 59% estão
no comitê executivo. O orçamento também é
mais generoso para quem usa a nova arquitetura.
Com SOA, a média fica em 8,9% da receita, contra
5,8% para os demais.
Para a sua empresa, investir em uma total reestruturação
da arquitetura de TI para adotar SOA
faz sentido? Para ajudá-lo a responder esta questão
- que pode ser decisiva para a sua imagem na
companhia -, CIO montou um especial com diversas
reportagens, abordando diferentes aspectos
do modelo. Confira abaixo.
APRESENTAÇÃO
O TSUNAMI SOA
CAPÍTULO 1
O QUE MUDA NO MUNDO PÓS-SOA
CAPÍTULO 2
O ABC DO SOA
CAPÍTULO 3
SOA: EM CONSTRUÇÃO
CAPÍTULO 4
O VERDADEIRO DESAFIO DO SOA NÃO É TECNOLÓGICO
CAPÍTULO 5
OS QUATRO ESTÁGIOS DA ARQUITETURA DE TI
CAPÍTULO 6
O MOMENTO DA ADOÇÃO DO SOA 27
20
17
10
05
02
01
OTSUNAMISOA
B R I E F I N G
Mudanças no mundo pós-SOA
2
T
CAPÍTULO 1
ransito no mundo do software a mais tempo do
que gostaria de admitir (Se eu contasse, revelaria
minha idade.) Acompanhei o vai-e-vem de muitas
tendências. Muitas inovações ocorreram, algumas
delas resultando em produtos e empresas muito interessantes,
que deixaram sua marca no mundo e
depois desapareceram. O modelo consistente que
observo é o avanço lento, nos últimos 20 anos, em
direção à computação distribuída. O advento da arquitetura
orientada a serviços (SOA) não é apenas
outra moda passageira, um dentre tantos conjuntos
de produtos e serviços. Acredito piamente que
terá o mesmo impacto de longo alcance que a
Internet teve quando surgiu como empreendimento
comercial no início dos anos 90. Olhando retroativamente,
muitas pessoas não tinham a menor
idéia de como esta simpática tecnologia seria usada
realmente no mundo comercial. Como se diz, o
resto é história.
Penso que, assim como a Internet, a SOA terá
suas próprias conseqüências imprevistas para o
futuro da computação. A arquitetura orientada a
serviços vai forçar uma mudança drástica no equilíbrio
de poder no mundo do software, tanto do
lado do fornecedor quanto do cliente. Por que esta
declaração intempestiva? Para começar, pense
nas implicações da SOA. O novo modelo representa
uma mudança radical no modo como o software
é criado, reutilizado, recombinado, gerenciado
e vendido. Da perspectiva do cliente, a SOA põe o
poder nas mãos do usuário de negócio.
O que pode mudar? Em primeiro lugar, com o
correr do tempo, SOA vai nivelar o jogo. Hoje, os
principais fornecedores disputam o controle sobre
quem possui a infra-estrutura do cliente.
Alguma empresa sairá vitoriosa? SAP, Oracle, HP,
IBM, Microsoft, um player open-source como
Jboss? Alguma delas conseguirá convencer clientes
em número suficiente para poder ditar as regras?
Talvez. Mas estou supondo um cenário diferente.
Imagine chegarmos ao estágio em que os
fornecedores vão convergir em torno de padrões
codificados como XML e todas as suas variantes
necessárias para criar este framework arquitetural
altamente distribuído. Imagine também que
existam bons adaptadores, capazes de permitir
que todos os componentes de diversos ambientes
conectem-se mais facilmente. E, por fim, imagine
que os clientes querem mesmo é reutilizar
seus ativos de software encapsulando-os de forma
que sejam usados repetidamente para criar
novas aplicações virtuais.
Se você acompanhar meu raciocínio, verá que
SOA cria oportunidades interessantes. Veja algumas
idéias que valem a pena considerar:
• Os clientes vão levar SOA a sério — não só como
iniciativa tecnológica, mas também como estratégia
de negócio — e demandar que líderes da
indústria colaborem para facilitar o trabalho dos
clientes.
• Vão surgir novos fornecedores capazes de capitalizar
o trabalho realizado por líderes de infra-estrutura
em torno de SOA para disponibilizar serviços
comercializados que resolvam problemas específicos
em mercados verticais específicos.
• Terá início a primeira era da industrialização de
software. Os fornecedores vão começar a criar soluções
modulares baseadas no modelo SOA para
se encaixar em frameworks existentes (tais como
os volantes que podem ser usados em 20 modelos
de carro diferentes).
• A aplicação empacotada que tem sido o alicerce
da indústria de software nos últimos 25 anos começa
a se transformar nestes pacotes industriais.
Daqui a uns 10 anos, o pacote de software tradicional
vai desaparecer.
A arquitetura orientada a serviços veio para ficar e terá grandes repercussões
no mercado de software mundial na próxima década e adiante
3
CAPÍTULO 1
• SOA abre as portas de um novo mundo, onde
“software como serviço” é a norma. Esta transição
levará, no mínimo, algo entre 15 e 20 anos. Mas
ela é real e terá um impacto surpreendente sobre
a indústria inteira, desde modelos financeiros a
fornecedores de hospedagem abrangentes.
Sei que é bastante informação para digerir.
Muitas empresas estão tentando descobrir se SOA
é para valer ou uma moda passageira. Teremos no
termo arquitetura orientada a serviços um elemento
crítico do futuro ou ele será desbancado por novas
balas de prata? Se prestarmos atenção à história
da indústria de informática, não surpreende que
as pessoas fiquem apreensivas. Como já observamos,
tendências vêm e vão rapidamente. Prevejo
que esta, porém, é real. E aqui vai meu alerta: não se
trata de um simples “jeitinho”. Na verdade, estamos
testemunhando o início de uma grande tendência
de mercado que terá repercussões no mercado de
software na próxima década e adiante.
Judith Hurwitz é presidente da empresa de consultoria e pesquisa Hurwitz and Associates.
4
CAPÍTULO 2
O ABC da SOA
OQUE É ARQUITETURA ORIENTADA A SERVIÇOS?
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
através de uma 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.
O que é SOA? Você realmente precisa dela? Se precisar, quais são
os primeiros passos que você deve tomar para adotar este novo modelo?
5
CAPÍTULO 2
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 integrá-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
6
CAPÍTULO 2
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 po7
CAPÍTULO 2
dem 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,
8
CAPÍTULO 2
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
9
CAPÍTULO 2
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.
S
SOA: Em Construção
10
CAPÍTULO 3
e você perguntar a qualquer pessoa encarregada
de construir uma arquitetura orientada a serviços
(service-oriented architecture -- SOA), ela responderá
que a parte mais difícil não é a tecnologia,
mas a reformulação dos processos de negócio que
constituem a base da arquitetura -- e a conseqüente
troca de funções e responsabilidades, com
freqüência litigiosa.
É o que estão dizendo muitos implementadores
de SOA e, portanto, tem que ser verdade. Mas a tecnologia
não é, necessariamente, fácil. Depois que a
fase de planejamento e estratégia está concluída,
os serviços e a infra-estrutura de mensagem têm
que ser disponibilizados e gerenciados juntamente
com plataformas, aplicações e sistemas já em uso.
O objetivo final de SOA é uma infra-estrutura extraordinariamente
ágil, em que TI desenvolve aplicações
híbridas sobre uma camada de abstração
que abrange múltiplas plataformas e múltiplos domínios
na corporação. Mas é impossível atingir esta
meta de repente. Implementações SOA viáveis
começam com um conjunto de processos de negócio
que se beneficiaria visivelmente de maior flexibilidade
– por exemplo, onde condições de mercado
estão em fluxo constante ou novos serviços têm
que ser implantados on the fly por razões competitivas.
Em algum momento, esta abordagem topdown
encontra a realidade bottom-up dos ativos de
software e da infra-estrutura existentes.
Quando isso acontece, os tecnólogos têm que
tomar decisões-chave sobre as plataformas nas
quais vão criar serviços e como estes serviços serão
expostos, gerenciados e mediados. Algumas
empresas podem optar por um ESB (enterprise
service bus) para conectar serviços, enquanto outras
talvez prefiram serviços baseados em padrões,
projetados para reutilização máxima. Uma
análise das decisões que empresas tomaram no
mundo real provê lições valiosas para quem precisa
criar realmente uma SOA, e não apenas louvar
seus benefícios.
CRIAR, EXPOR E MONITORAR SERVIÇOS
A escolha da plataforma sobre a qual criar serviços
provavelmente é a decisão mais fácil que TI enfrenta.
A maioria das empresas, quando constrói serviços
a partir do zero, capitaliza a força de seus desenvolvedores,
já que as ferramentas de criação de
Web services amadureceram em todas as importantes
plataformas de desenvolvimento, desde servidores
de aplicações Java a .Net em Windows e COBOL
em z/OS. Quando expõem a funcionalidade de
aplicações existentes como serviços, porém, algumas
empresas também usam ESBs como plataforma
porque os serviços podem ser provisionados via
configuração ao invés de codificação.
O que importa, desde o início, é criar serviços em
conformidade com padrões de Web services e, em
alguns casos, Java, diz Martin Moseley, arquitetochefe
de soluções de arquitetura de integração da
Intuit. Padronizar sobre XML e SOAP significa poder
usar a gama mais ampla de ferramentas para orquestrar
serviços. John Turato, vice-presidente de
tecnologia da empresa de aluguel de carros Avis
Budget Group, concorda. “Evitamos os penduricalhos
e nos atemos ao essencial.”
Depois de criar e testar um serviço, os desenvolvedores
publicam-no em um registro para que pessoas
autorizadas possam localizá-lo e outros serviços
ou outras aplicações possam consumi-lo. Hoje,
a maioria dos registros está acoplada a repositórios
que apontam para metadados sobre serviços – incluindo
políticas que governam o desenvolvimento
de serviços, como regras para desenho de segurança,
e parâmetros de governança run-time, como
SLAs ou carga esperada.
“Reconhecemos desde o começo que precisávamos
de uma ferramenta de repositório”, diz George
Glass, diretor de estratégia e arquitetura da BT
(ex-British Telecom). Mas as ferramentas de repositório
não existiam realmente quando a BT iniciou
os esforços de SOA e a empresa usou suas ferramentas
de design Borland como repositório, expon-
As empresas estão descubrindo que criar a SOA é um processo lento,
pois depende de várias tecnologias. Leia aqui como isso acontece
11
CAPÍTULO 3
do os serviços a analistas de negócio através de uma
interface Web que criou a partir do zero.
A empresa de seguros Hartford publica serviços
disponíveis em um registro UDDI, mas utiliza planilhas
Excel e um banco de dados para repositório, revela
Ben Moreland, diretor de serviços. Como parte
da iniciativa de arquitetura de referência corporativa,
a Hartford está cogitando um sistema de repositório
mais formal. Moreland ficou satisfeito porque
sua empresa pôde esperar e os produtos de registro/
repositório atuais lidam eficazmente com
metadados. “Agora podemos criar uma solução melhor
do que se tivéssemos aderido logo.”
Depois que você implementar os serviços, “as
pessoas vão utilizá-los muito mais rápido do que
você imaginou”, observa James Barrese, vice-presidente
de desenvolvimento de sistemas da eBay.
“Você precisa ter a infra-estrutura básica: um diretório
central de consumidores e publishers, logging
detalhado de operações e tecnologia de monitoramento
de operações como os dashboards.”
Os metadados sobre serviços no repositório, de
uma maneira geral, descrevem o que deveria acontecer,
e não o que está acontecendo na realidade.
Em uma SOA, a performance, a disponibilidade e a
utilização de serviços em tempo real têm que ser
monitoradas – freqüentemente com a ajuda de
produtos de gerenciamento de serviços fornecidos
por empresas como a Actional (recém-comprada
pela Sonic Software), AmberPoint ou Blue Titan (adquirida
recentemente pela SOA Software). Estas soluções
também suportam controle de versão, failover
e logging de mensagem, proporcionando uma
visão centralizada para avaliar o status geral dos
serviços de uma rede.
A eBay inclui parâmetros de QoS em seus modelos
de serviços, com limitação de preços e logging
embutidos. Segundo Barrese, esta funcionalidade é
“abstraída dos engenheiros” para garantir que seja
implementada universal e consistentemente. Serviços
dashboard monitoram logs para detectar problemas
de performance. Serviços que estão sobrecarregados
podem solicitar que um serviço clone seja
iniciado ou que um analista de TI seja notificado.
A BT adota abordagem similar. “Todos os serviços
têm mensuração e monitoramento incorporados
ao conjunto de mensagens XML. Todas as transações
são rastreadas, possibilitando a mensuração
em cada estágio”, explica Glass, da BT. Uma
combinação de ferramentas de monitoramento
comerciais e desenvolvidas internamente analisa
os “footprints” de dados gerados pelos serviços,
alertando a BT quando serviços de missão crítica
não cumprem compromissos de nível de serviço.
As funções de logging embutidas nos serviços podem
ser ativadas ou desativadas, permitindo que
a BT monitore serviços com maior rigor quando
necessário – por exemplo, assim que os serviços
são implementados ou quando surgem problemas
de performance. TI também pode fazer uma análise
histórica de logs de serviço usando ferramentas
de BI (business intelligence).
DENTRO OU FORA DO BUS?
O trato dos serviços é relativamente simples. As decisões
sobre SOA mais confusas envolvem o modo
como os serviços se comunicam e o tipo de mediação
entre eles.
Em um mundo ideal, cada serviço em uma SOA
seria um Web service compatível com padrões, robusto
e acessado diretamente pelo número mais
amplo de aplicações ou serviços autorizados que
necessitam da funcionalidade ou da carga útil de
XML proporcionadas pelo serviço.
No mundo real, porém, as empresas precisam lidar
com sistemas legados que utilizam protocolos
proprietários, de MQ a AS2. E muitas argumentam
que Web services messaging só alcançará níveis de
confiabilidade corporativos quando esboços de
protocolos de Web services como WS-ReliableMessaging
estiverem totalmente finalizados e vastamente
implementados.
É aí que entra em ação o ESB – a categoria de produtos
mais estreitamente associada a SOA. Barramento
de mensagem e plataforma de serviço, um
ESB facilita conectar sistemas legados e gerenciar
e orquestrar serviços. Como os produtos EAI (enterprise
application integration), ESBs também transformam
e roteiam mensagens. Fornecedores de
ESB alardeiam que seus produtos são baseados em
padrões, embora a maioria use JMS (Java Message
Service) ou algum protocolo de mensagem proprie12
CAPÍTULO 3
tário para fornecer a confiabilidade necessária.
Os adeptos gostam do modo como ESBs lhes
permitem provisionar serviços e gerenciar a comunicação.
Recentemente, a ADP implementou
um ESB distribuído porque “é difícil manter um
grande volume de mensagens um-para-um”, diz
Bob Bongiorno, CIO da gigante de processamento
de folha de pagamento. O número de serviços
da empresa cresceu de nove para mais de 30, mas,
ao longo do caminho, “a complexidade de gerenciamento
mais do que triplicou”.
“Estamos selecionando um barramento de serviço
corporativo agora, mas já teríamos escolhido
um há três ou quatro anos, se ele existisse”, diz
Paul Kaptur, arquiteto de sistemas da General Motors.
“Estamos fazendo isso hoje porque os produtos
estão mais amadurecidos.”
ESBs funcionam bem para processos longos que
precisam ser orquestrados, como processamento
de pedidos, que envolve várias etapas em uma determinada
seqüência e validações no decorrer do
percurso, segundo Moseley, da Intuit. Um processo
de pedido, por exemplo, talvez precise validar o endereço
de um cliente antes de calcular os custos do
frete ou autorizar um cartão de crédito (freqüentemente,
o endereço é necessário para validar um cartão
de crédito), e todos os passos têm que ser dados
para que uma fatura possa ser enviada para expedição.
O sistema de processamento de pedidos da Intuit
utiliza esta abordagem de serviços mediados.
Mas algumas pessoas encaram ESB como um EAI
requentado – e acham que ele vai contra a natureza
aberta de SOA. “EAI é fundamentalmente diferente
de SOA”, afirma Anne Thomas Manes, analista
da Burton Group. “EAI interliga silos de processos
de negócio; SOA os separa.” Ela não vê problema em
usar um ESB para provisionar um serviço ou até
mesmo para orquestrar serviços “fine grained” em
um serviço “coarse grained” amplamente acessível.
Mas rejeita a idéia de usar um barramento como gateway
para todos os serviços, especialmente quando
a conversão para e de um transporte de mensagem
ESB gera overhead adicional.
Manes também encontra falhas na noção de
que a ausência de um ESB afeta serviços “ponto a
ponto” difíceis de gerenciar: ponto a ponto é uma
metáfora de integração, enquanto que a idéia de
SOA é expor serviços que podem ser reutilizados
por muitas aplicações ou outros serviços. E isso
não tem que significar falta de controle. Uma alternativa
à abordagem ESB é usar appliances XML
– também chamados de gateways – para rotear
mensagens e lidar com transformação e mapeamento,
e proxy services para que eles possam ser
governados e protegidos com eficácia.
Performance, segurança e governança run-time
A questão de usar ou não um ESB depende das necessidades
e tendências individuais de cada organização.
Caso a orquestração de serviços distribuídos
seja obrigatória, por exemplo, é muito difícil alcançá-
la se estes serviços não estiverem conectados a
uma infra-estrutura de mensagem assíncrona. Mas
um ESB não é uma SOA. Em uma SOA de qualquer
tamanho significativo, até um ESB largamente implementado
não seria a única opção disponível.
Múltiplos barramentos de mensagem talvez tenham
que ser interligados, e as mensagens, transformadas
à medida que trafegam entre eles.
Esta é uma função ideal para a nova geração de
appliances XML (projetados para proteger, governar
e aprimorar a performance de uma SOA) de empresas
como a Cisco, Forum Systems, IBM DataPower,
Layer 7 e Reactivity. Estas empresas vendem
máquinas que roteiam mensagens XML com base
em conteúdo e promovem transformações, roteamento
e mapeamento de XML em altíssima velocidade
utilizando processadores especiais projetados
para esta finalidade.
Dependendo do modelo, estas máquinas incorporam
um conjunto recursos, muitos deles sobrepostos
a outras capacidades de um ESB. Elas são exímias
em virtualizar serviços para que cópias de serviços
possam ser criadas on the fly à medida que as
demandas de performance aumentam – e para que
políticas concebidas para serviços possam ser aplicadas
em tempo de execução (run time) utilizando
software de gerenciamento centralizado. A maioria
também inclui recursos de segurança XML.
Na realidade, as primeiras unidades disponibilizadas
foram firewalls XML projetados para bloquear
ameaças baseadas em XML e ataques DoS.
Agora, os appliances de segurança XML suportam
13
CAPÍTULO 3
criptografia/descriptografia, autenticação, gerenciamento
de identidade, validação de esquema
XML e muito mais, controlando o acesso a aplicações
e protegendo o perímetro.
Estes serviços de segurança tornam-se vitais à
medida que SOA amadurece. É o caso da ADP, que
está implementando seu modelo de segurança padrão,
fornecido como um processo central e usado
por todos os outros serviços. A fornecedora de serviços
de tecnologia USi também adota o modelo federado
para gerenciamento de identidade de usuários.
“O serviço talvez nem saiba quem é o usuário”,
diz Mike Rulf, vice-presidente de engenharia avançada,
“mas sabe que o usuário foi validado em algum
ponto ao longo do caminho do serviço, já que os serviços
transmitem esta informação sobre validação”.
“A segurança não recebe atenção suficiente em
SOA”, alerta Dennis Gaughan, analista sênior da
AMR Research. Os esforços iniciais tendem a se concentrar
em definir as interfaces de serviço e mensagem
ou em separar lógica do negócio e de dados
entre si e também da execução e da apresentação.
Mas, à medida que a utilização de serviços aumenta,
torna-se muito difícil aprimorá-los para acomodar
controle e autorização de acesso – com freqüência,
são necessárias mudanças em larga escala
porque os controles de segurança podem alterar o
fluxo de processos e de dados.
Por isso, é melhor embutir “ganchos” para segurança
desde o início, mesmo que os serviços e sistemas
de segurança ainda não estejam implementados,
ensina Rulf. Na USi, todos os serviços têm um
modelo de WSDL padrão que inclui validação de segurança
e controles de acesso – assim como relatório
de erro, comportamento de chamada e expectativas
de dados – para garantir que os serviços estejam
capacitados para segurança desde o começo.
A Avis Budget também incorporou segurança à
sua plataforma SOA inicial, batizada de Omega. “Estamos
muito bem em termos de autenticação, mas
ainda tentando decifrar a autorização, seja ela abordada
em um serviço ou no lado da segurança”, observa
Turato. A empresa espera fornecer um serviço
de segurança comum para todos os seus serviços
e todas as suas aplicações. “Vamos centrar nosso
trabalho em um LDAP corporativo para explorar
os serviços de segurança da plataforma Omega.”
O uso de LDAP será essencial para identificar esforços
de gerenciamento e Turato quer que todos
os serviços incluam chamadas a pesquisa LDAP.
Mas, para impedir que cada serviço faça uma pesquisa
direta toda vez que ele executa, a Avis Budget
pretende requerer pesquisa em estágios específicos
de um processo de negócio e, então, propagar
esta validação para serviços posteriores.
O risco desta abordagem é que alguém venha a
fraudar a validação simplesmente transmitindo
um atributo “verificado”. Turato espera implementar
o atributo de validação como uma assinatura
que rastreia onde e quando a verificação
aconteceu para assegurar que a validação ocorreu
no estágio certo e no processo certo.
A eBay adota um método de segurança similar para
seus serviços customer-facing, com um serviço
de segurança que outros serviços invocam quando
necessário. Para serviços internos, a eBay segue o
modelo de segurança corporativa, utilizando serviços
e aplicações existentes para cada domínio de
aplicação, ao invés de criar um serviço de segurança
paralelo para projetos baseados em SOA.
A implementação arquitetural também deve
permitir flexibilidade para segurança, de acordo
com Bongiorno, da ADP. “Estamos tentando padronizar
em torno de um único modelo de segurança,
mas permitiremos exceções quando os requisitos
forem pesados demais.”
TESTANDO E DEPURANDO SERVIÇOS
Outro aspecto subestimado das implementações
SOA envolve testar e depurar. “Em várias circunstâncias,
SOA adotada da maneira apropriada acelera
a chegada no mercado”, diz Bongiorno. “Mas o
teste contribui para isso.”
Embora o uso de interfaces de serviço definidas
com rigor facilite o teste de integração em pares de
serviços, a natureza “muitos para muitos” da interação
de serviços e a variedade de sistemas de hardware
e software que os provisiona dificulta o teste.
“Você não pode botar sua empresa inteira em um
laboratório de QA”, ressalta Barrese, da eBay. Você
tem que escalar sua plataforma de teste o máximo
que o business case justifique.
14
CAPÍTULO 3
A eBay criou algumas ferramentas de QA para teste
automatizado de regressão com o objetivo de
ajudar a testar os muitos cenários de execução inerentes
a SOA, mas utiliza ferramentas de prateleira
como as fornecidas pela Mercury Interactive. (A ADP
também usa ferramentas automatizadas de regressão
da Mercury.) Além disso, a eBay está avaliando as
ferramentas open source de teste de serviços Apache
Axis com suas plataformas BEA e IBM.
A SunGard, fornecedora de soluções de processamento
de transações financeiras, exige que casos
de teste de todos os serviços sejam criados de antemão,
para assegurar que todas as interações e todos
os requisitos sejam equacionados, diz Nils Winkler,
arquiteto técnico. Unidades de teste são desenvolvidas
a partir destes casos de teste e estão
disponíveis para uso em teste automatizado de regressão
por todos os desenvolvedores de serviços
cujos processos possam usar o serviço específico.
“Você pode fazer o teste com os dados que já tem.”
Um desafio relacionado é o controle de versão. À
medida que os serviços aumentam, você tem que
supor que precisará suportar múltiplas versões porque
não pode atualizar todos os serviços de uma tacada
só. Um registro ou repositório acomoda informações
sobre versão como parte dos atributos padrões
de seus serviços. Esta salvaguarda é importante
para que outros serviços possam ajustar suas expectativas
de acordo, explica Bongiorno.
A melhor maneira de gerenciar o controle de versão
é projetar para isso, antes de mais nada, orienta
Moreland, da Hartford. “Comece com a expectativa
de que vai aposentá-la”, isto é, defina – e aplique
– períodos com fim de vida útil para todos os
serviços. E, embora você tenha múltiplas versões de
um serviço funcionando durante o tempo de transição
necessário, use serviços de tradução onde for
possível para mapear chamadas para o serviço antigo
ao invés do novo, fornecendo dados novos que
possam ser gerados ou adotados na tradução.
Nem todo o volume de teste do mundo é capaz de
pegar cada erro, é claro. Erros transacionais podem
ser detectados como parte do processo de monitoramento.
Mas, para identificar erros lógicos nos próprios
serviços em run time, os serviços chamadores
têm que observar a mensagem retornada para ver se
há alguma combinação imperfeita de formato, políticas
ou outro atributo esperado, com base nas especificações
de processos de negócio, diz Moreland.
PERTO DE CASA
É desnorteante o leque de plataformas de desenvolvimento,
registros/repositórios, esquemas de gerenciamento,
sistemas de mensagem, tecnologias
de segurança e ferramentas de teste. Facilmente
você é enredado em decisões táticas – por exemplo,
se compra um ESB e de quem. Mas a abordagem
que você escolher deverá acompanhá-lo depois que
você tiver definido seus processos de negócio, seus
serviços core e sua arquitetura geral.
“A sopa de letrinhas gera confusão”, diz Bill Adiletta,
presidente da empresa de consultoria TekFinancial
Solutions. Ao invés de tentar avaliar todas as tecnologias
possíveis, veja o que você já tem e exclua o
que não atende suas necessidades. Se nenhuma tecnologia
interna servir, examine as ofertas dos fornecedores.
Dentre os candidatos remanescentes, escolha
os que melhor se encaixam na sua base de tecnologia
e no seu conjunto de talentos e evite tecnologias
proprietárias o máximo possível.
A Hartford também adota esta abordagem. “Nossa
filosofia para fornecedor é: quanto mais fácil é
substituí-lo, mais gostamos dele”, diz Moreland.
“Suas escolhas de tecnologia devem basear-se
no que você já tem e no que você precisa e o fornecedor
não é capaz de fornecer”, ensina Judith
Hurwitz, presidente da empresa de consultoria
Hurwitz & Associates.
“Se você tem um forte compromisso com SAP,
por exemplo, então talvez valha a pena explorar o
NetWeaver”, diz Hurwitz. “Se não tiver, examine
atentamente suas aplicações antes de expô-las
como serviços. Primeiro verifique os componentes,
depois decida do que precisa. À medida que
os serviços se tornam mais claros, você examina
tecnologias como barramentos de serviços e mecanismos
de processos de negócios para gerenciá-
los conforme o necessário.”
Em 2001, a GM usou sua plataforma J2EE para
suas primeiras iniciativas de Web services, um
serviço de compras online que consolidou todas
as 14 marcas de carros GM. Hong Zhang, chief ar15
CAPÍTULO 3
chitect do Emerging Technology Group da GM,
gostou de o J2EE ter uma camada separada para
acesso a dados, o que facilitou lidar com as muitas
fontes de dados sem criar dependências de
processos de negócio em torno delas.
Mas Zhang deixa claro que não está “casado”
com J2EE ou qualquer outra tecnologia específica.
“Você precisa enfocar os serviços e como eles
implementam os processos de negócio. As tecnologias
vêm, vão e evoluem.”
Em um panorama geral, plataformas e tecnologias
específicas representam decisões táticas, mas
não estratégicas. Afinal, em SOA, os processos, fluxos
de dados, definições de dados, interfaces de serviços,
políticas, e por aí vai, devem ser abstraídos para
que não apresentem dependências de tecnologias
especificas. Manes, analista da Burton, descreve
o desafio como um “planejamento corporativo
com implementação local. SOA não é middleware”.
Se for levada em conta adequadamente, “pode ser
feita com qualquer middleware”.
Adiletta, da TekFinancial, concorda. “Use o forte
modelo de governança para chegar a um consenso
em torno dos padrões: definição de serviços,
convenções de nomeação, utilitários etc. O
pior método é adotar a tecnologia e dizer o que
ela pode ou não fazer.”
O que realmente importa é projetar bem suas
iniciativas SOA: arquitetura e processos de negócio,
requisitos de implementação, trade-offs aceitáveis,
fluxos de dados e processos prováveis e
necessidades de gerenciamento e performance.
Com tudo isso entendido, você pode usar as tecnologias
que lhe aprouver para construir os serviços
reais e a infra-estrutura de suporte.
“As implementações SOA devem seguir um modelo
federado de implementações incrementais de
uma maneira frouxa, mas com as mesmas metas e
a mesma direção”, diz Hurwitz. “Comece com um
conjunto de regras sobre o modo de fazer SOA para
que as pessoas tenham a mesma filosofia e a mesma
abordagem em mente para cada projeto.”
TRATA-SE DE ARQUITETURA
No meio do furacão, é fácil ser surpreendido por decisões
táticas, como a que envolve comprar um ESB
e de quem. Mas TI precisa ser flexível. SOA diz respeito
a criar uma arquitetura que suporte um estado
final desejado de processos de negócio otimizados,
porém com um nível de flexibilidade ao reorganizar
os processos que estão faltando em projetos
de “reengenharia” antiquados.
“Existe muita imprecisão quanto ao que SOA é ou
não é. Mas ninguém pode ter êxito sem pensar em
TI e no negócio juntos”, diz Sohrab Kakalia, vice-presidente
da Infosys, integradora de sistemas.
A arquitetura descreve os aspectos padrões de
serviços para fornecer estes processos de negócio,
incluindo governança e políticas, gerenciamento
de processos, a própria lógica do negócio, gerenciamento
e acesso a dados, definições dentro de serviços
e interfaces entre eles para que colaborem facilmente
e um framework de mensagem – geralmente
nesta ordem. “Estas camadas devem existir
em cada serviço”, orienta Adiletta, da TekFinancial.
E você nem pode se preocupar com os serviços
até entender os processos de negócio que eles estão
fornecendo. “Você tem que pensar em padronizar
os processos de negócio primeiro”, diz Turato,
da Avis Budget.
A BT, gigante britânica de telecomunicações,
desenvolveu 14 plataformas de serviços. “Cada
plataforma tem um conjunto de serviços com
operações associadas a eles – como um método
na programação orientada a objetos. Um serviço
reside em apenas uma plataforma”, explica Glass,
da BT. E cada plataforma tem um arquiteto designado
para ela, que garante que todos os serviços
– sejam desenvolvidos internamente, fornecidos
por um parceiro ou comprados de um fornecedor
– aderem à arquitetura. Para imposição deste
compliance, se um projeto da BT não se adequa à
arquitetura, a equipe de desenvolvimento perde
um quarto do seu bônus anual.
Para proporcionar flexibilidade ao negócio e execução
de processos consistente, “a arquitetura é independente
de qualquer implementação de tecnologia.
Tecnologias mais novas podem aparecer e ser
implementadas, mas a arquitetura é sustentável. A
estratégia de SOA permanece”, diz Zhang, da GM.
Com foco nos processos de negócio subjacentes,
SOA desestimula dependências tecnológicas
16
CAPÍTULO 3
que poderiam limitar a capacidade de uma empresa
de mudá-los ou acrescentá-los posteriormente.
Além de uma decisão estratégica sobre
arquitetura, uma implementação SOA bem-sucedida
se apóia na idéia de TI reconhecer rotineiramente
oportunidades de projetos para um serviço
ou processo de negócio reutilizável.
Quem pensa que ao usar uma tecnologia como
SOAP ou WSDL para fornecer uma função ou integrar
aplicações está fazendo SOA, não está entendendo
nada, segundo Moseley, da Intuit. As tecnologias
são um meio para um fim, não o fim em si.
O verdadeiro desafio do
SOA não é tecnológico
17
O
CAPÍTULO 4
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 gran-
Para alcançar o alinhamento entre TI e negócio prometido pela arquitetura orientada
a serviços, os CIOs têm de enfocar processos e arquitetura, não apenas tecnologia
18
CAPÍTULO 4
de 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.
Esteja preparado para passar um ano fazendo a
análise inicial de processo de negócio e arquitetura,
aconselha Metzger, da TrueCredit. Mas este
tempo extra despendido no início vai compensar
exponencialmente, acredita Metzger. Hoje, novos
serviços na TrueCredit têm um ciclo de desenvolvimento
de apenas seis semanas. No Distrito
de Colúmbia, alguns serviços são disponibilizados
em apenas 12 semanas (serviços mais complexos
demoram de quatro a seis meses).
DESAFIO 2: LEVAR A GOVERNANÇA A SÉRIO
Governança é vital, tendo em vista que SOA, no
fim das contas, diz respeito a criar e gerenciar
processos de TI para suportar processos de negócio.
“As organizações de desenvolvimento, acostumadas
a criar aplicações, agora estão montando
peças”, diz Dennis Gaughan, diretor de pesquisa
sobre governança de TI na AMR Research. E este
desenvolvimento tem que ser feito de maneira
padronizada, o que pode aborrecer os desenvolvedores.
“SOA retira grande parte do controle
de desenvolvedores individuais e por isso você enfrenta
resistência”, afirma John Stubbs, CIO da
Sony Pictures Entertainment, braço de distribuição
da Sony. A iniciativa de SOA da Sony Pictures
resultou em um serviço comum para gerenciar os
direitos de licença de filme e programas de TV em
vários ramos de negócio (incluindo venda de
DVDs e edições limitadas), afetando 39 unidades
de negócio (incluindo jurídica e marketing). O
grupo de TI agora usa SOA para implementar Web
services comuns para seus processos SAP
Financials, como contas a receber.
Uma maneira de aplicar o princípio SOA de reutilização
é criar um board de análise que avalia novas
aplicações para garantir que são realmente
necessárias. Sony Pictures e TrueCredit têm tal
board. O board de análise deve incluir o CIO ou
CTO, chief architect, especialistas-chave em tecnologia
e processo da área de TI e os principais
analistas de negócio, salienta Rogers, da IDC.
DESAFIO 3: REPENSAR O CONJUNTO DE TALENTOS
Além da equipe de arquitetura que desenvolve e
gerencia o quadro geral de SOA, o CIO precisará
de uma equipe de desenvolvimento familiarizada
tanto com processos de negócio quanto com a
abordagem de serviços para desenvolver aplicações.
Especialistas em negócio capazes de se associar
a TI na identificação e implementação de
processos também são cruciais — a organização
do CIO não pode fazer tudo sozinha.
“É necessário re-treinar, contratar, reimple19
CAPÍTULO 4
mentar”, afirma Rogers. A maioria dos CIOs vai
contratar profissionais experientes em SOA essenciais
e re-treinar para a mentalidade SOA pessoal
já contratado. “É um processo contínuo, você
deve começar pequeno e re-treinar muito”,
aconselha Metzger, da TrueCredit.
DESAFIO 4: APLICAR PRINCÍPIOS DE SOA AOS DADOS
A importância de tratar os dados — e não apenas
a funcionalidade da aplicação — como um serviço
costuma ser negligenciada em implementações
iniciais de SOA, diz Schmelzer, da ZapThink.
Em SOA, múltiplos serviços residindo em múltiplas
aplicações poderiam ser combinados para
executar um processo de negócio. Se cada serviço
usa fontes de dados diferentes ou até a mesma
fonte de dados mas de maneiras diferentes,
observa Schmelzer, os resultados talvez não sejam
os desejados.
Metzger prega a separação total entre serviços
que acessam e armazenam os dados e serviços
que empregam os dados (cálculos, por exemplo).
Ele também separa serviços de apresentação, que
formatam os dados para usuários ou relatórios, de
outros serviços. Isso ajuda a garantir que todos os
serviços tenham o mesmo contexto para um dado
específico.
RECOMPENSA: O VERDADEIRO ALINHAMENTO
ENTRE NEGÓCIOS E TI
Todos estes desafios ressaltam o quanto SOA difere
das iniciativas de tecnologia corporativas
tradicionais. O CIO tem que pôr de lado o papel de
tecnólogo e se tornar um defensor de processos
de negócio. Um conhecimento melhor destes
processos leva a um desenho melhor da tecnologia,
reduzindo o custo de manter sistemas existentes
— algo que, atualmente, consome 70% a
80% dos budgets de TI, contabiliza Schmelzer.
“Há anos falamos sobre alinhamento entre TI e
negócio”, diz Rogers, da IDC. SOA permite que você
atinja esta meta, se puder desenvolver a visão
arquitetural e viabilizá-la no longo prazo. Não é
um processo fácil, mas adeptos pioneiros como
Peck, Metzger e Stubbs jamais retornariam à
abordagem de TI tradicional. “Grande parte do governo
do Distrito de Colúmbia não funcionaria
sem SOA”, exemplifica Peck.
Os quatro estágios
da arquitetura de TI
20
O
CAPÍTULO 5
ano era 1999. Abordar potenciais falhas relacionadas
ao ano 2000 - o bug do milênio - em todos os
sistemas de computador consumia a atenção de TI
na State Street, líder mundial em serviços financeiros
para investidores institucionais. Apesar da gigante
de serviços financeiros estar extremamente
focada em garantir que “00” fosse interpretado como
2000 ao invés de 1900, David Saul, gerente de
software de sistemas e líder em correção de bugs
do ano 2000, percebeu algo mais. Todos os projetos
estavam interligados. Para assegurar que nenhuma
mudança envolvendo Y2K na aplicação “A” trouxesse
problemas para a aplicação “B”, a equipe de projeto
precisava entender a relação entre as aplicações
e todos os seus inputs e outputs. As aplicações
da State Street usam dados de referência para processar
transações com valores mobiliários (moeda,
Bolsa de Valores onde a transação é realizada etc.).
Tendo em vista que estes dados permeiam todas as
aplicações, fazia sentido para a equipe de Saul lidar
com eles independentemente das aplicações financeiras
específicas que os exploravam. Na época, a
maioria das aplicações lidava com seus próprios dados
de referência, ao invés de se apoiar em um serviço
comum distinto. A State Street reconheceu o
valor dos serviços comuns e montou um escritório
de arquitetura (que Saul dirige desde então) para
criar o ambiente arquitetural para eles. “Nada mais
natural que o fornecimento de dados de referência
sob a forma de serviço evoluísse para as atuais arquiteturas
orientadas a serviços (service-oriented
architectures – SOA)”, diz Saul.
A abordagem SOA alinha diretamente serviços de
dados e software com processos de negócio para
que serviços específicos possam ser reutilizados e
mesclados conforme a necessidade. Assim, as empresas
reduzem os custos de desenvolvimento de
tecnologia e aperfeiçoam a capacidade de oferecer
serviços novos ou aprimorados para clientes e parceiros
de supply chain.
Tudo muito bom. Mas, mesmo que sua empresa
precise realmente de SOA, talvez você não esteja
preparado para implantá-la. Foi a conclusão a que
chegaram dois estudos recentes do MIT Sloan Center
for Information Systems Research (CISR), “Arquitetura
de TI como Estratégia” e “Escolhas Estratégicas
Norteadas por TI”, ambos baseados em uma série
de projetos de pesquisa envolvendo 456 empresas
entre 1995 e 2006. A pesquisa do CISR identificou
quatro estágios arquiteturais distintos: silos, TI
padronizada, processos de negócio padronizados e
modularidade do negócio — que tanto as unidades
de negócio quanto TI precisam percorrer para usufruir
plenamente os benefícios de SOA. E ninguém
pode pular nenhum estágio. Na melhor das hipóteses,
o processo pode ser acelerado. Para os pesquisadores
do CISR, a conclusão foi inesperada. “Mas,
quando contamos para as pessoas, elas retrucam
que é por isso que não está dando tão certo”, revelou
a pesquisadora-chefe Jeanne W. Ross. Considerando-
se que a vasta maioria das empresas se encontra
no primeiro ou no segundo estágio (e, repito,
não podem queimar etapas), vai levar anos, décadas
talvez, para que SOA seja ampla e eficazmente
adotada, prevê Ross.
A pesquisa do CISR proporciona um road map
que o negócio e TI podem seguir para evitar desvios
improdutivos, não desanimar no longo percurso
e entender o que é o sucesso quando ele finalmente
for alcançado. Felizmente, observa
Ross, cada estágio tem seus próprios benefícios,
com retornos de curto prazo sobre o investimento
arquitetural de longo prazo.
Cada estágio tem cerca de cinco anos de duração,
Estudo do Massachusetts Institute of Technology mapeia a evolução da arquitetura
de TI e explica por que nenhuma etapa pode ser pulada
21
CAPÍTULO 5
explica Ross, mas este período pode diminuir à medida
que mais empresas passem pelo processo e
aprendam quais erros devem ser evitados. “Sete
anos atrás não havia práticas arquiteturais nas empresas
de pesquisa”, diz Saul, da State Street. As empresas
de hoje não precisam tatear tanto o caminho.
A boa notícia, de acordo com Ross, é que seus
concorrentes provavelmente – ou quase – atingiram
o mesmo nível de maturidade arquitetural que
você e também não podem pular nenhum estágio.
Os que tentam podem desperdiçar tempo e esforço
ao implantar processos de negócio e infra-estruturas
de TI sem estarem preparados para usá-los.
Ao invés de tentar dar grandes saltos, Ross sugere
que os CIOs se unam ao resto da empresa para
promover um avanço incremental, ganhando conhecimento,
conquistando adesão e colhendo o
ROI que irá sustentar a maturidade no longo prazo.
Ross acredita que ter em mente o framework de
maturidade arquitetural durante esta evolução dá
aos CIOs e seus pares na área de negócio uma maneira
de avaliar se estão progredindo realmente,.
O FRENESI SOA
Hoje, os CIOs não podem mais ignorar SOA. As
empresas de pesquisa e as publicações de negócio
alardeiam sua capacidade de tornar as corporações
ágeis e eficientes. Os fornecedores utilizam
este rótulo, muitas vezes enganosamente,
para ajudar a vender seus produtos. Para onde
quer que se voltem, os CIOs ouvem a mesma mensagem:
você tem que implementar SOA rapidamente
ou ficará em desvantagem competitiva.
Na realidade, SOA apresenta vantagens ainda
que você não se encontre no estágio em que, segundo
o CISR, é possível usufruir todos os benefícios
desta abordagem. “Mesmo que você implemente
tecnologia baseada em SOA antes de sua
organização estar preparada, pode obter um sistema
de integração mais eficiente na área de TI”,
afirma Ron Schmelzer, analista sênior da ZapThink,
empresa de consultoria sobre SOA. “A implementação
de conceitos SOA, ainda que de maneira limitada
como a criação de web services, também
ajuda a produzir um vocabulário comum para que
os grupos de negócio e TI comecem a caminhar na
mesma direção”, enfatiza Judith Hurwitz, CEO da
empresa de consultoria Hurwitz & Associates.
Mas, mesmo que você extraia alguns pontos positivos
de uma implementação prematura de SOA,
ressalta Jim McGrane, ex-CIO (atual VP) da fabricante
de papéis MeadWestvaco, também pode depararse
com pontos negativos. “Pôr uma interface de web
services sobre um processo ruim apenas o torna
mais visível”, diz McGrane. Entender por que a empresa
ainda não está pronta para uma abordagem
SOA completa ajudará o CIO a descobrir quais benefícios
podem ser obtidos em relação à maturidade
em que a organização se encontra no momento.
ESTÁGIO 1: DOS SILOS À
MODULARIDADE DO NEGÓCIO
Mesmo que não saibam, diz Ross, a maioria das
empresas bem-sucedidas está atravessando os
estágios de maturidade identificados na pesquisa
do CISR. A maior parte das empresas se encontra
no estágio 2: tecnologia padronizada. No decorrer
da década de 90, ficou claro que o estágio
1 — silos de negócio com iniciativas de TI focadas
em necessidades departamentais específicas
— gerou overhead e requisitos de suporte excessivos.
Tal nível de complexidade, que caracterizou
os primórdios de TI, não foi capaz de sustentar o
crescimento corporativo (sem mencionar o fato
de que custou muito dinheiro). Isso levou a maioria
das empresas a adotar tecnologias de plataforma-
padrão onde era possível, utilizando apenas
uma ou duas configurações de PC, uma tecnologia
de banco de dados padrão para todos os departamentos
ou o mesmo tipo de hardware e sistema
operacional para todos os servidores.
O terceiro estágio -- processos de negócio padronizados
– é onde estão hoje muitas empresas modernas.
O negócio é visto holisticamente e os líderes
de TI e negócio se consideram parceiros. O quarto
estágio, no qual poucas empresas ingressaram
até agora, é o de modularidade do negócio. Os processos
de negócio e as tecnologias que o suportam
se transformam em módulos que podem ser reutilizados
para promover eficiência e recombinados
para proporcionar agilidade — a promessa quintessencial
de SOA. As organizações sabem quais pro22
CAPÍTULO 5
cessos devem ser restritos a unidades de negócio
específicas e quais devem ser padronizados na corporação,
com a arquitetura suportando o mix.
“Não é complicado passar do estágio 1 para o 2”,
diz McGrane. Apesar de consumir muito esforço,
nesta altura do campeonato os fornecedores, os
consultores e a equipe de TI já conhecem as táticas
e estratégias para a padronização bem-sucedida de
uma plataforma. “Passar do estágio 2 ao 3 exige mudança
organizacional e responsabilidade empresarial,
o que é muito mais difícil.” A transição para o
estágio 4 é ainda mais complexa, segundo McGrane.
“Requer uma redefinição daquilo que você, como
empresa, está fazendo.”
A evolução do estágio 1 para o 2 está a cargo, principalmente,
do departamento de TI. O ROI prometido
é redução de custos. A evolução para os estágios
3 e 4, entretanto, exige uma mudança de enfoque
fundamental — o foco não é mais o modo
como TI é capaz de satisfazer necessidades imediatas
e definidas das unidades de negócio, e sim o desenvolvimento
de processos de negócio que possam
ser fornecidos através de serviços de TI modulares.
O ROI prometido é agilidade empresarial. “A
questão não é simplesmente gerenciar custos, mas
transformar a empresa. Se o CEO e o CFO não entenderem
isso, você está acabado”, alerta McGrane.
ESTÁGIO 2: SANIDADE DA PLATAFORMA
No estágio 1, o CIO identifica facilmente a pressão
para migrar de silos à plataformas padronizadas. O
negócio reclama de custos de TI crescentes e cronogramas
de entrega mais longos enquanto TI luta
com a complexidade cada vez maior de todas as peças
que precisa gerenciar e integrar. Mas padronizar
a plataforma de uma empresa não é tão simples
quanto pode parecer. O primeiro passo é decidir
exatamente o que deve ser padronizado.
“Faz sentido padronizar no nível da rede, mas não
em uma área de negócio específica”, explica Saul,
da State Street. Uma rede de armazenamento e um
sistema de e-mail comuns reduzem os custos e
aprimoram o compartilhamento de informação.
Mas operadores de ações talvez precisem de funções
de aplicação diferentes dos operadores de derivativos,
por exemplo, mesmo que muitas funções
subjacentes, como gestão e relatório de clientes,
sejam idênticas. “Hoje, nossa arquitetura corporativa
é em camadas, começando com elementos como
a rede, o hardware e os sistemas operacionais,
e prosseguindo com middleware e bancos de dados,
até alcançar as aplicações. As diferenças nas empresas
podem ser muito sutis e restritas à camada de
aplicação. A idéia é padronizar em torno de funções
onde for possível, mas não no nível do negócio. Assim,
os designers podem se concentrar em serviços
de negócio que nos dão dianteira, ao mesmo tempo
reutilizando componentes core”, diz Saul.
O passo seguinte é aprender a lidar com a transição
dos sistemas existentes para os novos padrões.
Você tem que migrar não só a tecnologia, mas também
seus usuários. E, observa Saul, você está fadado
a se confrontar com tecnologias não aderentes
que estão executando, e bem, um trabalho importante.
Para tratar destas questões, a State Street
montou um comitê arquitetural no início do trabalho
de padronização. Ao decidir prioridades de padronização,
o comitê começou com os objetivos do
negócio, garantindo que TI não padronizasse inadvertidamente
uma tecnologia crítica para o negócio.
A abordagem do comitê plantou as sementes
da cooperação entre negócio e TI que seria necessária
alguns anos depois, no estágio 3.
Um aspecto mais sutil da transição para o estágio
3 é o fator humano, de acordo com John Petrey, vice-
presidente executivo e CIO da empresa de operações
bancárias e financeiras TD Banknorth. No estágio
1, as empresas e seus funcionários estão focados
(compreensivelmente) em resolver problemas
individuais específicos. Para os solucionadores
de problemas, a padronização de tecnologias pode
significar perda de controle e talvez até de soluções
ideais. “As pessoas demoram a perceber que é preciso
compartilhar mais coisas para obter os benefícios
que todo mundo busca”, aponta Petrey. Na verdade,
esta mudança cultural ocorre aos poucos.
“Você não acorda, um dia, e está em uma cultura diferente”,
analisa Petrew.
As empresas também precisam de uma medida
de resolução para obter êxito. Com freqüência,
uma crise mostra com clareza por que a mudança
é necessária. Outras vezes, os líderes da empre23
CAPÍTULO 5
sa possuem carisma, força ou personalidade para
efetuar a mudança. Na TD Banknorth, Petrey implementou
uma abordagem sem misericórdia para
a padronização nas empresas adquiridas. “Nós
tiramos e substituímos”, afirma. Assim, a heterogeneidade
de plataforma não tem um pé de apoio
na organização.
ESTÁGIO 3: HORA DA COLABORAÇÃO
Depois que uma organização padroniza suas plataformas,
os processos de negócio e de TI são o próximo
lugar lógico onde buscar eficiências. A fabricante
de produtos químicos Celanese, por exemplo,
economizou cerca de 40% dos custos de TI através
de uma iniciativa de padronização e consolidação
que consumiu quatro anos, recorda o CIO Karl
Wachs. A empresa reuniu sete data centers em um
e 13 sistemas ERP em um. A consolidação começou
no estágio 2 como uma iniciativa de plataforma e
foi concluída no estágio 3, quando a empresa conseguiu
iniciar a padronização de processos de negócio
necessária para administrar a empresa sobre
um sistema ERP.
Entender processos de negócio o suficiente para
padronizá-los não é tarefa pequena, na opinião de
Wachs. Demanda colaboração intensa entre TI e o
negócio. Mas o esforço ajuda ambos os grupos a entender
que unidades de negócio diferentes utilizam
muitos processos-chave iguais. “A unidade de
produtos químicos básicos e as unidades de plásticos,
por exemplo, operam de maneira diferente,
com processos de vendas diferentes e, conseqüentemente,
implementações de CRM diferentes”, diz
Wachs. “Mas, na realidade, são variantes da mesma
funcionalidade, o que nos permitiu colocar todas as
funções no mesmo sistema e torná-las configuráveis
para cada linha de negócio.”
Para fazer a análise profunda que permitirá este
entendimento, você precisa de métricas contínuas,
salienta Wachs. Sem elas, não pode garantir a governança
apropriada de seus serviços, muito menos de
seus processos de negócio. Schmelzer, da ZapThink,
aponta que governança, neste caso, significa tanto
as políticas para processos de negócio e de TI específicos
quanto o sistema através do qual a empresa
decide de que forma cria e implementa seus sistemas
de negócio e de TI, como requisitos de análise
arquitetural e prioridades de financiamento.
A transição do segundo para o terceiro estágio
pode produzir benefícios sutis. Na TD Banknorth,
as unidades de negócio precisavam de produtos
mais sofisticados para competir. Isso exigia que
TI aprimorasse continuamente suas habilidades e
seus níveis de sofisticação. Ao mesmo tempo,
pressões de custos exigem que o CIO forneça estas
ferramentas mais sofisticadas com o mesmo
nível de recursos. Esta pressão leva a uma abordagem
de otimização, conduzindo a empresa ao terceiro
estágio de arquitetura.
É neste terceiro estágio que arquitetura começa
a significar mais do que infra-estrutura de TI. Arquitetura
de dados, governança de TI, otimização de
processo Six Sigma e alinhamento entre negócio e
TI se tornam aspectos críticos da arquitetura corporativa.
O foco de TI muda: deixa de ser apenas o
gerenciamento eficaz das instalações de tecnologia
e passa a ser a contribuição para a excelência
operacional do negócio. A eficiência continua importante,
mas a meta não é mais economizar dinheiro
reduzindo os custos, e sim liberar recursos
para serem empregados no crescimento do negócio,
segundo Petrey.
Ao entrar no estágio 3, a TD Banknorth começou
a prestar muito mais atenção na arquitetura
de dados, por exemplo. “Você precisa investir recursos
expressivos para evoluí-la e planejá-la”,
afirma Petrey. Isso envolve garantir definições de
dados padrões para que múltiplos sistemas funcionem
mais facilmente com os mesmos dados e
os interpretem corretamente, e possam colher
modelos que ajudem a servir melhor os clientes.
A TD Banknorth designou membros da equipe de
TI, que se entrincheiram nas linhas de negócio e
agem como gerentes de relacionamento com
seus colegas na empresa para assegurar o verdadeiro
alinhamento de TI com o negócio.
Embora a TD Banknorth tenha padronizado suas
plataformas de tecnologia, nem sempre impôs seus
padrões arquiteturais sobre as aplicações que comprou
ou criou. “O motivo foi o crescimento rápido,
estávamos mais preocupados em trazer algo”, recorda
Petrey. “Cometemos este pecado no passado
24
CAPÍTULO 5
e ele reduziu nossos níveis de serviço e interferiu
na nossa capacidade de fazer a empresa progredir”,
desabafa o executivo. Agora, Petrey está empenhado
em fazer estes sistemas com desvio arquitetural
encaixarem em sua nova arquitetura de TI para
que a TD Banknorth possa continuar amadurecendo
no estágio 4. A governança está mais rígida para
que o problema não se repita.
O foco na arquitetura também cria as bases para
futuros benefícios, acredita Joe Solfaro, diretor executivo
de gestão de informação da Merck, fabricante
de produtos farmacêuticos. Grande parte dos esforços
de TI se concentra em padronizar plataformas,
mas a empresa também está mapeando seus
processos de negócio e sua arquitetura de dados
para aumentar a agilidade quando tiver uma plataforma
mais eficaz em termos de custos. A Merck
deu início a dois projetos distintos de padronização
de dados há muitos anos, mas só recentemente
contratou profissionais de arquitetura corporativa
para desenvolver uma arquitetura de dados comum
que esteasse a ambos. “Ainda que com diferenças
táticas, os sistemas vão suportar a mesma direção
estratégica”, diz Solfaro. Isso resulta em uma gestão
de dados mais fácil, que acabará por suportar
SOA completa no estágio 4.
Culturalmente, o estágio 3 requer que as equipes
de TI e de negócio relaxem. “Você precisa deixar de
ser tático. Tem que confiar a outros a tarefa de gerenciar
os detalhes”, aconselha Petrey. Parte desta
mudança acontece na transição do estágio 1 para o
2, mas no estágio 3 é mais difícil relaxar porque tipos
de pessoas muito diferentes — TI e negócio—
têm que depender umas das outras e confiar umas
nas outras. E, assim como a migração do estágio 1
para o Estágio 2, a mudança para o estágio 3 acontece
paulatinamente, à medida que a organização vê
o ROI da nova abordagem e apóia a transformação.
ESTÁGIO 4: MODULARIDADE DO NEGÓCIO
Pouquíssimas empresas se encontram neste ponto.
Não mais do que 6% das cerca de 450 empresas pesquisadas
pelo CISR. Os CIOs que estão na fase final
do estágio 3 já podem vislumbrar como será o 4. De
acordo com o CIO Wachs, algumas partes da Celanese
passaram para o estágio 4, enfocando processos
modulares que podem ser gerenciados facilmente
em uma ampla arquitetura corporativa. “As
empresas só são ágeis se conseguem ativar e desativar
determinadas funções”, sustenta Wachs, e para
tanto precisam entender que funções são essas,
onde são utilizadas e o que elas afetam. Por sua vez,
isso requer uma arquitetura projetada para flexibilidade
e consistência.
A State Street também acredita que está no início
do estágio 4. “Temos que melhorar os níveis de
entendimento de processos de negócio e de comunicação
do pessoal de TI”, reconhece Saul. “A linha
que divide TI e negócio está desaparecendo e fica
claro que alguém terá que gerenciar ambos.” Para
algumas empresas, isso significa que TI poderá se
tornar parte de uma iniciativa de serviços compartilhados.
(Para conhecer melhor que tipo de função
o CIO terá neste tipo de estrutura organizacional,
leia o box “EA muda tudo”.)
O que ainda não está muito claro é como será uma
organização plenamente amadurecida no estágio
4, observa McGrane, da MeadWestvaco. “Estamos
apenas começando a entender como usar TI para
promover agilidade e virar o jogo versus aprimoramentos
incrementais.” McGrane não está seguro
de que tecnologias capacitadoras já existam realmente.
De uma coisa, porém, ele tem certeza: “a
empresa não pode passar para o estágio 4 sem ter
atingido o 3, porque ele estabelece a orientação de
processos necessária para que a empresa seja vista
como módulos, conforme exige o último estágio”.
UM LONGO CAMINHO
Embora seja tentador pensar em cada estágio como
um lugar onde chegar, o mais correto é encará-lo como
um processo transformador, com a corporação
migrando gradualmente de um estágio para outro,
define Ross, do CISR. O volume de mudança é imenso
e, mais importante, as pessoas têm que mudar
junto com a tecnologia. Os CIOs devem promover
implementações incrementais e prometer valor incremental,
tanto para suavizar o impacto da mudança
quanto para alimentar o entusiasmo da gerência
pela iniciativa, orienta Wachs, da Celanese.
Na verdade, tendo em vista o legado das fusões,
os diferentes níveis de necessidade e de adesão do
25
CAPÍTULO 5
negócio e as forças externas como as regulamentações,
é freqüente as empresas descobrirem que se
encontram em estágios diferentes simultaneamente.
Na Celanese, por exemplo, o sistema de RH
continua no estágio 2 por causa de requisitos da folha
de pagamentos, ao passo que outras partes da
empresa já estão entrando no estágio 4.
Por maior que seja a pressão para aumentar a eficiência
e a agilidade — “É pra ontem!” — as empresas,
ao contrário de X-Men, não podem queimar etapas
em sua evolução, alerta Ross, da CISR. Cada estágio
prepara o terreno tecnológico, procedural,
cultural e comportamental para o estágio seguinte.
A impossibilidade de pular estágios é real até
mesmo em empresas onde uma entidade está à
frente das outras. Em 2002, McGrane achava que a
Mead estava no estágio 3, mas aconteceu a fusão
com a Westvaco, que se encontrava no estágio 1.
No cargo de CIO da nova MeadWestvaco, McGrane
teve que fazer a empresa recém-adquirida atravessar
o estágio 2 antes de levá-la ao estágio 3. Agora,
a organização unificada está perto de atingir um nível
de maturidade uniforme.
As empresas também precisam entender que a arquitetura
nunca estará concluída. “A idéia é sempre
ajustar o serviço, não necessariamente a implementação:
reunir dois serviços mais granulares em um
serviço composto ou vice-versa, por exemplo”, diz
Schmelzer, analista da ZapThink. Normalmente, os
CIOs não contam com talentos para isso. Schmelzer
recomenda que os CIOs tenham um arquiteto chefe
ou uma equipe de arquitetura reportando a eles.
Não importa como uma empresa gerencia a evolução
de sua arquitetura, ela precisa ter em mente
que a recompensa é a jornada em si, aconselha Ross,
da CISR. “O ponto final é muito menos importante
do que o aprimoramento contínuo conquistado.
Você tem que melhorar um pouquinho a cada dia.
Não se trata simplesmente de chegar ao estágio 4.”
NÃO HÁ LUGAR MELHOR QUE O LAR
O ideal é que as investidas em estágios de arquitetura
mais amadurecidos tenham início no próprio
departamento de TI. Assim, você pode testar abordagens,
assegurar que elas funcionam e reduzir as
chances de que algum passo em falso em uma unidade
de negócio impeça a evolução, recomenda Jim
McGrane, ex-CIO da MeadWestvaco. Estes esforços
dentro de TI também dão aos CIOs a prova de conceito
de que necessitam para conquistar a adesão
do negócio. Além disso, começar com TI rebate uma
queixa muito freqüente: os CIOs gostam de mudar
os processos de todo mundo, menos os deles.
A Merck também está seguindo este caminho, de
acordo com Joe Solfaro, diretor executivo de gestão
de informação. “Vamos agir de dentro para fora”,
revela. TI está usando uma plataforma de integração
para unificar a arquitetura de mensagem da
empresa, o que, a princípio, parecia um ganho de
eficiência muito focado em tecnologia da informação.
Mas a iniciativa está obrigando TI a mudar suas
próprias operações internas e proporcionando uma
interface natural com o negócio. “Colocar a informação
em uma única base nos dá acesso a informação
que nós sabemos que o negócio vai querer, como
gestão de processos, e mais visibilidade dos processos
de negócio”, diz Solfaro.
Abordagens como Capability Maturity Model for
Integration (CMMI) e IT Infrastructure Library (ITIL)
são bons métodos de processos que ajudam TI a migrar
para o estágio 3, observam McGrane e Solfaro.
“Ajudam a organização a focar em processos e obrigam
você a determinar o valor de serviços e a operar
como um negócio”, afirma McGrane.
MUDANÇAS NA ARQUITETURA
TRANSFORMAM O PAPEL DO CIO
À medida que uma empresa evolui através dos diversos
estágios de maturidade arquitetural, a função
do CIO evolui junto, diz Jeanne W. Ross, pesquisadora-
chefe do MIT Sloan Center for Information
Systems Research. Nas empresas que estão
no estágio 1, o trabalho do CIO é manter as instalações
de tecnologia. No estágio 2, o CIO desempenha
um papel mais estratégico: coordenar a
transição para uma plataforma comum e seu impacto
na empresa. “Às vezes, quando as organizações
estão percorrendo o estágio 2, é observada
uma estranha tendência a trazer alguém que não
é de TI”, observa Ross. À proporção que a tecnologia
se estabiliza no estágio 2, questões de processo
vêm para o primeiro plano e um CIO focado em
26
CAPÍTULO 5
tecnologia talvez pareça menos capaz de lidar
com elas, justifica Ron Schmelzer, analista sênior
da ZapThink, empresa de consultoria sobre SOA.
A função do CIO começa a cruzar as fronteiras organizacionais
na jornada para o estágio 3. Ironicamente,
quando uma empresa ingressa no estágio 4
e os líderes de negócio ganham mais controle sobre
a implementação de serviços de TI, a função do
CIO, outra vez, pode se tornar mais tática, diz o ex-
CIO e atual VP da MeadWestvaco, Jim McGrane. Ao
detectar o início desta mudança na empresa,
McGrane decidiu que não era este o trabalho que
queria. (Em abril, ele deixou o cargo para se dedicar
a outras áreas.) Mas a perda da dimensão política do
cargo de CIO não é inevitável, argumenta Judith
Hurwitz, CEO da empresa de consultoria Hurwitz &
Associates. “Você pode focar em inovação porque
as eficiências operacionais proporcionadas [por
SOA] lhe dão este tempo.”
Quando as empresas atravessam os estágios de
maturidade mais avançados, a área de TI também é
afetada. “TI deve fazer parte de algo maior, como
serviços compartilhados, operações ou finanças”,
despindo-se de seu papel de mera fornecedora de
tecnologia”, diz Ross. Nesta evolução, o CIO se torna
o chefe — ou líder — de uma operação mais ampla.
A gigante de serviços financeiros State Street,
por exemplo, promoveu a fusão entre TI e operações.
Na Merck, fabricante de produtos farmacêuticos,
TI passou a fazer parte de serviços compartilhados.
Recentemente, o mesmo aconteceu na
MeadWestvaco, fabricante de papéis.
Mas é a visão da empresa sobre as habilidades individuais
do CIO que vai determinar realmente que
função ele terá em uma organização no estágio 4.
De acordo com Schmelzer, muitas empresas têm
um vice-presidente de marketing e vendas, cargo
que reúne duas funções muito diferentes. Outras
empresas têm um executivo separado para cada
atividade. A função de TI é ainda mais ampla, diz
Schmelzer, combinando arquitetura, design, e integração
e operações. Poucos CIOs serão fortes em
todas as três áreas. Alguns serão fortes em apenas
duas. A gerência talvez veja TI como uma função
distinta ou um subconjunto de uma organização
de serviços maior. Porém, independentemente da
estrutura organizacional, o CIO precisa ser tão
cônscio do negócio quanto da tecnologia.
Projetos de arquitetura orientada a serviços (SOA) estão
cada vez mais freqüentes, segundo relatório do
Yankee Group. A consultoria entrevistou 306 executivos
de TI dos Estados Unidos e 84% deles disseram
já ter uma implementação do gênero em andamento
ou nos planos para o ano que vem.
SOA é uma abordagem de design de software
que promove o desenvolvimento e a integração
de componentes reutilizáveis, baseados em elementos
de processos de negócios. Por exemplo,
se os elementos de um processo de negócio requeridos
pelos clientes para comprar produtos
online (como checagem de inventário e de crédito)
estiverem em diferentes sistemas, “escrever”
cada componente como se fosse um serviço permitiria
a rápida integração e entrega da informação
necessária para completar a transação. Como
os serviços podem ser modificados sem afetar os
usuários, SOA visa a reduzir o tempo de desenvolvimento,
os custos e facilitar a reconfiguração de
processos de negócios.
Com a economia obtida, as melhores candidatas
a implementar projetos de SOA são áreas com
maior impacto no planejamento estratégico, diz
Tom Dwyer, diretor de pesquisas do Yankee. Ele
acrescenta que para a maioria das empresas pesquisadas,
essas áreas são aquelas com maior contato
com os clientes, as que impactam diretamente
o faturamento.
Dentre os respondentes que já implementaram
SOA, o conceito pode ser visto com freqüência em
áreas como portais e sites com interação direta
com clientes (30%) e áreas de suporte e help desk
(29%). Mas o futuro pertence à integração interna.
Nada menos que 73% dos respondentes disseram
que estão avaliando ou desenvolvendo projetos
de SOA para integrar aplicativos internos de
negócios, e 72% estão buscando implementar
SOA para agregar dados e conteúdo.
MELHORES PRÁTICAS
1 – COORDENE INVESTIMENTOS EM SOA
Cada projeto de SOA deve ser revisado por um time
multidisciplinar com a responsabilidade de estabelecer
e manter os padrões de arquitetura de TI. Esse
time tem de estar certo que cada projeto SOA
pode ser integrado com aqueles que vieram antes.
2 – MAPEIE OS PROCESSOS DE NEGÓCIOS
Enumere todos os serviços corporativos que suportam
operações de missão crítica e tente adivinhar
como eles se inter-relacionam. “Você provavelmente
não vai querer fazer isso, mas é uma tarefa
cada vez mais importante para qualquer projeto
SOA”, alerta Dwyer. Contar com um mapa de
todos os serviços é uma garantia de que a empresa
não perderá dinheiro em projetos desnecessários
e que, ao mesmo tempo, conseguirá se adaptar
rapidamente a mudanças nos modelos de negócios,
caso isso seja necessário.
3 – DEFINA OS DADOS
Crie definições de dados que serão utilizados para
construir os aplicativos de um projeto de SOA.
As definições poderão ser padronizadas pela própria
companhia.
O que você deve fazer
na hora de adotar a SOA
27
CAPÍTULO 6
Estudo mostra que companhias priorizam áreas de missão crítica
PLANOS PARA O DESENVOLVIMENTO DE SOA
43% 41%
16%
JÁ USA
USARÁ EM 2 ANOS
USARÁ EM 1 ANO
28
CAPÍTULO 6
PRINCIPAIS ÁREAS PARA OS INVESTIMENTOS EM SOA
Processos que envolvem interação direta com o cliente, integração interna
e acessibilidade aos dados são as prioridades
DOS QUE JÁ IMPLEMENTARAM
30%Sites e portais de interação com clientes
29%Help desk e suporte
25%Integração de aplicativos internos de negócios
DOS QUE ESTÃO PLANEJANDO SOA
73%Integração de aplicativos internos de negócios
72%Agregação de dados e conteúdo e acessibilidade
65%Sites e portais de interação com clientes
65%Supply chain/ procurement
*Fonte: The Yankee Group