Pergunta: Se quero expor serviços na “nuvem” (seja para aplicações, seja para processos), existe uma forma de ter serviços que representem as necessidades de negócio, sejam desacoplados, prontos para B2B, com arquitetura madura e etc?
Resp: Ah, tem sim . E nós, escribas e leitores de SOA sabemos disso.

Segue matéria, leitura rápida!

Arquitetura SOA cria plataforma para cloud computing, diz IDC

De acordo com analista da consultoria, nuvem é uma das tecnologias responsáveis pelos investimentos na arquitetura orientada a serviços, que devem crescer até 25% em todo o mundo entre 2008 e 2013.
Por COMPUTERWORLD/REINO UNIDO

Os investimentos realizados na Arquitetura Orientada a Serviços (SOA, da sigla em inglês), vão crescer até 25% em todo o mundo entre 2008 e  2013, de acordo com a consultoria IDC. O vice-presidente de aplicações empresariais da IDC da Europa Central, Ruediger Spies, afirmou que o crescimento será liderado pelos países das Américas, seguido pela região chamada EMEA, que compreende Europa, Médio-Oriente e África.

A declaração contraria rumores de mercado que diz que os investimentos em SOA teriam chegado ao seu final. Segundo Spies, a crença não poderia estar mais errada. E uma das razões é que a arquitetura é uma das melhores maneiras de proporcionar uma plataforma para implantar computação em nuvem.

Segundo Spies, é verdade o fato de que SOA ajuda no alinhamento entre a tecnologia e as necessidades de negócios. No entanto, a única forma de ter sucesso é pensar no longo prazo. “Arquitetura não é uma coisa simples, é um projeto que deve estar na pauta por alguns anos. O ciclo de vida chega a ser maior que os projetos de ERP, que chegam a durar entre 12 e 13 anos”, diz.

A escolha do arquiteto SOA é um dos pontos cruciais no sucesso da empreitada. O profissional precisa ser experiente, bem aceito tanto pelas áreas de negócios quanto de tecnologia, além de ser capaz de enxergar o valor da arquitetura para os negócios, além de fazer com que a área de negócios entenda as contribuições que SOA pode proporcionar em todas as pontas.

Se bem implantado, a SOA ainda cria uma base para estratégias de gerenciamentos de processos de negócios (BPM, da sigla em inglês), que por sua vez influencia na implantação adequada de cloud computing. “Se a empresa estiver em dia com SOA, terá um caminho desenhado para a arquitetura de processo e a arquitetura de informação, elementos responsáveis pelo alicerce das tecnologias e pela integração das mesmas”.

fonte: computerworld

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. SoundCloud – Música nas nuvens
3. Davi x Golias em SOA

Li um artigo da ZapThink recentemente que contrasta os fornecedores de infraestrutura para SOA (ferramentas e middleware) num interessante embate entre empresas gigantes e as menores, focadas em SOA.

O artigo completo segue abaixo, mas me permito resumí-lo da seguinte forma:

• O mercado SOA sofreu forte consolidação em seus fornecedores e hoje apresenta 5 big-players e alguns fornecedores menores (de nicho, startups e open-source)
• Comentam sobre restrições que as empresas possuem quanto ao investimento em soluções de empresas menores e afirmam que o investimento nas big-players é tão arriscado quanto ou até mais;
• Por fim, colocam também que o caráter mais inovador das ofertas aliada a uma política de preço mais agressiva e facilidades para influenciar a direção dos produtos são destaques positivos em se investir em empresas menores

A conclusão do artigo é bem interessante:

(…) ZapThink is very concerned that the rapid consolidation and maturation of the enterprise IT landscape will have a negative outcome on innovation in the marketplace. We believe that the consolidation is resulting in mammoth conglomerates of vendors that will be harder, more confusing, and more expensive to work with. We believe that there is just as much uncertainty around the future of the large vendor’s offerings as there are with startup offerings. In this light, we don’t believe that there’s anything more inherently risky about a startup solution than an established, incumbent vendor solution.

Grande abraço,
Kleber

Segue o artigo completo:

Including Startups in your SOA Infrastructure: A Guide for Enterprise Architects

Document ID: | Document Type: ZapFlash
By: Ronald Schmelzer | Posted: March 25, 2010

