Eu escrevi um artigo recentemente que foi publicado na ComputerWorld sobre como a Governança SOA pode ajudar as empresas na adoção de cloud computing, em especial, quando pensamos na utilização de serviços invocados diretamente da nuvem.

Abaixo o link original e o texto na íntegra.

Abraço,
Kleber

Link no site da Sensedia.

Como aumentar as chances de sucesso na nuvem – Por Kleber Bacili

Leia em Computer World
23/06/2010

Apesar de ter sido criado em 2006, em pouco tempo o conceito de cloud computing deixou de ser apenas uma tendência e se tornou um assunto bastante discutido e planejado pelas empresas de TI. Um levantamento feito pelo Gartner revelou que o modelo é prioridade para os CIOS brasileiros em 2010. Mas será que esses gestores conhecem os diversos contextos que podem ajudar suas empresas a se prepararem para cloud e estão atentos aos fatores que podem causar problemas para suas operações?

Cloud computing abrange uma série de conceitos como IaaS (Infrastructure as a Service), PaaS (Platform as a Service) e ainda o mais famoso de todos, SaaS (Software as a Service).

Durante uma palestra realizada na IV Conferência Anual de Tecnologias Empresariais, o analista e vice-presidente do Gartner, Daryl Plummer, afirmou que “apesar de estar fundamentada em conceitos já estabelecidos, a cloud computing ainda é, frequentemente, mal utilizada pelos gestores” e apontou governança SOA como uma importante ferramenta na obtenção de sucesso com a adoção de cloud computing.

Mas de que maneira governança SOA pode impulsionar a  maturidade de uma empresa para sua aplicação de cloud e de que forma ela aumenta as chances da empresa ter sucesso na adoção do conceito?
Cada vez mais serviços são disponibilizados na web e é cada vez mais comum as empresas adotarem soluções de negócio, como CRM e ERP, disponibilizadas na cloud no formato de SaaS. Com isso, cresce a necessidade de integração entre aplicações sendo usadas na nuvem com as aplicações internas.

Cresce, também, a dependência entre os processos de negócio da empresa e serviços utilizados a partir da nuvem. E, consequentemente, a falta de conhecimento das dependências entre aplicações, processos de negócio e serviços – internos ou na cloud – pode levar a interrupção dos negócios caso algum elemento crítico dessa malha de dependências pare de funcionar. É nesse cenário que as áreas de TI e negócios sentem a necessidade por Governança.

O primeiro passo é entender que Governança SOA está profundamente ligada com visibilidade e controle de responsabilidades. Conseguir saber quais aplicações existem, quais serviços são expostos e consumidos por quais aplicações e processos de negócio, ter informações ainda sobre componentes e rotinas reutilizáveis e sobre as integrações nos mais variados formatos usados pela empresa são preocupações constantes da Governança SOA.

Aliado a esse quesito de visibilidade, há o conceito de controle de responsabilidades, onde cada papel relacionado a criação e evolução dos itens listados acima precisa estar mapeado e atribuído a pessoas reais na empresas. É claro que existem vários níveis de maturidade diferentes e o desafio das empresas está em descobrir esse nível e definir seu processo de governança SOA com o “tamanho e peso” corretos.

Mas voltando a cloud, vamos a um exemplo para ilustrar o conceito da governança SOA aplicada a computação em nuvem: imagine o processo de negócio de cotação de seguro de carro. É normal que a precificação leve em consideração informações como: (i) o nível de criminalidade em determinadas regiões; (ii) histórico de pagamentos do proponente no mercado; (iii) informação sobre sinistros anteriores.  O(s) sistema(s) que suporta(m) esse processo de negócio pode ter, então, dependências de um serviço provido pelo IBGE (i); outro pela Serasa/Experian (ii) e um terceiro pela FENASEG (iii). E, caso algum desses provedores tenham problemas em seus serviços o processo de negócio de cotação, chave para a seguradora, pode parar de funcionar.

