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!

E através da experiência com projetos de implantação, percebemos que a existência destes grupos é vital para a absorção e disseminação para as equipes de desenvolvimento internas da empresa (uma vez que a implantação inicial não envolve toda a fábrica).

Embora seja responsável por garantir a governança SOA sob uma visão corporativa, o Núcleo SOA deve existir já na fase de implantação, pois ele será o responsável por dar a “cara” da empresa na arquitetura definida.

Recentemente o Forrester publicou um relatório listando os benefícios da crianção do Núcleo SOA. Segue trechos de uma matéria a respeito:

Equipe focada em Arquitetura Orientada a Serviços tem como principais funções a garantia da governança e o alinhamento dos projetos.
24 de setembro de 2009

(…) No relatório da Forrester, quando questionados sobre as funções mais valiosas do centro de excelência de SOA, os entrevistados apontaram os cinco principais benefícios:

• Criar e manter a visão e os planos (do projeto SOA)
• Agir para a aprovação de regras que façam parte das políticas de governança de SOA
• Gerenciar os padrões para a implementação da arquitetura
• Gerenciar o portfólio e os documentos relativos aos serviços – baseados na nova arquitetura
• Planejar o futuro das tecnologias que suportam a arquitetura

Entre as conclusões de Heffner em relação ao levantamento, o especialista aponta também que os benefícios citados pelos executivos já são suficientes para mostrar que a criação de um centro de serviços durante a implementação de um projeto de SOA é muito mais eficiente do que simplesmente investir em capacitação das equipes de TI para adequar-se aos padrões exigidos por essa arquitetura.

Li em computerword.

Para mim, o recado é: A criação do núcleo é vital para uma implantação alinhada às necessidades da empresa e para a garantia que passaremos do projeto piloto para a visão corporativa de maneira menos traumática.

abraços,
Marcílio

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

Vejam:

• Mundo Java - Gartner lança Quadrante Mágico em Governança SOA e destaca Sensedia como visionária
• Executivos Financeiros - Sensedia é posicionada como visionária no Quadrante Mágico de Governança SOA do Gartner
• Baguete - Sensedia, 1ª brasileira no Quadrante de SOA

Related posts:

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

Recentemente foi publicado um case SOA (Success with SOA: A Cisco case study) com muita relevância, principalmente pelo trabalho envolver um roadmap bastante maduro e preocupações com as questões que, na minha opinião, são cruciais.
Li a notícia na infoQ (Estudo de caso: Sucesso com SOA na CISCO), e de lá retirei um texto para discutirmos aqui.

Segue abaixo alguns trechos do texto e algumas considerações pessoais:

“Harvinder Kalsi é arquiteto líder do domínio SOA/BPM na Cisco, apresentou um estudo de caso em dezembro no SOA Consortium meeting em Santa Clara.

Na sua opinião, nós estamos em um momento crucial para SOA. Ele argumenta que a partir de 2008, o padrão e as tecnologias estarão bastante maduras enquanto o interesse dos negócios está crescendo. Neste estudo de caso o negócio foi o principal driver por trás do desenvolvimento SOA.

Eles estabeleceram suas estretégias SOA utilizando quatro passos para o processo de maturidade:

1. Serviço permite sistemas legados criar uma camada de serviço de negócios
2. Atingir a excelência dos processos de negócio
3. Dar visibilidade ao negócio
4. Eles vêem vários benefícios gerados pela abordagem SOA:

• Reusabilidade
• Agilidade
• Impacto mínimo para mudança

Finalmente, na sua opinião SOA permite pegar a funcionalidade que a Cisco tem internamente e a oferecer ao seu ecosistema de parceiros, ampliando os benefícios para toda a cadeia de estoque.”

Ou seja, conhecemos os benefícios e muitas empresas investiram em maturidade. Agora é o momento das empresas (e não os fornecedores) obterem seus benefícios! Pensei que só eu acreditava nisso, mas vejo que não estamos sozinhos!

Em seguida, são descritas algumas capacidades desenvolvidas na Cisco, durante o projeto. Vou repetir apenas as três que considero totalmente indispensáveis (Padrões de desenvolvimento, Repositório ou Registro de serviços e Governança):

“Mais adiante, Harvinder descreve nos mínimos detalhes as capacidades que a Cisco desenvolveu como parte de sua iniciativa SOA. Muitos destes elementos tem sido desenvolvidos em 2007 e em 2008:

Framework de Desenvolvimento de Serviço

• Este é ambiente de desenvolvimento de serviço padronizado
• Eles tiveram uma redução de 20-30% no desenvolvimento de serviço
• Este foi o elemento chave do seu framework de Operações & Gerenciamento
• Suporta Web 2.0 (JSon, REST)

Registro SOA