In a previous ZapFlash, ZapThink opined that Open Source Software could play an important role in your Service-Oriented Architecture (SOA) Infrastructure. Certainly, there were no architectural reasons why it couldn’t. As we explained in that article, the primary biases against OSS (if there are any) are from the people in the organization who have fear, uncertainty, or doubt about the risks or benefits of OSS. But of course, that article spoke at a fairly general level. Individual implementations or products might be better than others, or more suited for specific problems than others. This is where Enterprise Architects should spend their time focused – on the specific solutions to specific problems, rather than engaging in religious battles about the merits of entire classes of solutions.

Unfortunately, in addition to the biases against OSS, many companies have developed aversions to solutions from startup companies. Yet, in an environment where we are left with just a handful of incumbent companies remaining in the SOA infrastructure landscape, and these vendors have confusing collections of often conflicting and competitive infrastructure products, it might be a good time to revisit utilizing solutions from niche, best-of-breed, and often startup, solutions in your SOA environment. However, how do you do so without incurring substantial real or perceived risk? After all, it is the nature of a startup company to change, be acquired, or die. In this environment, EAs need to become wholeheartedly selfish: meet the requirements of the business in an agile manner by reducing the penalty for failure. In such an environment, startup solutions are not only feasible, but very appropriate.

Best of Breed in an Increasingly Suite World

Through a combination of consolidation, maturation, and the pressures of a tough economic environment, the landscape of enterprise IT software players has dwindled to a handful of companies that control the infrastructure for a vast majority of companies. Just like the auto industry experienced a period of rapid growth and diversity in the early part of the 20^thcentury, only to consolidate down to the “Big three” in the United States and a similar number in countries around the world, we are now faced with the reality of a “Big Five” set of vendors in the enterprise IT marketplace, especially in the area of SOA infrastructure.

However, consolidation is not always a friend of innovation. Many have argued that the consolidation of the auto industry in the US by the late 1970s resulted in products that were unable to compete with offerings from overseas. Indeed, it’s in the period after the consolidation that the US manufacturers saw its most precipitous decline in worldwide share of automobiles. Why is this? Is it because large companies can’t innovate? Or is it that the large portfolio or products and services are confusing not only to customers but even to internal managers? When one company owns Pontiac, Buick, Oldsmobile, Chevrolet, and a myriad of other brands, how can anyone really tell when one product is best suited for a problem or another? These brands compete for dollars not only among customers, but among their own budgets. Much hay has been made of Microsoft’s internal competition and struggles that have hindered its own ability to compete. Why should it be any different for the enterprise IT software companies that have grown primarily through acquisition?

Innovation is incredibly important in an area of continued maturation such as SOA. More importantly, agility is a key benefit of SOA, which means that properly designed architectures should not only be implementation-neutral, they should be fairly immune to infrastructural change. In this light, vendor selection is less a matter of making sure your infrastructure works and more a matter of picking the right vendor for the job while balancing risk and economic factors. In this light, startup and niche companies offer just as much opportunity, if not more, to advance your architectural efforts than those of large vendors. The only things that differentiate the startups from the large vendors are three core issues: the scope of their offerings, the potential risk of company failure, and the ability to negotiate price to your benefit.

Mitigating the Startup Risk: Enterprise Software and Cloud / SaaS Concerns

The biggest risk that many cite in working with startup companies is the risk that they might simply no longer exist. This fear is especially pronounced for companies that must spend a considerable amount of time and money implementing the solutions. If an enterprise is involved in a multi-year effort to implement a large-scale, highly visible, and important solution for the company, then in many cases startup solutions are ruled out very early in the vendor evaluation process. This is even if the startup company offers a better, more appropriate, and more innovative solution. The real issue here is whether the risk of company failure, real or perceived, should outweigh the loss of solution appropriateness and innovation. Or in other words, does it make sense for companies to implement less-optimal solutions based on what they know today because they fear an unknown event in the future?

Rather than rule out startup solutions out of hand, companies should mitigate vendor failure by incorporating such contingencies in their enterprise architecture. We would argue such vendor mitigation plans should be made for well-established vendors as well, since internal political or budgetary battles might result in the disappearance of even decades-old products.