Todas as dependências entre os elementos mencionados nesse exemplo podem ser entendidas como invocações de serviços que caracterizam a abordagem SOA só que aplicadas ao novo conceito de cloud. Se a empresa determinar os responsáveis pelos diferentes tipos de elementos envolvidos numa solução e estabelecer processos e um ciclo de vida para controlar sua criação e evolução, a chance de sucesso, tanto em SOA quanto em cloud, especialmente SaaS, aumenta sensivelmente.

Com base nessas informações, é possível dizer que a Governança SOA permite que as empresas conheçam as dependências que seus negócios possuem de elementos externos, e, por isso, aquelas que investirem em governança antes de migrarem seus serviços para a nuvem estarão mais bem preparadas e com maiores chances de sucesso.

Related posts:

1. SoundCloud – Música nas nuvens
2. SOA ajuda Cloud? Sim!
3. Davi x Golias em SOA

frequentemente os leitores perguntam por livros de referência para SOA. Vou tentar centralizar alguns neste tópico, e ir atualizando de acordo com as sugestões de vocês. Podem usar os comentários, com novas sugestões ou feedbacks do material listado.

Em uma procura rápida pelo blog, já comecei a lista. Segue abaixo:

Livros:

• SOA Design Patterns
  by Thomas Erl

• SOA Principles of Service Design
  by Thomas Erl

• Web Services – Concepts, Architectures and Applications
  Autor: Alonso, Casati, Kuno, Machiraju

• SOA na Prática – Inovando seu negócio por meio de soluções orientadas a serviços
  Autor: Fabio Perez Marzullo
  Editora: Novatec
  Ano: 2009
  ISBN: 978-85-7522-201-0

• SOA na Prática – A arte da modelagem de sistemas distribuidos
  Autor: Nicolai M. Josuttis
  Editora: Alta Books
  Ano: 2008
  ISBN: 978-85-7608-184-5

• SOA – Principles of service design
  Autor: Thomas Erl
  Editora: Prentice Hall
  Ano: 2008
  ISBN: 978-01-3234-482-1

Revistas/periódicos que possuem colunas a respeito (algumas mais técnicas).

• TI inside [link]
• Mundo Java [link]

Related posts:

1. 40% dos usuários de SOA não medem o tempo necessário para ROI
2. SOA Manifesto
3. Como aumentar as chances de sucesso na Nuvem

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

Se em tempos normais já é assim, imagine com a crise econômica: as empresas se sentem ainda mais pressionadas a reduzir custos e aumentar a agilidade. E a Arquitetura Orientada a Serviços (SOA) é uma proposta concreta para superar esses desafios.

No entanto, nós, profissionais de tecnologia, não estamos acostumados a vender essa idéia dentro de nossas empresas, principalmente devido ao fato dos benefícios esperados em SOA serem um tanto quanto intangíveis. Inclusive, um estudo do Gartner feito com 200 companhias no final de 2008 mostra justamente isso: 40% dos usuário SOA não medem o tempo necessário para o retorno dos investimentos. Na outra ponta, 50% dos entrevistados que não utilizavam SOA declararam que não o faziam pela dificuldade em demonstrar o valor que essa solução tem para o negócio.
Portanto, é preciso estar atento. Em momentos de crise, somente os projetos

que conseguem mostrar uma relação custo/benefício adequada e com a dose correta de risco avançam. Para provar sua “tese” sobre SOA, existe uma série de cálculos e argumentações, que vão do ROI de serviço até a palavrinha mágica “Lightweight” (leve, iterativa e ágil) – SOA não precisa ter um investimento alto no primeiro momento. E é muito importante elaborar um Business Case e mostrar de forma estruturada as dificuldades atuais, a proposta de projeto com os resultados esperados e também os investimentos e o plano de implementação para se atingir esses resultados.

ESTRUTURAR A ADOÇÃO DE SOA: BUSINESS CASE
A primeira etapa de um Business Case deve ser identificar os problemas atuais, ou seja, o que está motivando a proposição do projeto. Tipicamente, os problemas mais comuns são:

• Falta de alinhamento entre as demandas das áreas de negócio e a agenda de TI
• Falta de agilidade na evolução das aplicações existentes, bem como na entrega de novas
• Dificuldade na integração dos processos
• Qualidade das soluções finais

No entanto, esses sintomas são bastante genéricos. É fundamental que você seja capaz de determinar exemplos concretos, do dia-a-dia, que mostrem como esses pontos impactam os resultados de TI.

A próxima etapa é apresentar uma visão geral das fases do projeto:

ROI em SOA (fases)

Fases curtas (3 meses para cada uma é o máximo), com resultados concretos a cada passo. A imagem é um exemplo. O ponto mais importante é conseguir definir claramente os entregáveis e, fundamentalmente, que esses entregáveis tragam valor imediato para a empresa.

GERAÇÃO DE VALOR E BENEFÍCIOS
Vamos entrar na discussão sobre geração de valor para a empresa. Quando pensamos em um Business Case para SOA, temos que considerar os principais benefícios prometidos, como quantificá-los e como eles se distribuirão ao longo do tempo.

A lista dos benefícios:

• Redução do desenvolvimento duplicado
• Simplificação da integração entre aplicações
• Aumento da qualidade das funcionalidades
• Redução do custo de manutenção das aplicações
• Flexibilidade na alteração de processos de negócio
• Agilidade na análise de impacto
• Conhecimento dos ativos existentes

Algumas métricas para usarmos no cálculo da economia podem ser:

• Reuse Cost Avoidance: trata-se do quanto a empresa economiza por não ter que desenvolver novamente as mesmas funcionalidades. Digamos que para construir um determinado serviço foram necessárias 100 horas. Cada vez que se reutilizar esse serviço, praticamente 100 horas – ou pelo menos uma parte delas – serão economizadas.
• Consistency: a mesma lógica de negócio desenvolvida várias vezes pode causar comportamentos diferentes dependendo da aplicação e, sempre que muda, é necessário mudar em todos os locais onde esteja implementada.
• Maintenability: uma parte significativa do orçamento de TI é gasta apenas mantendo as aplicações existentes funcionando. Redução nos custos de manutenção com integrações mais fáceis de manter e componentes isolados sendo reutilizados, e com nível de qualidade já atestada, impactam de forma muito positiva o uso racional dos recursos de TI.
• Agility: Conseguir fazer a análise de impacto mais rapidamente e promover mudanças nas aplicações e processos de negócios no tempo demandado pelas áreas de negócio é uma argumentação muito efetiva quando relacionado ao business case de SOA.

O desafio é conseguir quantificar os elementos acima de forma a contrapor os investimentos necessários.

INVESTIMENTOS
Além de quantificar os benefícios, será necessário também quantificar os investimentos necessários para atingir os resultados propostos. Abaixo está uma lista de itens que não podem deixar de ser considerados:

• Capacitação: custo para contratação de treinamentos e o tempo dos times de desenvolvimento e arquitetura para participarem dos treinamentos;
• Elementos de infraestrutura: repositório de serviços, barramentos de integração, monitoração dos serviços. Mas lembrem-se, com o que a empresa já tem de ferramentas é possível andar sem fazer investimentos que inviabilizem a iniciativa. Importante: considere também os custos de renovação das licenças nos anos seguintes.
• Apoio de consultoria externa: aprender com os próprios erros é uma virtude. Com os erros dos outros é muito inteligente. Vemos que o papel da consultoria, além da experiência, é trazer ritmo e compromisso com os resultados.
• Tempo e foco do time que estará envolvido: identificar serviços existentes, criar padrões, fazer uma modelagem mais refinada, definir responsabilidades e todas as demais atividades dependem do envolvimento e patrocício executivo e foco do time.

Para finalizar, é importante consolidar o material e conseguir atençãoexecutiva. Lembrando: abordagem Lightweight: ágil, leve e incremental. Boa venda!

