SOA Manifesto

Durante o 2nd SOA Symposium Conference, realizado no último final de semana, foi publicado o SOA Manifesto, um conjunto de princípios e intenções que deveriam fundamentar qualquer iniciativa de SOA.

Aqui vai uma tradução do manifesto, que pode ser encontrado na sua versão original em http://soa-manifesto.org/.

Orientação a serviços é um paradgma que modela o que fazemos. Arquitetura Orientada a Serviços (SOA) é o tipo de arquitetura resultante da aplicação da orientação a serviços. Aplicamos orientação a serviços para auxiliar organizações a entregarem valor de negócio de maneira consistente e sustentável, de forma cada vez mais ágil, com custos efetivos e em linha com as voláteis necessidades de negócio.

Priorizamos:

Valor de negócio em relação à estratégia técnica
Objetivos estratégicos em relação à benefícios específicos de/para o projeto
Interoperabilidade inerente em relação à integração customizada
Serviços compartilhados em relação à implementações específicas
Flexibilidade em relação à otimização
Refinamento evolutivo em relação à perfeição inicial

Apesar dos itens da direta terem seu valor, valorizamos mais os itens da esquerda.

O manifesto conta ainda com uma lista de princípios que podem servir como guia na adoção de SOA: http://soa-manifesto.org/principles.html.

IT BSC e a Arquitetura de TI

O Balanced Scorecard (BSC), criado por Robert Kaplan e David Norton na década de 90, é um framework para medição do desempenho corporativo. Criado a partir de uma pesquisa realizada em 12 empresas de grande experiência em medidas de desempenho coorporativo, o BSC permite que a alta gerência tenha uma visão ampla de diferentes aspectos do negócio possibilitando acompanhamento da sua dinâmica. A proposta é que sejam identificados objetivos e medidas em 4 perspectivas que visam responder algumas perguntas genéricas:

• Financeira: Como os acionistas vêem a empresa?
• Cliente: Como os clientes vêem a empresa?
• Processos Internos: Em que a empresa tem que ser excelente?
• Aprendizado e Crescimento: Onde e como a empresa pode inovar e gerar mais valor?

Para informações mais detalhadas do BSC sugiro o artigo da Harvard Business Review intitulado "The Balanced Scorecard - Measures that Drive Performance".

Quase uma década mais tarde, Kaplan e Norton identificaram a importância do relacionamento das medidas nas 4 perspectivas e das suas relações de causa e efeito como critério de sucesso para atingimento dos objetivos propostos pelo BSC. Foi então que eles criaram o chamado "Strategy Map" representado pela figura abaixo, que foi extraída do artigo original escrito por eles.

Tendo sido amplamente adotado na esfera de negócio, o BSC e o Mapa Estratégico passaram também a ser aplicados em TI, sendo que nos últimos anos começaram a surgir casos de sua aplicação.

Aplicadas em TI e batizadas de IT BSC (Information Technology Balanced Scorecard), as 4 perspectivas do BSC foram adaptadas e ficaram assim:

• Contribuição para o negócio: Como as gerências das áreas de negócio (clientes) vêem a área de TI?
• Orientação ao Cliente: Como os usuários vêem o departamento de TI?
• Excelência Operacional: O quanto eficiente e eficaz são os processos de TI?
• Orientação ao Futuro: O quanto TI está preparada para atender as necessidade futuras do negócio?

Dentre as lições aprendidas dos casos de aplicação do IT BSC está a importância do seu relacionamento com o BSC corporativo. 

É justamente esse relacionamento que na prática pode representar o tão falado "alinhamento de TI ao negócio". A final de contas, quando falamos desse "alinhamento", estamos nos referindo ao alinhamento dos objetivos das duas áreas.

Resumindo, o BSC é a ferramenta que além de promover esse alinhamento pode ser utilizada para definir, comunicar e acompanhar a execução das estratégias corporativa e de TI estando intimamente ligado ao dia-a-dia de trabalho de cada colaborador.

Mas o que isso tem a ver com Arquitetura de TI? 

Vamos olhar mais de perto um exemplo de IT BSC detalhando suas perspectivas:

Considerando que os principais processos da área de arquitetura de TI são:

• Construção da arquitetura atual (As-is);
• Construção da arquitetura futura (To-be);
• Análise de defasagem (Gap analysis); e
• Criação do mapa diretor (Roadmap), 

Temos que a evolução da arquitetura de TI pode ser medida pelo progresso de implementação do roadmap em direção à arquitetura futura. 

O roadmap, também chamado de plano de evolução, determina padrões técnicos e arquiteturais a serem seguidos. Tais padrões servem de base para a medição da aderência ao plano que é um dos objetivos da perspectiva Orientação ao Futuro em um IT BSC. Vale ressaltar ainda a importância de serem definidos marcos para auxiliar o acompanhamento e a medição do desempenho.

Erros comuns na adoção de SOA

Essa semana assisti um vídeo no Youtube sobre erros comuns na adoção de SOA. Trata-se de um apresentação do David Linthicun com o nome "5 coisas a serem evitadas ao adotar SOA". Além de dar dicas sobre caminhos a não serem seguidos, David Linthicun mostra, em alto nível, uma metodologia de adoção de SOA.

Os 5 erros apresentados são:

1) Usar as pessoas erradas ao compor o escritório de arquitetura ou o chamado SOA CoE (Center of Excelence);
2) Selecionar a tecnologia muito cedo. (Comece pelos requisitos!);
3) Não considerar o design de serviço;
4) Não ter o foco nas necessidades do negócio;
5) Não pensar a longo prazo e de maneira estratégica (Pense grande, inicie pequeno e evolua rápido).

Como não era de se esperar, vemos logo no primeiro erro a importância que deve ser dada às pessoas. A final de contas é difícil conseguir bons profissionais com um perfil generalista de atuação em todas as áreas da Arquitetura de TI (Processos/Negócio, Informação, Sistemas, Integração e Tecnológica) ou nem sempre a empresa tem condições de bancar um profissional com experiência na área. Essa mesma importância dada às pessoas é ressaltada no artigo do Gartner denominado "Horror Story Shows How Poor Governance Leads to Failure in SOA Initiatives", que diz:

"Terceirizar arquitetos ou não tê-los de maneira adequada, significa que a empresa não possuirá as competências necessárias para um projeto SOA."

Esse mesmo artigo do Gartner diz ainda:

"Crie um ICC (Integration Competence Center) ou um SOA CoE (SOA Center of Excelence) que inclua membros das áreas de negócio e desenvolva-o. Você precisará de um para se certificar que o projeto de adoção de SOA está no caminho certo."

Sobre o erro 2, selecionar a tecnologia muito cedo, o artigo do Gartner também está alinhado. O artigo diz que as pessoas tendem a associar SOA com tecnologia e que se um projeto SOA falha é devido a escolha da tecnologia errada. Entretanto várias projetos falham pela falta de importância dada à governança.

Em linhas gerais a metodologia sugerida pelo David Linthicun é composta dos seguintes passos:

1) Entenda os objetivos de negócio e defina critérios de sucesso;
2) Defina o domínio do problema;
3) Entenda todas as aplicações envolvidas;
4) Descubra e entenda todos os serviços no domínio do problema;
5) Descubra e entenda todos os processos no domínio do problema;
6) Identifique a necessidade de criar novos serviços;
7) Identifique a necessidade de criar novos processos;
8) Selecione as tecnologias e ferramentas a serem usadas.

O vídeo da apresentação pode ser encontrado em http://www.youtube.com/watch?v=0CbjUNzBV6I&feature=channel

Os slides estão aqui...