There are two major areas of mitigation for enterprise IT vendor products: products that companies install, manage, and own in their own infrastructure (traditional enterprise software products sold by the license), and those solutions that are run and managed on the vendor’s infrastructure (such as Cloud or Software-as-a-Service [SaaS] offerings). In the case of licensed enterprise software, it has long been a practice of end-user companies to require that the vendor’s software code be held in escrow such that if the vendor goes out of business, it is transferred to the ownership of the end-user customer. While this is a far from optimal solution (after all, the company has no knowledge or ability to do much with the code), it provides some level of comfort to the buyers that the code at the very least won’t disappear.

More complicated is a mitigation plan for Cloud / SaaS offerings. If a SaaS vendor disappears, what happens to the code? If a Cloud vendor goes under, what happens to the infrastructure? More importantly, what happens to your data? It’s not enough to simply require that the vendor hand over the code for their SaaS implementation; in the event of their failure, you have to also implement all the infrastructure that makes the Cloud work or keeps the SaaS solutions running. This is because the economic benefit of Cloud computing and SaaS solutions is that you’re not paying the full cost of owning and managing the solution. It is easy to mitigate the data component of the Cloud / SaaS default risk – simply make sure that you maintain a “local” copy of all relevant data.

However, in order to mitigate the loss of application functionality and infrastructure, a company needs to have a backup plan. Enterprise architects need to discover or implement comparable Services run internally or on another Cloud / SaaS service. Or, companies should require an escrow provision similar to what is provided by licensed enterprise software vendors – if the SaaS / Cloud vendor goes belly up, they have to hand over not only the code and data that makes the application work, but also configured infrastructure on which to run it. While the hope is that these escrow provisions will never have to be enacted, they provide the security blanket necessary to give one at least a psychological sense of security.

Negotiation Leverage: It’s on your Side with Startups

Mitigation and product functionality issues aside, there is another good reason to work with startup vendors: it’s much easier to get your way with smaller companies hungry for your business. Smaller vendors have less layers of corporate infrastructure, and many times you are in direct communication with the individuals responsible for the functionality of your implementation. In this way, it’s easier to get your voice heard on features or bug fixes. Don’t like the way something works or want a new feature? Pick up the phone and talk directly to the product or development managers, or even the CTO. Perhaps you’ll get a fix the same day or within a very short timeframe. Try that with one of the super-vendors.

It’s also easier to negotiate on price. While large vendors might be able to discount or cut the price on one of their offerings so they can make another one sweeter, the realities of large sales forces and commission structures requires them to keep their products at a certain (increasingly higher) price point. Smaller companies are more eager to negotiate, especially if you are a large enterprise that could be a marquee name for them.

Finally, it’s easier to get help with your specific implementation from startup companies. Many enterprise software startup companies know that their products are not plug-and-play and require some additional effort and expense to set them up. As a result, many startups have professional services arms whose goals are not to drive revenue for the company, but rather to support the products in customer installations. Unless the startup vendor charges for this additional service (and we regularly counsel them notto), you should consider this to be free consulting and professional services help. Use as much of this as possible, and even negotiate more into your contract. It is in yours and the startup’s best interests to make sure you get the value you require from your investment.

The ZapThink Take

As you can see from the past few ZapFlashes, ZapThink is very concerned that the rapid consolidation and maturation of the enterprise IT landscape will have a negative outcome on innovation in the marketplace. We believe that the consolidation is resulting in mammoth conglomerates of vendors that will be harder, more confusing, and more expensive to work with. We believe that there is just as much uncertainty around the future of the large vendor’s offerings as there are with startup offerings. In this light, we don’t believe that there’s anything more inherently risky about a startup solution than an established, incumbent vendor solution.

The only thing that has us concerned about the startup landscape is the shortage of new startups. We’ve seen a significant drop-off in new enterprise software venture creation. We are not entirely sure why this is. Is there simply less demand for new enterprise software solutions? Is there less opportunity for new enterprise software startups? Has the venture capital and finance community lost interest with enterprise software? Or has the area of innovation moved away from enterprise software? We hope none of these things are true. The enterprise still has leagues to go to get closer to the vision of loosely-coupled, agile, heterogeneous systems that can meet the ever-changing needs of business with high governance and low risk. There’s plenty of opportunity here. Startups: do your part innovating in this space. Enterprises: do your part and implement startup companies’ offerings so that innovation does not come screeching to a halt.

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. SOA ajuda Cloud? Sim!
3. Gartner Enterprise Technologies Summit 2010