• Um stop shop para publicação, descoberta e contratação dos serviços
• Repositório master para todos os serviços dentro da Cisco
• Chave para permitir governança SOA
• UDDI v2
• Integrado com outros componentes da Plataforma SOA
• SOA Gateway

SOA Governança

• Políticas & padrões técnicos
• Templates para definição de serviço
• Processos”

Fico particularmente satisfeito ao encontrar casos de sucesso SOA, principalmente quando percebemos que (quem sabe por coincidência ) eles só acontecem  com planejamento, governança e padrões! Implementar projetos com um monte de serviços não garante que a artquitetura e o negócio sejam “orientados a serviço”… certamente, neste caso, SOA não apenas morre, como mata o projeto.

Como o próprio Harvinder concluiu: “São Pessoas, processos e tecnologias que fazem SOA ser bem sucedido”

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. Webinar: Maturidade e Roadmap SOA. Participe!
3. Gartner Enterprise Technologies Summit 2010

Fui convidado para fazer uma apresentação no primeiro dia. O tema será: “Governança de serviços e qualidade arquitetural em SOA”. Discutiremos sobre controle de qualidade de mecanismos arquiteturais e gestão de serviços. A idéia é ressaltar os cuidados essenciais com qualidade em uma Arquitetura Orientada a Serviço, e traçar um paralelo entre Qualidade x Reúso x Governança SOA, com conceitos, alguns exemplos práticos de cases e ferramentas.

Mais detalhes, alguns links abaixo:

• Programação (lista de palestras e empresas)
• Site da ASR Consultoria
• Blog do Robson

[]s
Marcílio

Related posts:

1. Empresa aposta em Qualidade Arquitetural e Orientação a serviços…
2. Webinar: Maturidade e Roadmap SOA. Participe!
3. SOA ajuda Cloud? Sim!

Bom, para pensar em situações aplicadas, vamos falar rapidamente sobre integração. A necessidade de usar SOA para facilitar a integração de sistemas tem se destacado e usa bastante estes conceitos (based e enabled), facilitando a vida de fornecedores e evoluindo a forma das aplicações conversarem.

Sempre que visitamos uma empresa que trabalha com linha de produtos, vejo que um dos nortes das preocupações é evoluir a maturidade de integração com outros produtos e pacotes! A necessidade de integração existe não é de hoje, a diferença é que não estamos mais querendo disponibilizar “aquela view no oracle” para que um sistema converse com o outro. Alguns clientes apresentam, inclusive, restrições técnicas para estas conversas através de Banco de Dados.

Fornecedores vêm se movendo, criando camadas e mais camadas nos seus produtos, para que a integração seja através de serviços. Não é viável reimplementar o produto, não agora! Então, o que eu estou fazendo? Gambiarra ou SOA? Para que especialistas possam responder esta questão sem se comprometer , surgiu até o conceito de SOA Enabled e SOA Based!

• SOA Enabled: O núcleo da aplicação é o mesmo, mas inserimos uma ou duas camadas de abstração, para publicar algumas funcionalidades como serviços. Muitas vezes, os problemas arquiteturais persistem! Mas, agora a integração é mais bonita e posso falar que disponibilizo serviços. Ok, tudo bem que os serviços surgem por demanda (feio né?!), mas tenho visto esta abordagem ser positivamente aplicada em diferentes empresas. É importante usar um processo de reengenharia e identificação de serviços legados, sendo possivel descobrir e criar serviços totalmente alinhados às necessidades de negócio, mesmo tendo que abrir mão de algumas características técnicas que vão continuar rodando por baixo dos panos.
• SOA Based: A aplicação é feita tendo a Arquitetura “Orientada a Serviços” (bingo!). Ou seja, os serviços não vão surgir depois, eles são identificados no início do projeto, através de um processo de identificação de serviços que orienta o design arquitetural. Show de bola! Mas, é necessário que seja uma nova aplicação ou um refactoring arquitetural (talvez até traumático) para conseguirmos aplicar SOA Based efetivamente. Uma grande vantagem é que, descobrindo os serviços logo no início do projeto, potencializamos o poder de reúso sem precisar criar serviços genéricos e a arquitetura é voltada para estes serviços identificados.

Três considerações antes da conclusão:

1. Primeiro: Bom mesmo seria se só existisse SOA Based.
2. Segundo: SOA enabled não é, obrigatoriamente, uma má prática! Mas a Arquitetura não foi Orientada a Serviços.
3. Terceiro: O que as duas abordagens têm em comum? Para ambas, é necessário estabelecer um processo de identificação de serviços! Que esteja alinhado às demandas de negócio. E o processo vai rodar para criar uma nova aplicação, ou para descobrir serviços em produtos existentes. A abordagem deve ser top-down! Não estarei apenas “disponibilizando alguns web services”, o que é bastante comum.

