Category Archives: Governance

Cloud Computing: Open-source Cloud e a Ajuda da Microsoft

Este post traz duas boas notícias para o mundo da “Cloud Computing”. A primeira é o anúncio da empresa de soluções SOA open-source, WSo2, já citada várias vezes neste blog, e a outra vem da Microsoft e de sua plataforma de Cloud, Azure.
wso2cloud

WSo2 Lança sua Plataforma de “Cloud Computing”

Para quem não conhece, a WSo2 é uma companhia que desenvolve soluções para a arquitetura orientada a serviços (SOA) no modelo open-source. Tem escritório no longíquo Sri Lanka (terra natal do seu fundador) e nos EUA e Europa.

A plataforma de “Cloud Computing” que eles lançaram permite que as empresas criem sua própria “nuvem”, as chamadas “Private Clouds“, com um custo (direto) de software bastante reduzido.

A solução de Governance as a Service é um dos serviços já disponíveis para serem utilizados (veja restrições abaixo).

wso2gaas A idéia é que sua empresa possa fazer o setup de uma solução de Governança para o ambiente SOA (SOA Governance Registry) diretamente na “nuvem” da WSo2.

Veja o que é possível implementar:

- Armazenar services, WSDLs, Schemas e policies, facilitando a descoberta (discovery) dos serviços e suas restrições

- Gerenciar o ciclo de vida dos serviços
- Manter múltiplas versões dos serviços

- Acompanhar as dependências e associações entre os WSDLs e os Schemas

- Dar permissões apropriada para os usuários

As restrições para utilização são:

  • até 5 usuários
  • não mais do que 100 recursos armazenados
  • não mais do que 100 recursos acessados / dia
  • cada recurso pode ter, no máximo, 1 MB

E estão preparando o lançamento do 2o. produto: “Indentity as a Service”!

Importante: como informou esta notícia da InformationWeek USA, o WSO2 suporta o uso de seu produto como uma “Amazon Machine Image“, o formato de máquina virtual do EC2/Amazon Cloud. É compatível também com “VMware ESX Server virtual machine” e, claro, no open source Linux KVM virtual machine.

A Cloud da Microsoft, Azure, agora pode rodar “Ruby on Rails”

azureinterop

A notícia vem do blog da Mary-Jo Foley. No final de Novembro (25/11/2009) o arquiteto da Microsoft, Simon Davies, anunciou que já tinha um exemplo do “Ruby on Rails” rodando em uma “nuvem” do Microsoft Azure (veja aqui “ao vivo”).

Em um movimento acertado, a Microsoft tem feito um esforço para que sua “nuvem” tenha compatibilidade com vários produtos e soluções open-source. Alguns exemplos de “Azure compatible” são:

  • Ruby
  • PHP e ferramentas baseada no Eclipse
  • MySQL
  • MediaWiki
  • MemCached
  • Tomcat
  • SugarCRM tem sua versão para o Azure (!)

e claro, o seu “Service Bus and Access Control services”, antes conhecido como “.NET Services”, agora roda diretamente no Windows Azure e é chamado agora de “Windows Azure platform AppFabric Service” (nome nada fácil…). Mais detalhes aqui e aqui.

Como na discussão levantada no post da Mary-Jo, não imagino que exista motiva de desconfiança por trás desta iniciativa da Microsoft em suportar soluções open-source em sua “nuvem”.

No meu ponto de vista, não importa para o usuário, e até mesmo para o desenvolvedor, em que “nuvem” sua sua aplicação baseada no “Ruby on Rails” ou seu open-source SugarCRM, está sendo executado.

O que você acha?

Carol, Yto e a Ontologia de SOA (parte I)

Carol é uma arquiteta de software, recém-casada, sem filhos, está prestes a receber seu 6o. certificado Java. Formada em análise de sistemas, é autodidata e adora música (não desgruda do seu iPod).

Yto é o gerente de desenvolvimento. Filho de japoneses, ele é casado, tem 1 filha, e está cursando uma pós-graduação em engenharia de software. Foi desenvolvedor por muito tempo e este é seu primeiro cargo como gerente.

carol&yto01 São 17:52 (veja o relógio) quando Yto chega próximo da mesa da Carol e pergunta:

[Yto] – Carol?

[Carol] – (ouvindo “Bangers and Mash”, do Radiohead, não ouve a pergunta)

[Yto] – (chegando mais perto) Carol, eu sei que já está tarde, mas preciso da sua ajuda para pensarmos sobre a Ontologia e a Taxonomia dos serviços que já construímos.