Related posts:

1. SOA ajuda Cloud? Sim!

A zapthink acabou de publicar um artigo muito legal a respeito de implantação light de SOA. Um modelo de implantação incremental, focado em ROI de curto prazo, em resposta principalmente para o cenário econômico atual.

Artigo escrito por Jason Bloomberg, um dos principais analistas do mercado. (Download aqui!)

O artigo traz uma série de informações relevantes de mercado e ferramentas, e apresenta também uma visão macro de abordagem para implantação de SOA em um modelo leve, com menores riscos e resultados em curto prazo.

LEITURA OBRIGATÓRIA!!

Lightweight SOA

Download do artigo: aqui!

Alguns trechos do paper:

- “SOA is not particularly risky.”

- “It’s finally time to dispel the myth that SOA success requires a large initial investment and a long-term effort to achieve significant business results.”

- “When times are tough, it is imperative that businesses rethink the way they are doing business.”

- “In lightweight SOA projects, architecture, business processes, and governance drive SOA infrastructure and tooling choices.”

Abraços,
Marcílio

Related posts:

1. Davi x Golias em SOA
2. Webinar: Maturidade e Roadmap SOA. Participe!
3. Como aumentar as chances de sucesso na Nuvem

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

“Cloud computing requer uma infraestrutura de computação dinâmica, mas existem também outros pilares.” ( Dave Malcolm)

Artigo interessantes. Resumidamente, cinco pilares:

• Infraestrutura de Computação Dinâmica
• Abordagem Centralizada em Serviços de TI
• Modelo de Uso Baseado em Auto-Serviço 
• Plataforma Minimamente ou Auto-Gerenciada
• Faturamento Baseado em Consumo

Leitura rápida e recomendada. Veja aqui.

[]s

Related posts:

1. SOA ajuda Cloud? Sim!
2. Como aumentar as chances de sucesso na Nuvem
3. Davi x Golias em SOA

=====================

Há consenso no mercado e nas corporações que poucas ações podem trazer melhorias tão significativas no desenvolvimento de software quanto a possibilidade de reaproveitar e capitalizar o que já foi construído, testado e validado, permitindo que soluções existentes sejam implementadas rapidamente em novos contextos. Essa é a idéia do asset reuse, ou reúso de ativos. Com ele, migra-se do modelo do software artesanal para uma indústria de software mais madura, capaz de “montar peças” para compor novos sistemas.

Isso torna o processo de engenharia de software mais eficiente em termos de custo, produtividade e qualidade, e mais apto a responder com agilidade às mudanças nos processos de negócio.

Por essa razão, o desenvolvimento de software baseado em componentes vem se firmando cada vez mais como uma proposta concreta para a melhoria da produção de software, cujo processo passa a ter foco em:

• Criação de ativos — sejam eles componentes (blocos de software com funcionalidades) ou serviços (funções de um sistema que são disponibilizadas na rede através de uma interface), base do modelo SOA — Service Oriented Architecture;

• Reúso de ativos — sejam eles parte do próprio capital intelectual da corporação, provenientes de comunidades de software livre ou comprados de terceiros.

Os benefícios dessa abordagem são obtidos através da definição de uma estratégia corporativa de reúso, representada por mudanças em termos de negócio, processos, pessoas e ferramentas. Com isso, tem-se o necessário para a implementação, monitoração, governança e capitalização das ações. Pesquisas elaboradas por Ivar Jacobson e Jeffrey Poulin (referências mundiais em engenharia de software e reúso de ativos) apontam melhorias em produtividade da ordem de 100 a 400% e redução de defeitos e custos de manutenção de 80 a 90% para corporações que adotam reúso sistemático de ativos.

imagem-minipaper1

Na prática, a implementação dessa estratégia deve seguir uma trajetória caracterizada por um novo direcionamento executivo, no qual o investimento inicial é necessário e a governança passa a ser fator de sucesso ou fracasso. O retorno do investimento (ROI) tipicamente é obtido de médio a longo prazo, uma vez que os desafios da estratégia sejam superados. Porém, existem fatores comuns apresentados por corporações que tiveram êxito na implementação da estratégia de reúso.