Enfim, para SOA based e SOA enabled, o mais importante é que surjam serviços de negócio disponibilizados no produto, que possam ser evoluídos, integrados, reutilizados, rastreados e, inclusive, governandos e monitorados em runtime.

Ou seja, não esqueçamos da governança dos serviços. Para garantir diversas diretrizes SOA, como desacoplamento, seria necessário sujar as mãos. Mas cá entre nós, mesmo sem isso, os benefícios de utilização de serviços de negócio para tornar meu produto SOA Enabled são reais.

[]s
Marcilio

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. Webinar: Maturidade e Roadmap SOA. Participe!
3. SOA ajuda Cloud? Sim!

Ser referência em um esporte é ser perseguido por todos que querem no mínimo superá-lo. É a tal da referência. Um padrão a ser seguido que “pode” levá-lo ao sucesso. Óbvio que o talento faz toda a diferença e eu acredito muito nas pessoas.

Mas falando em referência, você possui referências para o seu projeto SOA? Ou sendo mais específico, você tem uma arquitetura de referência na sua empresa para estes projetos?

Aplicações SOA possuem um grau maior de complexidade em relação as aplicações tradicionais, visto que alguns níveis de abstração são adicionados. Uma maneira comprovadamente eficaz de vencer este desafio é elaborar e manter uma Arquitetura de Referência forte e versátil.

Meu amigo Airton Lastori no seu trabalho de pós-graduação diz que: “Uma Arquitetura de Referência consiste no conjunto de informações acessíveis a toda equipe de desenvolvimento e que provêem um conjunto consistente de boas práticas. Seu corpo pode conter informações vindas de diversas fontes: artefatos de projetos anteriores, princípios, metodologias, modelos conceituais, tecnologias, padrões de mercado, além dos próprios padrões corporativos. Portanto, a sua missão é prover um repositório de boas práticas arquiteturais que podem ser reusadas horizontalmente pela empresa, ao longo de todo ciclo de vida dos seus projetos de software, minimizando riscos e retrabalho.”

Eu concordo, e resumiria a arquitetura de referência como sendo:

• Apenas um conjunto de decisões técnicas!
• Decisões que afetam a qualidade do sistema inteiro: camadas, componentes e tecnologias, padrões, guias, nomeclaturas e patterns.

 

Mas também, uma Arquitetura de Referência:

• Aumenta a produtividade das equipes de projeto.
• Poupa tempo, pois fornece um ponto de partida.
• Norteia as preocupações do arquiteto.
• Provê um marco zero a partir do qual pode-se fazer medidas.
• Conhecendo uma arquitetura, é fácil familiarizar-se com outro projeto na mesma arquitetura.
• Quanto mais pessoas conhecem uma tecnologia, mais fácil é obter ajuda.

 

A figura abaixo é a representação dos itens que compõem uma arquitetura de referência, seja como produto gerado ou como inspiração para a sua elaboração.

arq_ref1

Arquitetura de Referência

Cada corporação deve ter a sua arquitetura de referência. Não acredito em Arquiteturas de Referência vendidas como um pacote. Será que existe uma Isinbayeva sendo vendida como pacote para ser campeã olímpica? É claro que podem haver exceções, mas no geral cada corporação já possui os seus padrões, a sua cultura e as suas necessidades no desenvolvimento das suas aplicações. A arquitetura de referência carrega o DNA da corporação.

A idéia central disso tudo é a criação de aplicações SOA com serviços interoperáveis, facilitando as integrações, reutilizações e a manutenção das aplicações, bem como o domínio sobre os problemas conhecidos atrelado com aumento de produtividade (agilidade).

Para finalizar e reforçar, eu considero fundamental a criação de uma arquitetura de referência em qualquer estratégia de implantação SOA. Alguém concorda ou discorda?

olimpiadas_soa3

Arquitetura de Referência SOA Olímpica

- Fábio Rosato

Related posts:

1. Boas Festas
2. Princípios Básicos de SOA – Serviços são Capazes de se Compor
3. Webinar: Maturidade e Roadmap SOA. Participe!

Meu Deus, o que fiz de errado?!?

Bom, ela eu não sei (talvez não acertou o gol:-)), mas como não estamos no blogdojuca, vamos tentar aplicar este pensamento para o contexto do nosso blog: “Meu Deus, o que as empresas têm feito de errado na implantação de SOA?!”

Você está cansado de todo mundo falar das balas de prata? Bom, que tal se discutirmos um pouco sobre o outro ponto de vista. Por que SOA pode fracassar? O que as empresas fazem errado?