[Carol] – “Taxo” o que Yto? (ao mesmo tempo em que pensava, “O Yto não tem mesmo o que inventar, perguntar desta tal de ‘taxo-não sei-o-que’ quase 6 da noite…”)

Ontologia e Taxonomia

Os termos parecem difíceis para quem nunca ouviu falar mas o conceito é relativamente simples. Carol não precisa se preocupar mas, claro, às 06:00 PM não é a hora do Yto solicitar um planejamento de como classificar os serviços que eles já desenvolveram.

Quando se tem poucos Serviços – um número entre 20 e 100, então pode-se assumir que uma pessoa será envolvida no trabalho de entender e descrever a semântica deste Serviço.

Entretanto quando temos centenas de ou milhares de serviços, e estes estão sendo constantemente atualizados, é difícil ou mesmo impossível manter a semântica de cada um destes Serviços atualizado. Em algum momento se faz necessário uma representação formal, um padrão para representar a semântica destes Serviços.

soa-ontology(Evolução da Taxonomia para a Ontologia, SOASimples.com a partir de várias fontes)

Definições

Taxonomia são esquemas básicos, primários, de classificação através de hierarquia. A Taxonomia entretanto é uma estrutura muito simples para se utilizar em sistemas com muitas mudanças. Algumas vantagens:

  • Auxilia na definição de complexidade, melhorando estimativas de custo
  • Evita a quebra de uma regra básica de orientação a serviço que define que “serviços só podem utilizar outros serviços do mesmo nível (layer) ou de um nível inferior”
  • Suporta a linha de negócios (LoB) no entendimento do nível de reusabilidade quando surgem novos requisitos

Introduzir o conceitos de novos Serviços em uma ambiente de constante mudança (como o de uma operadora de telefonia) é uma das desvantagens desta classificação “horizontal”. Surgiu então necessidade de algo mais resiliente a mudanças, e a Ontologia tem esta característica importante.

Pode ser utilizada para capturar visões alternativas dentro de um arcabouço único, uma classificação “vertical”. Algumas vantagens:

  • Quando se desenha os serviços no contexto de “domínios” fica estabelecido uma linguagem comum entre TI e negócios
  • A visão de alto nível, simplifica o desenvolvimento de requisitos de negócio
  • Uma visão do todo (“big picture”) é compartilhada com todos facilitando a interoperabilidade dos novos serviços e evitando a duplicação de funcionalidades
  • Facilita a identificação de “quem” é o dono do novo serviço

Acompanhe aqui como a estória se desenrola. Abcs!

Governança de TI funciona?

Esta é a pergunta que Chris Curran faz neste post do seu excelente blog “CIO Dashboard“.

Ele argumenta, com razão, que uma das melhores métricas e indicadores de que a TI está sintonizada com o negócio é o baixo índice de falhas dos projetos que são liderados pela área de tecnologia. Parece óbvio, mas não é. No final do dia, o que interessa é o software funcionando de acordo com os requisitos acordados, correto? Simples assim.

Na vida real eu e você sabemos que não é tão simples, mas temos que concordar que isto é um fato: ou o nosso cliente tem a solução, ou não podemos considerar que o projeto foi um sucesso.

A pesquisa em questão verificou que menos da metade (45%) dos projetos foram entregues no prazo e que apenas 16% foram entregues com todas as funcionalidades (features) inicialmente acordadas.

Sem uma análise mais detalhada, poderíamos utilizar a famosa frase “…certamente, a falta de governança de TI é um motivos para esta taxa de insucesso….”.

Claro que Governança é muito importante mas nunca esqueçamos que, no final do dia, o que importa é que a solução seja entregue no prazo e com as funcionalidades desejadas. Divida o projeto em fases, negocie features desejáveis para versões posteriores, documente os requisitos e exponha a compreensão de TI de forma clara e objetiva para o cliente do projeto, obtenha apoio de um “patrocinador” (sponsor) etc. Tenha em mente que o objetivo é que o projeto tenha sucesso, e entregar no prazo é fundamental para este sucesso.

IT Projects Delivery

IT Projects Delivery

Category: Governance

SOA e ITIL (Parte II)

Na Parte I deste post tratamos do aspecto do como o ITIL pode auxiliar no controle da complexidade de ambientes heterogêneos (com ou sem SOA). Com SOA e também “Cloud Computing”, o conceito de “este-é-meu-servidor-e-meu-serviço-está-aqui” não faz mais sentido.

