Pensando nisto esta figura, que segue, do processo de melhoria continuada que encontramos na ITIL é um tanto quanto esclarecedora.

Apesar de parecer tão claro que devemos saber qual a nossa meta e onde estamos, muitas vezes nos pegamos saindo correndo por aí sem olharmos com atenção qual é o nosso ponto de partida. Isso pode ser até mesmo desastroso porque se percebemos, no meio do caminho, que tomamos a direção errada talvez já seja tarde a correção dessa rota.

Logo que tive contato com o OSIMM fiz alguns exercícios, no caso fiz uma avaliação rápida de uma empresa que trabalhei e que na época não conhecia este padrão ainda. Neste exercício de 20 minutos eu acreditava que o nível de maturidade de todas as dimensões iria ser nível 1. Para 3 dimensões o nível era realmente 1 mas, para minha surpresa, em duas classifiquei como nível 2 e em uma outra dimensão chegou até nível 3. Moral da história: nem sempre estamos tão certos assim do nosso ponto de partida.

Aí que gostaria de chamar a atenção da importância do Assessment para descobrirmos se estamos num estágio inicial ou, talvez para a surpresa de alguns, não tão inicial assim. Lendo livros sobre governança SOA os autores* falam sempre da necessidade do assessment, segue alguns motivos para fazermos o assessment:

• Para determinarmos a melhor maneira de introduzir os novos preceitos, processos e políticas;
• Para entendermos o estilo e cultura organizacional da organização, já que não existe um padrão de abordagem da governança;
• Identificar as áreas de necessitam de prioridade no seu desenvolvimento;
• Ajudar no alinhamento com o roadmap;

Existem níveis de maturidade e assessment como o COBIT, CMMI e no caso específico de SOA estamos falando do OSIMM, que nos ajuda a efetuar esta avaliação.

*REFERÊNCIAS:

ERL, Thomas et al. SOA Governance: Governing shared services on-premise and in the cloud. New Jersey: Prentice Hall, 2011.

BROWN, William A. et al. SOA Governance: Achieving and sustaining business and IT agility. New Jersey: IBM Press, 2009.

Related posts:

1. Avaliando a maturidade em SOA
2. The Open Group Brasil – Sao Paulo, May 24, 2012

 As inscrições para o Open Group Brasil Conference estão abertas, evento com assuntos bem interessante, vale a pena! Confiram:      http://www3.opengroup.org/brasil2012

Abs!

Related posts:

1. Avaliação do atual nível de maturidade.

Além do fato de, nos processos convencionais, todos os artefatos serem entregues somente no final do projeto, normalmente, os guias gerados são extensos demais, ocasionando outro grande problema que é a dificuldade na absorção do conteúdo gerado.

Somando-se os dois problemas, temos um processo longo que demora no mínimo seis meses para começar a entregar resultados e, quando esses são entregues, são de difícil compreensão e acabam não agregando tanto quanto poderiam agregar.

Para tentar minimizar este problema, a adoção de práticas de metodologias ágeis, tais como o Scrum, tem sido uma alternativa na agregação de resultados para o cliente. Um grande diferencial deste tipo de metodologia é a definição de espaços menores de tempo (Sprints), que variam entre duas a quatro semanas, onde são definidas quais atividades/entregáveis devem ser realizados e, ao término deste período, os resultados são apresentados, revisados e um novo Sprint é planejado e tudo começa outra vez.

O Scrum define alguns papéis: Product Owner, Scrum Master e Time Scrum. Geralmente um projeto de consultoria SOA conta com apenas um consultor e a equipe envolvida do cliente. O consultor exerce papel de Scrum Master e Time Scrum, pois é o principal gerador de conteúdos além se preocupar com as atividades do backlog que estão com problemas (blocks). O ponto focal do cliente atua como Time Scrum pois, além de revisar os artefatos gerados, algumas atividades, principalmente durante o piloto, são endereçadas a ele, e também tem o papel de Product Owner, afinal, é ele quem prioriza o backlog. Os ritos – Sprint Planning, Spring Review e Daily Meeting – e ferramentas – ProductBacklog, SprintBacklog – são utilizados para contemplar a metodologia.

Esta abordagem, considerada uma abordagem leve, tem se mostrado muito eficiente, pois o cliente não precisa ficar esperando o término do projeto para ver os resultados.  Os guias criados, como são revisados no final de cada Sprint, tendem a ser menores e mais focados no objetivo real do guia. Além disso, um dos pontos mais importantes, todos os guias e definições são validados em um projeto real, um piloto que garante que todas as definições serão aplicadas e validadas de acordo com a necessidade real da corporação.