Vai acontecer no dia 29 de OUTUBRO* um Webinar sobre Maturidade e Roadmap SOA, e recomendo fortemente a participação de todos! A apresentação será em português. A participação é aberta, com duração de uma hora. Você assiste aí, no seu computador, e ainda pode dar seus pitacos e enviar perguntas.

Acredito ser uma ótima oportunidade para assistir (e participar) de uma apresentação adequada ao cenário nacional, considerando a realidade das empresas de TI brasileiras e os níveis de maturidade SOA utilizados em diversas consultorias. Um dos apresentadores é este blogueiro que vos escreve, juntamente com Kleber Bacili (Diretor de tecnologia da Sensedia). Faça sua inscrição.

Para maiores detalhes e conteúdo da palestra, veja divulgação abaixo (ou aqui).

Detalhes do Webinar:

Data: 29/10/2009
Horário: 14hs

Em cenários de implantação estratégica de SOA, diferentes perspectivas devem ser consideradas: Mecanismos arquiteturais e padrões de desenvolvimento de serviços, Governança, Metodologia, Infraestrutura e também as Aplicações e Informações já existentes na empresa.

Muitas vezes, as empresas focam esforços na implementação dos serviços em si e acabam negligenciando as outras perspectivas. Entender como balancear as ações nas perspectivas mencionadas acima e como realizar os investimentos nos momentos certos é fundamental para a empresa otimizar os custos envolvidos e antecipar os resultados almejados com a iniciativa SOA

Neste webinar apresentaremos:

• Níveis de maturidade SOA com as suas diferentes perspectivas;
• Como avaliar sua própria maturidade conforme o modelo e os benefícios gerados em cada fase;
• Abordagem Lightweight SOA de priorização e geração de valor;
• Quais competências devem ser desenvolvidas;
• Principais padrões técnicos, mecanismos e boas práticas que devem ser consideradas em seu planejamento;
• Como planejas as ações nas diferentes perspectivas de forma a otimizar custos e antecipar resultados.

abraços,
Marcílio

Related posts:

1. Lembrete! Webinar SOA.
2. Princípios Básicos de SOA – Serviços são Capazes de se Compor
3. SOA ajuda Cloud? Sim!

Dando uma olhada rápida aqui no blog, encontrei diversos posts falando de crise, investimentos e SOA:

• Aprenda a calcular o ROI em SOA
• Governança SOA Light
• Quanto vale SOA
• SOA em tempos de crise

Porém, apesar da discussão, a preocupação ainda não é regra. Conforme o texto abaixo:

40% dos usuários de SOA não medem o tempo necessário para ROI

por Reseller Web
25/05/2009

Gartner aponta que 50% dos entrevistados que não utilizam SOA não adotaram a tecnologia por não conseguirem demonstrar o valor que ela tem

Segundo o Gartner, “as organizações devem ter expectativas realistas e identificar métricas de sucesso que estejam de acordo com a empresa para obter valor a partir da arquitetura orientada aos serviços (SOA)”. Uma pesquisa global, realizada com 200 companhias no quarto trimestre de 2008, descobriu que 40% dos usuários de SOA não medem o tempo necessário para o retorno dos investimentos (ROI).

Já 50% dos pesquisados que não utilizam SOA não adotaram esses sistemas porque não conseguem articular e demonstrar o valor que ele tem para os negócios.

Para ter certeza de que as expectativas sejam realistas e que a empresa tomou medidas precisas com relação às suas metas, o Gartner recomenda que as organizações se concentrem inicialmente em obter somente um benefício chave da lista de vantagens comerciais de SOA. À medida que os esforços com a tecnologia ficarem amadurecidos, e os benefícios começarem a surgir, elas poderão acrescentar mais benefícios e mudar ou acrescentar novas medidas de acordo com a situação.