Estes erros comuns, são tecnicamente chamamos de Anti-Patterns. Para mim, seriam “conselhos que devemos dar aos nossos inimigos”. Ou seja, são práticas comprovadamente erradas, muitas vezes baseadas em eperiências e tentativa/erro.

A experiência é a base de tudo

Acompanhei uma apresentação específica sobre esse tema no no 3o. SOA Forum, em São Paulo, em agosto de 2008, na qual destacaram 6 anti-patterns (vou apenas citá-los, já que eles estão sendo explicados no vídeo abaixo):

1. Try to Boil the Ocean. Não tente ferver o oceano! Não adianta parar toda a empresas para implantar conceitos e padrões em todos os projetos. Embora as definições devem ser corporativas, é importante definir um foco e eleger projetos piloto, para não ficar apenas na teoria (patinando e nunca conseguir aplicar em um projeto real).
2. Vamos implementar alguns Web Services. Embora webservices sejam uma boa abordagem para implantar os serviços de uma Arquitetura Orientada a Serviços, a simples existência desgovernada deles pode ser um tiro no pé.
3. Pensaremos em governança mais tarde. Qual o número de serviços eu preciso ter para começar a pensar em Governança? No máximo 1!
4. “Governar” vs. “Ser Governado”. É fundamental definir de forma clara os papéis e responsabilidades nas políticas de Governança. É importante considerar nas equipes que, de fato, várias pessoas que nunca se falaram vão passar a trabalhar em conjunto! (até falamos sobre isso no post: Adotar SOA é mais complexo do que parece). Barreiras culturais existem e não seria aqui que elas passariam despercebidas.
   
5. A nossa empresa é diferente. É difícil achar, no mundo, quem só tenha problemas inéditos. Mas, acreditem, é muito comum as empresas acharem que possuem um ambiente único. Mesmo em diferentes áreas, é possível reaproveitar, pelo menos, lições aprendidas.
6. Vamos às Compras. Ir ao mercado e abrir a carteira não garante que tudo vai se encaixar à necessidade de empresa. SOA é estratégico da empresa. É uma abordagem arquitetural interna. Deve ser feito “de dentro pra fora”.

Para facilitar a vida, a apresentação feita pelo Kleber Bacili está disponível (vídeo abaixo) e tem 45 minutos.

Bom proveito!

[]s
Marcílio

Related posts:

1. Boas Festas
2. Webinar: Maturidade e Roadmap SOA. Participe!
3. Davi x Golias em SOA

Estou falando do mercado de registries/registry. Ok, ok, não é tão natural assim, mas vamos limitar nossa amostragem de forma que pareça que é…

Parte dessa sonolência foi causada por uma seqüência de fatos mais ou menos assim: vários big-vendors de plataforma incluíam em seus produtos uma versão free de registry, tornando difícil para os niche-vendors competir com esse “preço”! Mas o barato sai caro ou, em business language, “you get what you pay for“, e esses registries eram bastante, digamos, inúteis (pouco investimento = poucas funcionalidades)! Pronto! Tá ai o impacto negativo no mercado de registries, ficando este a mercê dos bastiões da resistência Systinet, Infravio e SOA Software.

Lá por 2006 algumas empresas (onde “algumas” lê-se “FORTUNE 500”) que estavam investindo em SOA olharam para os seus serviços, que já estavam sendo implantados, olharam para os fracos registries e disseram: “Nossa! É disso que precisamos!”

Esse foi cutucão necessário para que o gigante começasse a se mexer (tem mel nesse pote!!) e começam as negociações/aquisições/junções. Ficou mais ou menos assim:

“João, que gostava de Alice, que gostava de Paulo, que gostava… Ops, história errada!”

“Mercury compra a Systinet e é comprada pela HP. WebMethods compra a Infravio. BEA é comprada pela Oracle depois de ter feito um acordo com a Systinet (assim como a TIBCO). Software AG cria a suite Crossvision baseada no produto da Centrasite. IBM luta consigo mesma (Rational) e SOA software segue seu caminho, investindo um pouco mais no seu produto.”

Olhando mais ao longe ainda vemos também gente com muito a evoluir (começaram bem, mas atualmente andam devagar) como a MuleSource, focada em ESB, mas que tem uma versão free da sua ferramenta de governança SOA (pobrinha, é verdade…).

Na linha Tupiniquim temos o DigitalAssets Manager (parcialidades a parte ) que busca o melhor dos mundos: já estabilizado e consolidado em design-time está com um pé (um pé e meio, vai…) em run-time.

E isso é só o começo! Essa história não está nem próxima do fim. Ainda nem comecei a falar das integrações, especialmente com UDDI (maioria), ebXML e o estilo “alone in the dark” da IBM. Aguardem e confiem!

Related posts:

1. Davi x Golias em SOA
2. Webinar: Maturidade e Roadmap SOA. Participe!