O Scrum, na maioria das vezes, é recomendado para projetos complexos onde as mudanças devem ser gerenciadas e priorizadas constantemente. Pode até ser que esta não seja uma característica dos projetos de consultoria SOA, no entanto, em meu último projeto de consultoria, adotamos um processo de gestão ágil que trouxe grandes ganhos, pois nosso Backlog de execução se moldou de acordo com as demandas imediatas e, às vezes, inesperadas de governança SOA do cliente. Graças à utilização de Sprints curtos (duas semanas) e da flexibilização do Backlog, conseguimos atender todas as demandas do cliente.

Assim como o ESB (Enterprise Service Bus) atua como um mediador, permitindo que web services conversem uns com os outros sem a necessidade de criar um relacionamento ponto-a-ponto específico para cada um deles, um modelo canônico permite que sejam definidos esquemas para as entidades de uma organização (ex. Cliente, Produto, Fatura, etc..), desta forma, todos serviços fazem uso desse mesmo modelo de dados canônico, reduzindo o número de transações, o custo de infraestrutura e o custo de implementação e garantindo uma maior padronização como consequência do aumento do reúso.

Definir as entidades separadamente para cada serviço implica em um contrato de serviço (WSDL) totalmente customizado para cada serviço. Isto pode significar muita redundância, também conhecido como desnormalização de esquema.

Qualquer serviço que necessite fazer troca de dados pode traduzir sua versão de dados local para versão canônica.

Considere que uma empresa adquiriu outra empresa. Ambas as empresas possuem a entidade Funcionário. No entanto, o esquema de ambas as entidades são diferentes. Utilizando o modelo de dados canônico, basta que os dois serviços mapeiem seus dados para o modelo canônico, eles não precisam mapear de um para o outro ou serem individualmente reescritos.

A transformação de dados local para o modelo canônico ocorre mais frequentemente de três formas:

• O Consumidor 1 chama o Serviço A. Ambos utilizam o modelo canônico, nenhuma transformação é necessária, sendo esta implementação a ideal;
• O Consumidor 2 chama o Serviço B. A transformação para o modelo canônico ocorre dentro do barramento;
• O Consumidor 3 chama o Serviço C. Um adaptador transforma a mensagem do modelo local do serviço para o modelo canônico.

O modelo canônico existe para definir conceitos e agem como mediadores ideais.

O modelo canônico deve ser mantido de forma flexível e geral, dado que eles irão potencialmente absorver uma variedade de definições de entidades.

A evolução do modelo canônico implica na evolução do contrato do serviço (WSDL), já que o esquema faz parte do contrato do serviço (WSDL), sendo assim, será necessário re-gerar código do serviço.

A evolução do modelo canônico deve ocorrer através da governança SOA. Os esquemas podem ser versionados. Indicando explicitamente a versão do esquema no namespace, têm-se a liberdade para mudar apenas os serviços necessários no momento, sem a necessidade de alterar todos os serviços de uma só vez. Os demais serviços podem ser alterados ao longo do tempo, mas o ideal é que essa atualização não demore a ser feita. Ter muitas versões de esquema canônico em uso, pode levar a não se ter mais o esquema canônico. As atividades de governança para este processo devem estar bem definidas.

Abraço,
Daniel Varanda

Representação do Modelo Canônico em uma abordagem SOA

Related posts:

1. O lado técnico da aquisição de um ESB

A aquisição de um ESB (Enterprise Service Bus) para compor o barramento de serviços de uma empresa é sempre um processo complexo. Se bem estruturado, o processo pode prever uma RFI e/ou PoC, além de outras RF’s.

E se a sua preocupação dentro desse processo está do lado técnico, segue abaixo uma lista de categorias de itens técnicos que são importantes observarmos em um ESB:

• Conectividade
• Linguagens
• Containers
• Mapeamento e Transformação
• Invocação
• Roteamento de Mensagens
• Processo ou Composição de Aplicação
• Formato de dados
• Depuração
• Logging, Trilha de Auditoria e Transaction Tracking
• Armazenamento
• Deployment
• Performance e Escalabilidade
• Segurança e Transação
• Testes, Operação e Monitoramento
• Ferramenta de Desenvolvimento e Gerenciamento
• Suporte e Integração a Outras Tecnologias

[]‘s

Fábio Rosato

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. Aplicação de Metodologia Ágil em Consultorias SOA