A escolha dos benefícios depende de qual o valor comercial mais urgente ou mais importante que a estratégia possa oferecer e a rapidez com que possa ser obtido. Entre os benefícios citados pelo Gartner estão: maior eficiência na execução dos processos de negócio; maior rapidez para chegar ao mercado/ciclos de projeto menores; estabelecimento de novos modelos de negócio de crescimento mais rápido; mudança da cultura de TI, de novos desenvolvimentos para reutilização; redução do custo total de desenvolvimento e manutenção das aplicações.

Related posts:

1. Referências para SOA [1]
2. Webinar: Maturidade e Roadmap SOA. Participe!
3. Grandes Volumes de Dados sem um Banco Relacional

No último post escrevi sobre o princípio que define que serviços abstraem a lógica, com um exemplo de uso.

Voltando a falar sobre os princípios básicos da arquitetura orientada a serviços, nesse post escreverei sobre o quinto item da nossa lista: os serviços são capazes de se compor. A cada princípio, eles se mostram cada vez mais complementares e, de certa forma, até mesmo intuitivos. Isso deve facilitar o entendimento dos conceitos aqui apresentados.

Serviços são Capazes de se Compor

5. Princípio: Serviços são capazes de se compor

• O que é:
  • A característica de os serviços capazes de se compor consiste em criar serviços que sejam capazes de se juntar e serem acessados de forma a englobar e atender um problema maior.
  • A composição dos serviços pode ser:
    • Primitiva - quando há apenas a troca de mensagens entre um conjunto de serviços;
    • Complexa - quando um conjunto de serviços oferece uma solução lógica sofisticada, ou seja, diversas trocas de mensagens entre um conjunto de serviços que são executados paralelamente.
• Aspectos positivos:
  • O princípio de dividir para conquistar é muito conhecido há anos e tem como principal objetivo simplificar os problemas encontrados no dia-a-dia. Com possibilidade de criar composições de serviços, eles tornam-se capazes de resolver grandes problemas com a complexidade de um simples serviço.
• Dificuldades:
  • A troca de mensagens entre os serviços pode torná-lo mais complexo e o princípio de baixo acoplamento não deve ser desrespeitado em detrimento disso. Os serviços devem comunicar-se para tornarem-se mais completos, e não interdependentes.
• Exemplo:
  • Situação inicial: É necessário serviços de validação dos dados de um cadastro de usuários em um sistema. Os dados a serem validados são o CPF, o cartão de crédito e o endereço.
    • No barramento de serviços A, é possível descobrir o serviço de validação dos dados.
    • No barramento de serviços B encontramos 3 serviços:
      • Validador de CPFs;
      • Validador de Cartões de Crédito;
      • Validador de Endereços.
  • No diagrama abaixo podemos ver como os serviços simples são capazes de se compor e resolver o problema mais complexo que é a validação de dados.
    • Cada seta ilustra a troca de mensagens entre os serviços. O serviço que valida os dados consulta cada validador individual e é responsável pela validação completa dos dados.
    • A troca de mensagens entre o serviço de validação de cartões de crédito e de validação de endereços é uma forma de aprimorar a simples validação do número do cartão junto à operadora de cartões de crédito.

Exemplo de composição de serviços

No próximo post falarei sobre o sexto princípio da nossa lista: os serviços devem ser autônomos.

Related posts:

1. SOA ajuda Cloud? Sim!
2. 40% dos usuários de SOA não medem o tempo necessário para ROI
3. Davi x Golias em SOA

As organizações devem ter expectativas realistas e identificar métricas de sucesso que estejam de acordo com a empresa para obter valor a partir da arquitetura orientada aos serviços (SOA), de acordo com o Gartner. Estudo global, realizado com 200 companhias no quarto trimestre de 2008, aponta que 40% dos usuários de SOA não medem o tempo necessário para o retorno dos investimentos e 50% dos entrevistados que não utilizam SOA não adotaram esses sistemas porque não conseguem articular e demonstrar o valor que ele tem para os negócios.

“A maioria das empresas que começa a utilizar SOA tem expectativas demais, como a obtenção imediata de ciclos de projetos mais rápidos, mas frequentemente os usuários não estão a par dos esforços, recursos e tempo necessários para conseguir tais benefícios”, afirma Massimo Pezzini, vice-presidente de pesquisas e pesquisador do Gartner.