Você pode ter um Web Service sendo executado no ambiente da Amazon.com, o seu servidor de aplicação em um host em algum lugar do mundo, seu banco de dados no seu servidor dentro da sua empresa, seu ERP hospedado nas dependências do fornecedor etc etc.

O trabalho de Tony Baer, resumido neste artigo da Beth Gold-Bernstein/eBizQ, conclui que existe muita similaridade entre o ciclo de vida dos serviços em “ambiente” SOA e a abordagem ITIL do gerenciamento do ciclo de vida de serviços. Adicionalmente, a forma como as informações são trocadas entre diferentes grupos, em pontos específicos destes ciclos de vida, pode ajudar a integrar os famosos “silos” de informação.

Veja a imagem abaixo, do post da B.Bernstein:

Um ponto importante, citado dezenas de vezes neste blog, é que Governança em projetos que fazem uso da arquitetura SOA, deve ser uma preocupação desde o início. Se sua empresa já tem ou está implantando o ITIL, certamente, isto pode auxiliar. Um exemplo é a definição de papéis e responsabilidades que o ITIL propõe: governança SOA pode fazer usos destes processos.

De mais a mais, tudo que auxilie no controle de ativos de software, ajuda na Governança necessária para o sucesso de uma iniciativa SOA.

Category: Governance, SOA

Métricas em SOA: quais são importantes?

Neste artigo Mark Little, CTO da Red Hat discute um pouco sobre governança SOA e algumas métricas importantes neste mundo de arquitetura orientada a serviços.

Apesar de um pouco superficial (não apresenta qualquer fórmula ou exemplos práticos), o texto nos mostra quais indicadores importantes devemos colocar nosso foco. Abaixo a lista de Mark Little:

- Return on Investment (ROI) per service
Medir o ROI é complicado em qualquer cenário/arquitetura de software. Em SOA, mais complicado ainda. “Holísticamente”, como diz este artigo do Leo Shuster, estrategista SOA do National City Bank (EUA), o ROI do seu programa (conjunto de projetos) SOA pode ser calculado através da seguinte equação:

SOA ROI ($) = Cost Savings/Efficiencies Achieved – All SOA-Related Investments

or

SOA ROI (%) = SOA ROI ($) All SOA-Related Investment

Um dos “complicômetros” desta métrica é que alguns serviços são dependentes de outros para executar a regra de negócio à qual ele se propõe (objetivo). Assim, o ROI deste serviço deve ser medido ao longo de toda cadeia de dependência dos outros serviços/componentes. O autor lembra também que medir o ROI não significa necessáriamente que um serviço específico vai gerar receita.

- Revenue per service

Receita por serviço. Métrica diretamente relacionada com o ROI. A proposta é priorizar os serviços pelos retornos “teóricos” de investimento, classificando-os pela receita que eles produzirão.

- Service grow rate/reuse

Uma das grandes vantagens de SOA é o reuso de serviços. Pelo menos é isto que eu falo quando tento vender a idéia por trás da arquitetura. Na verdade, uma boa arquitetura, no mínimo, avalia esta possibilidade e projeto o serviço para que o mesmo seja reutilizado, gerando enormes economia de tempo/recurso e manutenção daquele código.

Este indicador é importante para definir o ROI e acompanhar o quanto um serviço vai ser/está sendo reutilizado força seu time a revisitar as implementações e avaliar a performance.

O que geralmente ocorre é que, mesmo que você tenha desenhado um serviço com a preocupação no reuso, dificilmente você sabe por quantos sistemas e sub-rotinas o mesmo está sendo invocado. No momento de stress com performance você tem esta informação na mão? I guess no.

- Business agility

Quanto tempo leva entre o planejamento do serviço e seu deployment? SOA traz agilidade, correto? Não foi isto que voê vendeu para seu cliente? Então, esta é uma métrica excelente para você exibir para seu patrocinador, mostrando que, de fato, o quanto esta nova forma de conceber soluções de software traz ganho para a empresa.

- Reliability

Métricas de confiabilidade (SLA) já utilizadas em outros ambientes (SOA ou não):

mean time to failure (MTTF) e

mean time to recovery (MTTR)

- Service inter-dependencies

Nada no mundo está isolado. Quanto um serviço depende de outro? A idéia é classificar e documentar o “nível” de interdependência dos serviços. Este serviço tem uma dependência “fraca” ou “forte” destes outros? Estes serviços com alta dependência podem ser classificados como uma única “unidade lógica”?

