terça-feira, 24 de novembro de 2009

SOA Manifesto

Após o mundo de TI passar por algumas rodadas de disseminação do conceito SOA, sem esquecer de alguns tumultos “provocados” pelo post “SOA is Dead; Long Live Services”, alguns bam-bam-bans no tema, motivados por Thomas Erl e incluindo a autora do post citado, compilaram o “SOA Manifesto”. Segue uma tradução livre:

 

Manifesto SOA

Orientação a serviço é um paradigma que direciona o que você faz.
Arquitetura orientada a serviço é um tipo de arquitetura que resulta da aplicação de orientação a serviço.

Nós aplicamos orientação a serviço para auxiliar organizações a entregar valor de negócio sustentável de forma consistente, com maior agilidade e eficiência de custo, alinhado às necessidades de mudança do negócio.

Através de nosso trabalho nós priorizaremos:
Valor de negócio acima de estratégia técnica
Objetivos estratégicos acima de benefícios específicos de projeto
Interoperabilidade intrínseca acima de integração customizada
Serviços compartilhados acima de implementações de propósito específico
Flexibilidade acima de otimização
Refinamentos evolutivos acima de busca da perfeição desde o início
Ou seja, enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.

 

Princípios que Guiam o Manifesto SOA

Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção de SOA pode variar. Manter esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe fornecerão SOA nem aplicarão o paradigma de orientação a serviços para você.
SOA pode ser concretizada através de várias tecnologias e padrões.
Estabelecer um conjunto uniforme de políticas e padrões corporativos baseado em padrões de facto da indústria e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre interessados de negócio e tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro de utilização.
Verificar se os serviços satisfazem os objetivos e requisitos de negócio.
Evoluir os serviços e sua organização em resposta ao seu real uso.
Separar os diferentes aspectos de um sistema que mudam em ritmos diferentes.
Reduzir as dependências implícitas e publicar todas as dependências externas para aumentar a robustez e reduzir o impacto de mudanças.
Em todo nível de abstração, organizar cada serviço em torno de uma unidade de funcionalidade coesa e gerenciável.

 

E ai, concorda? Então vai e “assina embaixo”! :-)

quarta-feira, 18 de novembro de 2009

Engenharia de Software – Escopo, Prazo, Custo e Qualidade

Sempre que falamos em desenvolvimento de software surge o triângulo:

Não há mágica a ser feita. Para uma mesma área, aumentar um lado implica em diminuir um outro. Mas isto pressupõe que o escopo é (totalmente) conhecido e, o mais importante, não sofrerá mudanças. Já foi esse tempo, não dá mais pra atender ao cliente com escopo fechado. Já dizia o filósofo Heráclito: “a única constante é a mudança”.

No artigo do Ivar Jacobson “Closing the Gap between Business and IT”, ele cita:

“We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants. This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.”

Em resumo, temos que saber lidar com a mudança e demonstrar resultados rapidamente e com qualidade.

Em outro artigo, da Marília Coelho, “Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software”, a autora fala das dificuldades no entendimento do problema do cliente e cita uma frase de Einstein:

“Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução.”

Isto tem a ver com a “pressa” e com a visão míope do “dá pra fazer”, sem buscar o entendimento sobre a real necessidade do cliente e sem explorar as alternativas mais apropriadas.

Ela também cita alguns dados do Standish Group:

“41% dos projetos falham em adicionar valor ao negócio e sobre o Retorno de Investimento – ROI.

49% dos projetos ultrapassam as estimativas iniciais de custo.

Somente 28% dos projetos acontecem no prazo e no orçamento.”

O escopo fechado traz, no início do projeto, a ilusão da certeza do prazo e do custo. Qualquer mudança posterior é temida! A tal da “change request”!

A autora ainda discorre sobre a necessidade de mudança de cultura na engenharia de software e conclui:

“Para que os três pilares – processo, ferramentas e pessoas – funcionem de forma harmônica na organização, o suporte executivo é fundamental, pois as ansiedades, e a pressão do “fazer para ontem” são forças que devem ser gerenciadas corretamente. Os números mostram que continuar como está não é bom para o negócio e não é bom para TI. Pense em fazer algo para mudar o futuro da engenharia de software, conseqüentemente mudando a percepção de que TI não é um centro de custo, mas sim uma área que agrega valor ao negócio através da inovação tecnológica.”

Pensamentos Finais

Escopo muda, é um fato, e assim deveria ser tratado. Com entregas ágeis, frequentes e com qualidade o prazo (final) deixa de ser um “bicho-papão” e a previsibilidade sobre o custo torna-se maior. Ganhar a confiança do cliente, mantendo-o sempre envolvido, aumenta as chances de sucesso pois, no fim das contas, há um relacionamento humano.

Vida longa e próspera à engenharia de software!