Segundo ele, consequentemente, alguns projetos de SOA são considerados falhos, quando na verdade simplesmente não houve métricas bem estabelecidas para avaliar o sucesso. Para ter certeza de que as expectativas sejam realistas e que a empresa tomou medidas precisas com relação às suas metas, o Gartner recomenda que as organizações se concentrem em obter somente um benefício chave da lista de vantagens comerciais de SOA.

Segundo o instituto, a medida que os esforços com SOA ficarem amadurecidos, e os benefícios começarem a surgir, elas poderão acrescentar mais benefícios e mudar ou acrescentar novas medidas de acordo com a situação. A escolha dos benefícios depende de qual o valor comercial mais urgente ou mais importante que o benefício possa oferecer e a rapidez com que possa ser obtido.

Vi em: Sensedia radar

Related posts:

1. 40% dos usuários de SOA não medem o tempo necessário para ROI
2. SOA ajuda Cloud? Sim!
3. Webinar: Maturidade e Roadmap SOA. Participe!

Por Thomas Erl e Ricardo Barbosa.

SOA (arquitetura orientada a serviços) é caro, leva tempo e precisa envolver toda a empresa. Os mitos que se criaram em torno da arquitetura de serviços, sejam totalmente falsos ou não, afastam as empresas que poderiam obter resultados favoráveis e retorno no investimento em uma infraestrutura mais moderna.

O problema começa com a utilização de vários sistemas e diferentes tecnologias, seja por herança de gerações anteriores de TI ou impostos por fusões e aquisições. Mesmo onerosos para manter e evoluir, as empresas dedicam cada vez menos tempo para adaptá-los às crescentes demandas das áreas de negócios. Como resultado, acabam por produzir uma colcha de retalhos, além de centenas de integrações ponto a ponto.

O SOA e as inovações tecnológicas correlatas permitiram às áreas de TI desenvolver unidades de lógica (serviços) altamente flexíveis e interoperáveis. Assim, é possível se adaptar a mudanças de negócios de forma mais fácil e com menos custos.

O desafio está nas empresas compreenderem o que é SOA e como adotá-lo. Quando a área de TI desenvolve um sistema para atender a uma necessidade específica da área de negócios, ela o faz mais rápido e mais barato do que com a utilização de SOA e a área de negócios fica satisfeita. Porém, mais caro e mais demorado no início, o SOA trará em médio e longo prazo mais agilidade para a empresa. É quando os desenvolvimentos cedem lugar a simples e rápidas composições de serviços já existentes. 

Os modelos de business case e ROI usados para TI não conseguem captar esses benefícios. Eles vão acontecer nas áreas de negócios por meio da diminuição do time-to-market e aumento da lucratividade, o que nem sempre é simples de ser mensurado. Para piorar o quadro, muitas empresas dizem ter adotado SOA e na verdade apenas tentaram resolver problemas de integração de sistemas.Nesse caso, se trata de uma iniciativa isolada da área de TI que adquire uma série de tecnologias sem se preocupar em construir serviços segundo os princípios de design de serviços.

Outro mito é que para ter sucesso o SOA deve envolver toda a empresa. Falso. Serviços podem ser desenvolvidos e colocados em repositórios distintos (chamados de Inventários de Serviços) dentro da mesma empresa, permitindo que a empresa adote SOA de uma forma gradual. Assim, a empresa pode passar a identificar projetos e a produzir “pedaços” gerenciáveis. Essa abordagem está diretamente relacionada a um padrão de design recentemente publicado chamado Domain Inventory (para uma descrição, consulte www.soapatterns.org). 

O fato de poder adotar SOA de forma gradual deve servir de estímulo para que as empresas iniciem um projeto piloto que demonstre resultados palpáveis às áreas de negócio ao mesmo tempo conferindo à área de TI um entendimento sobre os diversos aspectos correlacionados (governança, infraestrutura, segurança, sistemas legados, etc.) resultando em experiência e confiança necessárias para estender SOA para o restante da empresa. 

Thomas Erl é autor de livros sobre SOA mais vendidos do mundo. Sua obra mais recente é SOA: Princípios de design de serviços, publicado pela Editora Pearson. Também é o fundador da SOA Systems Inc. Ricardo de Castro Barbosa é sócio da SOA-Savoir Faire Educação e Consultoria e é certificado como “SOA-Consultant” pela SOA Systems.

 