Como em muitos projetos que utilizam esta arquitetura, a idéia é começar a medir e extrair algumas métricas do seu ambiente. As coisas tendem a ficar um pouco mais complexas. Exemplo: Cloud Computing. Imaginar que parte destes serviços e infra-estrutura pode estar em qualquer lugar da “nuvem” é uma idéia que deve dar pesadelo em todo gestor de TI, mas já é uma realidade que não tem volta.

Melhor começarmos a medir este indicadores agora.

Mais sobre métricas de SOA nesta nota.

Google e Mag.nolia “down”?!

Entre Sexta (Jan, 30) e Sab (Jan, 31), dois grandes serviços ficaram indisponíveis.

O Google ficou fora do ar por cerca de 55 minutos no Sáb (31). Um erro de digitação (isso mesmo!), conduzia todas os links da pesquisa para um site de uma organização que ajuda o Google na classificação de sites “malware”: StopBadware.org. Detalhes aqui e aqui.

Um dia antes, Sex (30), foi a vez de um dos mais conhecidos sites de “bookmarks“: o Mag.nolia. Este último teve todos os dados corrompidos. Ainda estão tentando recuperar e, pior, até o momento ainda não tem previsão de retorno (já são 3 dias down!).

A discussão que julgo relevante são nossos planos de recuperação de desastres (DRP, Disaster Recovery Plan). Nenhuma, repito, nenhuma empresa está imune a uma situação como esta (vide o gigante Google).

Na “computação em nuvem”, em “ambientes” SOA é preciso uma atenção redobrada. Os serviços estão distribuídos e, para alguns deles, você não tem nenhuma gerência, são externos à seu ambiente. Como fica o serviço que você disponibiliza para seus clientes?

Se você já tem um DRP, hora de revisar. Se não tem, é bomo começar a pensar. 

Google and Mag.nolia logos

Google and Mag.nolia logos

Projetos orientados a SOA?

Na arquitetura orientada a serviços (SOA) encontramos muitas referências sobre desenvolvimento de software mas, e quanto a metodologia dos projetos de software baseados na arquitetura SOA, será que muda algo?O responsável pela estratégia SOA do National City Bank (USA), Leo Shuster, publicou este artigo (ou versão em PDF) na SOA Magazine de Agosto/2008.Projetos ainda são a forma mais efetiva de organizar as tarefas necessárias para entregar uma solução dentro das organizações. Como SOA traz uma mudança de paradigma no software e infraestrutura de TI, certamente os projetos são impactados.

  • Alguns projetos são suportados por linhas de negócios (Lines of Business ou LoB). Lembre-se que o paradgima de sistemas em “silos” não faz mais sentido em uma arquitetura corporativa (enterprise architecture). Desta forma, podemos ter um problema em que um projeto tem um funding de uma área mas vai alterar processos e resolver problemas de outros departamentos também. É justo atribuir 100% deste custo para o departmento solicitante?
  • Reuso. Aquele serviço que você implementou para o departamento financeiro consultar o rating de crédito dos seus clientes será reutilizado no processo de validação dos clientes de um novo produto produto da área comercial. Quem vai custear este reuso? Como calcular? Como dividir os custos?

Project-oriented SOA Governance ModelO autor propõe um modelo de governaça SOA para os “projetos orientados a SOA”. Veja imagem abaixo:

 (fonte: SOA Magazine)

Veja outras dicas sobre o funding dos projetos:

There are three possible ways to address the service funding concerns.

1. Make the first project to build a service provide the complete funding

2. Establish a central funding source that will cover all service design and construction expenses

3. Provide supplementary funding to projects building services

If option 1 is selected, several strategies for recouping the initial investment can be used.

a. Do not recoup the investment

b. Place a surcharge on each instance of service leverage

c. Charge a small fee for each service call 

 

Leitura mais do que recomendada para gerentes e líderes de projeto.

Implementações de SOA falham devido a Pessoas?!

Pouco falamos das falhas das implementações ou implantações dos nossos projetos e iniciativas. Acho que compartilhar estas informações pode ajudar outras pessoas e empresas a reduzir os riscos e, no mínimo, faze-las parar e pensar se estão mesmo no caminho certo. Com a arquitetura SOA não é diferente.

Muitas iniciativas falharam (e falham). É claro que as empresas e consultorias que “vendem” SOA não irão te contar nada a respeito disto e muito mesmo irão colocar em seus sites os “cases de falha de implementação SOA”, esqueça!.