Fiz um porto no Blog IT Web SOA sobre como avaliar a maturidade em SOA.

Vocês podem acessar o texto original em: http://www.itweb.com.br/blogs/blog.asp?cod=167

Abraço,
Kleber

Related posts:

1. Avaliação do atual nível de maturidade.

A Sensedia, empresa especializada em soluções de Governança SOA, está com vagas em aberto para Consultor arquiteto SOA.

Se você já trabalha ou pretende trabalhar em projetos focados em definições de Governança SOA e boas práticas relacionadas a arquitetura de serviços, vale a pena entrar em contato. A Sensedia possui um time de consultoria especializado, e  possui modelos interessantes aplicados à Operação SOA e implantação de Governance as a Service, com de repositório e barramento de serviços.

Você pode enviar seu CV pelo site da empresa, ou enviem para rh@sensedia.com.

Dada a notícia!

abraços,
Marcílio – @marcilioso

A gente pode fazer melhor do que isso!

–

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB

Fiz um post no blog da IT Web sobre SOA falando sobre o papel dos Repositórios SOA.

Caso se interessem: http://www.itweb.com.br/blogs/blog.asp?cod=167

Abraço,
Kleber

Related posts:

1. Avaliando a maturidade em SOA

Toda mudança gera desconforto, mesmo quando é para melhor. Um dos grandes desafios que as empresas enfrentam na adoção de SOA não está relacionado a barramentos de integração, repositórios de serviços, ou tecnologias de web services, XML ou WSDL.

Muitas empresas já investiram em ferramentas e treinamentos técnicos para seus times e, não raro, o resultado atingido por SOA dentro da empresa ainda não pode ser classificado como “um sucesso”.

O desafio em questão é conseguir aplicar, na prática, os métodos, ferramentas e conhecimentos técnicos muitas vezes já disponíveis na empresa.

Recentemente um de nossos clientes nos contatou com esse desafio: “Já fizemos investimentos em ferramentas, nossos processos já foram ajustados e as pessoas até já foram capacitadas em algumas das tecnologias relacionadas a SOA. Mas ainda vemos que há bastante espaço para avançar na aplicação de SOA nos projetos”, dizia o gestor de arquitetura da empresa, uma grande empresa no segmento de seguros.

O cliente trouxe também uma semente de idéia: que tal fazermos um treinamento diferente, que fosse prático, totalmente customizado para a nossa realidade usando as ferramentas e processos que já definimos, mas de forma vivencial e lúdica?

A partir dessa idéia inicial montamos em conjunto a proposta de um treinamento de Alto Impacto em SOA. Teríamos equipes de analistas, simularíamos uma competição entre eles. Usaríamos as ferramentas e processos já existentes na empresa, mas sobre uma temática diferente da usual. Levamos para uma outra sala os gerentes desses analistas para que, no final, pudessem presenciar os resultados obtidos pelos seus comandados.

Identificar e desenhar serviços, aplicar governança, promover o reuso e acompanhar o retorno do investimento, foram tarefas bravamente desempenhadas pelas equipes e o resultado final deixou a impressão que aplicar na prática o que foi visto em sala de aula seria bastante natural.

Agora é acompanhar como as equipes reagirão no dia-a-dia. Estaremos atentos.

—-

Fonte: IT WEB - http://www.itweb.com.br/blogs/blog.asp?cod=167

–

Related posts:

1. Aplicação de Metodologia Ágil em Consultorias SOA

Vejam o artigo sobre Mapa de Integração que a ComputerWorld divulgou na quarta.

Mapa de Integração: agilidade para tomada de decições em TI

O ambiente de TI das médias e grandes empresas tem se tornado mais complexo. Pacotes adquiridos, normalmente com diversas customizações, sistemas desenvolvidos sob medida nas mais diversas linguagens de programação são o pano de fundo da inflexibilidade de TI. Somem-se a isso todas as integrações ponto-a-ponto desenvolvidas para que os sistemas e processos de negócio sejam minimamente integrados e chegamos ao cenário no qual qualquer mudança pode gerar impactos inesperados.

O artigo completo pode ser lido em: http://computerworld.uol.com.br/blog/opiniao/2010/11/17/mapa-de-integracao-agilidade-para-tomada-de-decisoes-de-ti/

Por Kleber Bacili, diretor de Tecnologia da Sensedia

Abraço,
Kleber

Related posts:

1. Avaliando a maturidade em SOA
2. O lado técnico da aquisição de um ESB
3. O Modelo Canônico em uma abordagem SOA