Li no baguete.

Related posts:

1. Webinar: Maturidade e Roadmap SOA. Participe!
2. Como aumentar as chances de sucesso na Nuvem
3. 40% dos usuários de SOA não medem o tempo necessário para ROI

soa e web services

Mais uma do Geek And Poke

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. Gartner Enterprise Technologies Summit 2010

Pessoal, segue um artigo enviado pelo Daniel Waldman.
O texto discute sobre o roadmap executado num projeto de implantação SOA, ilustrando algumas características importantes: Abordagem incremental, reúso de serviços, infra-estrutura mínima (repositório) e planejamento. 

CENÁRIOS E ETAPAS PARA IMPLANTAÇÃO SOA

No ano passado estive envolvido em um projeto com Workshops com grandes fornecedores de soluções SOA como a HP, a SUN, entre outros. Um dos objetivos desse projeto era aprofundar o conhecimento em SOA e perceber como funciona na prática o seu processo de implantação, através da apresentação de modelos de implantação, experiência dos consultores em grandes clientes e ainda cases de sucesso de grandes multinacionais. 

Segundo a revista Decision Report [1] uma boa implementação de SOA com boas práticas de governança pode trazer um excelente resultado para a organização. Se o projeto por implementado de uma forma eficiente o reuso em futuros sistemas pode chegar a 80% que é uma taxa muito elevada e com uma probabilidade muito pequena de acontecer comparada com uma arquitetura tradicional. Com essa taxa o custo de um projeto de desenvolvimento se torna muito menor e o retorno sobre o investimento é grande.

Ao final do projeto foi possível constatar que a implantação de um cenário SOA em uma grande organização não é uma tarefa fácil. É necessário um comprometimento dos funcionários da organização para o projeto poder ser executado com sucesso. Além disso, outra característica importante para o sucesso de uma implantação é a divisão por etapas para a implantação SOA. 

Um erro muito comum é organizações desejarem alterar todo seu cenário de softwares de uma só vez. Essa é uma estratégia que tem traz sérios problemas: é alterado de uma só vez o dia a dia dos funcionários que lidam com os sistemas. Outro fator importante é que normalmente quando se tenta fazer uma mudança brusca dessas não se consegue fazer uma boa migração, pois passam a existir muitos sistemas para se trabalhar e dessa forma não é possível concentrar os esforços em cada detalhe necessário. 

Pela experiência dos consultores pode-se perceber que projetos com elevado grau de sucesso são feitos em fases: primeiro se escolhe alguns sistemas, realiza-se a migração e observa o funcionamento para depois repetir o mesmo processo para outros sistemas até que se tenha realizado para toda a organização.

A figura 1 representa as etapas que segundo Gartner é o cenário ideal para uma organização de grande porte, com centenas de sistemas distribuídos, implantar um processo de SOA utilizando práticas de governança. A primeira etapa, que se for bem realizada pode durar em torno de 1 ano, é a que a organização começa a migrar alguns serviços para SOA. Nesse momento, conforme citado anteriormente, o importante não é se preocupar em implantar vários serviços, mas fazer alguns que possam já trazer o quanto antes algum beneficio. Com esses serviços implantados não é necessário ter um repositório final de serviços e as práticas de governança começam a ser definidas. O importante nesse período é testar o comportamento dos serviços, verem as políticas de governança que devem ser aplicadas e começar a trabalhar com as questões de repositório de serviços, controle de acessos, contratos de utilização, controle de consumidores entre outros.

Figura 1 - Adaptado de Gartner [2]

Além disso, outro fator importante é a escolha de sistemas simples, para serem utilizados nessa fase. Essa escolha é importante para que daqui a algum tempo quando surgir um projeto novo que utilize características dos projetos piloto já se possam constatar as vantagens que trouxeram a implantação do projeto piloto como, por exemplo, a reutilização de componentes e com isso aceleramento no tempo de desenvolvimento do novo projeto.