E por que falham? Porque a tecnologia ou produto é ruim? Não necessariamente. Iniciativas de SOA, como qualquer outra, são conduzidas por pessoas. Parece óbvio (e é!). Logo, muitas vezes, a falha está em nós mesmos que lideramos e propomos esta nova abordagem orientada a serviço.

Isto é o que Mike Kavis escreve neste artigo para o site CIO.com. Resumo abaixo as 10 razões que ele destaca. O artigo vale a leitura porque o autor não se limite a apontar os erros; ele faz recomendações para cada umas das razões.

Iniciativas SOA falham porque as pessoas…

  1. não sabem explicar o valor de SOA para o negócio
  2. subestimam o impacto da mudança organizacional que SOA traz
  3. não garatem o patrocínio dos executivos ou alta gerência
  4. tentar implementar uma arquitetura SOA “baratinha”, apenas com base em produtos “free”, sem ajuda externa (nós sabemos tudo, certo?!)
  5. não investem em treinamento e pessoas com conhecimento suficiente e experiente para conduzir uma mudança de arquitetura
  6. não tem um gerenciamento de projetos eficiente. Empresas com forte cultura de gerenciamento de projetos tem 2 vezes mais chances de sucesso
  7. acham que SOA é um projeto e não uma arquitetura. Sem comentários!
  8. subestimam a complexidade que a arquitetura orientada a serviços traz
  9. não acreditam na importância da governança SOA
  10. deixam os fornecedores e consultores externos ditarem e “dirigirem” a arquitetura



Governança SOA Open-source?

A proposta vem da empresa MuleSource que recentemente anunciou a liberação do “Mule Galaxy Enterprise“. Este pode ser considerado a primeira plataforma open-source de governança SOA, com registry e repository integrados.

Acreditem, este é um mercado muito interessante. Segue minhas impressões:

  • O retorno de investimento em governança SOA é de difícil mensuração. De acordo com o Burton Group, apenas 20% das empresas conseguiram comprovar o retorno positivo.
  • São poucas empresas (realidadade do Brasil) que já necessitam de um ferramental para governança SOA
  • Já é difícil “vender” SOA, “Governança SOA” então. Segundo um estudo da AMR (USA!), em 2007, o custo médio de adoção da arquitetura SOA foi de US$ 1.4 milhões
  • Se o gestor de TI tiver que um orçamento bem limitado (quem não tem?), fatalmente ele irá priorizar as soluções de integração (broker) e/ou ferramentas de desenvolvimento para esta nova arquitetura. Governança? Bem, se sobrar algum dinheiro…
  • Governança está relacionado primeiramente com processo e controle. O software ajuda, principalmente, se você tem vários serviços que podem ser disponibilizados em várias versões, que são reutilizados largamente por toda organização (cuidado com a performance), se seu ambiente de desenvolvimento é descentralizado…
  • O custo de aquisição da maior parte das ferramentas ainda é muito alto (vide investimento médio na adoção de SOA)

Por estes e por outros motivos é que iniciativas como esta da MuleSource facilitam a vida dos gestores de TI, na medida em que temos ferramentas para testar e comprovar os benefícios da Governança SOA.

Segundo o post original o mercado deve investir US$ 50 bilhões em soluções SOA, ao mesmo tempo em que não vemos muitos dados (números!) dos benefícios equivalentes. É um desafio e tanto e eu acredito que isto é absolutamente normal no processo de adoção de SOA.

Category: Governance, open-source

Governança SOA: Erros Comuns e Soluções (parte III)

Na terceira (e última) parte desta série de posts sobre Governança SOA, gostaria de compartilhar um site com várias referências à este assunto: SOAGovSource.com.

É um sítio devotado ao assunto com muitas referência a outros artigo, estudos de caso, cases de sucesso, definições etc.

Leia com especial atenção algumas definições de Governança SOA (What is SOA?).

The Role of SOA Governance
“SOA governance is the set of solutions, policies and practices which enable companies to implement and manage an enterprise SOA.”
Samih Fadli, Satyam Computer Service

Gartner: SOA Governance Remains Crucial
“SOA governance is about having the discipline and making sure that the very important decisions go through to appropriate people and that these people have the appropriate input to make those decisions. That is half of the SOA governance problem. The second half is whenever there are decisions that are made, SOA governance needs to make sure that those decisions are actually followed. It’s not only about setting a speed limit, it is about enforcing it too and eventually giving people tickets or sending them to jail. That is what SOA governance really is about.”
Paolo Malinverno, Gartner

Category: Governance, SOA