O primeiro é a mudança no processo de engenharia de software, com a formalização de todos os pontos do ciclo de desenvolvimento nos quais a componentização pode ser considerada. É importante pensar em reúso desde o início, quebrando a solução em pacotes menores. O refinamento ocorrerá em etapas posteriores, contribuindo para a biblioteca de ativos. É necessária também uma arquitetura corporativa de referência, garantindo produtividade e uniformidade técnica ao portfolio de projetos da corporação.

Para um fornecedor de TI, outro fator é a criação de um modelo de licenciamento, no qual os ativos são precificados e vendidos como parte da solução, reforçando ao cliente o potencial de diminuição do preço final. O cliente, ao adquirir soluções compostas por ativos reutilizáveis, cria uma biblioteca que facilita a construção de novos sistemas.

Por fim, tem-se a necessidade de investimento (ou uso da receita com licenciamento) em uma unidade de negócios focada no gerenciamento dos ativos, ou seja, criação, manutenção, controle de versões, divulgação e mecanismos de incentivos. Essa unidade deve ter foco em governança e integração dos processos, apresentando métricas e visões gerenciais que possibilitem o acompanhamento dos seus benefícios, como ROI, economia de cada reutilização, ativos mais solicitados, entre outros.

Nesse mundo de reúso de ativos, SOA e engenharia de software madura, as corporações precisam assumir efetivamente o modelo de colaboração, compartilhando e reutilizando soluções, unificando esforços e boas práticas. Todos têm a ganhar ao não reinventar a roda.

Para saber mais

http://en.wikipedia.org/wiki/Code_reuse
http://www.redbooks.ibm.com/redbooks/pdfs/sg247529.pdf
http://books.google.com/books?id=wrFQAAAAMAAJ&pgis=1

Related posts:

1. Davi x Golias em SOA
2. Como aumentar as chances de sucesso na Nuvem
3. Empresa aposta em Qualidade Arquitetural e Orientação a serviços…

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. Davi x Golias em SOA
3. Webinar: Maturidade e Roadmap SOA. Participe!

****************************************************************

Com crise, organizações adiam investimentos em SOA

A adoção da arquitetura orientada aos serviços perde velocidade rapidamente, segundo pesquisa do Gartner

Infoworld, EUA

Publicada em 04 de novembro de 2008 às 17h29

O número de organizações planejando adotar SOA caiu para 25% na pesquisa do Gartner sobre o tema em 2008. Para se ter uma idéia, esse número foi de 53% na pesquisa do ano passado.

Cresceu o número de organizações que não pensam em adotar SOA. De 7% em 2007 para 16% em 2008. A dramática queda de interesse em SOA, relata o Gartner, está acontecendo desde o início de 2008.

O instituto faz essa pesquisa há cinco anos e essa foi a primeira vez em que registrou queda nos números, disse Dan Sholler, vice-presidente de pesquisas no Gartner. “Estamos vendo organizações que, por várias razões, não pretendem fazer nada específico para SOA,” disse.

No geral, as organizações planejam menos projetos em 2009 e SOA também foi atingido.

O Gartner apontou uma mudança no que as empresas pensam sobre SOA. Se antes o conceito era visto como uma modificação inevitável para as corporações, a idéia está mudando. As empresas avaliam SOA e decidem não gastar tempo ou dinheiro nele.

O Gartner ouviu mais de 200 empresas durante os meses de maio e julho de 2008. Outras três pesquisas subseqüentes foram realizadas pelo instituto em conferências realizadas em várias partes do mundo, com 119 entrevistados.

Related posts:

1. Gartner Enterprise Technologies Summit 2010
2. 40% dos usuários de SOA não medem o tempo necessário para ROI
3. Como aumentar as chances de sucesso na Nuvem