A etapa seguinte é a de um período muito grande, podendo levar até 4 anos, dependendo da infra-estrutura existente e da quantidade de sistemas que necessitam ser migrados. Essa etapa é muito importante, pois nessa fase que os outros serviços da organização começam a ser migrados. Essa é a fase chamada de cenário intermediário, pois até o seu final vai existir uma coexistência entre serviços com SOA e sistemas antigos. Durante esse processo as políticas de governança devem ser implantadas aos poucos conforme forem existindo as necessidades. Além disso, o repositório de serviços deve obrigatoriamente ser utilizado, pois é através dele que serão procurados os serviços que já estão implantados para poderem ser utilizados ou reaproveitados por outros serviços. Nesse ponto a organização começa a perceber um dos principais benefícios trazidos por SOA: o reaproveitamento de serviços. Com isso os novos projetos começam a se tornar mais rápidos, baratos e com menos problemas, pois quanto maior for o nível de reutilização, menor o desenvolvimento e assim chance de problemas. Ao final dessa etapa chega-se a um bom cenário organizacional: serviços estão implantados, existe reaproveitamento, controle do ambiente, registro de serviços e políticas de governança implantadas.

A última fase é o cenário estável para a organização. Os sistemas existem com conceitos de serviços, todos estão no repositório, não existem serviços duplicados e existe alta taxa de reuso. Todas as políticas de governança, processos de desenvolvimento de software foram implantados e estão estáveis. Nesse ponto, o importante é manter o ambiente para o futuro: novos serviços devem seguir o processo desenvolvimento e as políticas organizacionais, utilização de serviços deve ser feita via repositório com um contrato formal de prestação de serviços, entre outras.

Porém, esse modelo sugerido acima só se aplica a grandes organizações. Para empresas médias pode ser realizado um modelo alternativo. Ele deve ser feito considerando o número de sistemas existentes e de áreas da organização.  A figura 2 representa um modelo para implantação de SOA utilizando práticas de governança.

Figura 2 - Adaptado de Gartner [2]

Assim como no outro modelo proposto, o primeiro passo é a realização de um projeto piloto. No projeto piloto devem ser definidas as ferramentas que serão utilizadas no ambiente SOA. Além disso, devem ser escolhidos, da mesma maneira que no processo anterior, os sistemas pilotos. Ao final dessa etapa devem ser analisados os resultados do piloto para verificar se os resultados da ferramenta escolhida e dos sistemas pilotos foram satisfatórios. Caso não sejam, devem ser repetidos tantos pilotos quanto necessários até a organização estar confiante para avançar para a próxima fase.

Na segunda etapa, primeiramente deve ser feito a migração dos sistemas da área onde foi feito o piloto anteriormente. Durante esse trabalho as práticas de governança devem ser definidas conforme a necessidade da implantação. Ao final de todos os sistemas da área o processo deve ser repetido quantas vezes forem necessárias para cada área da empresa. O tempo dessa fase vai depender da quantidade de setores ou divisões dos sistemas da organização. Esse processo acaba quando todas as áreas da empresa forem migradas.

A última etapa, assim como no modelo anterior, é quando a organização já está com toda a política de governança definida e serviços implantados. O importante nesse momento é garantir que todos os colaboradores da organização sigam as políticas adotadas, como por exemplo, a verificação de serviços antes no repositório antes da criação de um novo, padrões de desenvolvimento, desenvolvimento orientado a serviços, entre outras práticas definidas.

Os modelos propostos nesse artigo são modelos indicados para o perfil das empresas. Porém, não pode se pode dizer com total confiança que este é o processo ideal para todas as organizações de mesmo porte sem que seja feita uma profunda análise do seu cenário e do seu contexto.

• [1] ZAIDAN, P. SOA atinge até 80% do reuso com governança, diz BearingPoint. [S.l.]:
  Disponível em: hwww.decisionreport.com.br. Acesso em: Março, 2009.
   
• [2] PEZZINI, M. Practitioner’s Guide: Best Practices in Enterpricewide SOA Initiatives.
  [S.l.]: Disponível em: http://www.gartner.com/. Acesso em: Outubro, 2008.

Related posts:

1. 40% dos usuários de SOA não medem o tempo necessário para ROI
2. Referências para SOA [1]
3. Davi x Golias em SOA

Related posts:

1. SOA ajuda Cloud? Sim!