Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Qual o valor para o SOA Incremental?
Postado por Mark Little , traduzido por Thiago Pinelli em 26 Nov 2009
Em um artigo recente, John Moe discute a taxonomia das abordagens SOA, especificamente o SOA incremental - mais conhecido como Zero Middleware ou Guerrilha SOA. Como John diz, por aí estão...
... um número de gurus alternativos oferecendo para fazer SOA um pouco mais simples, opção acessível - que eu irei agrupar nesta discussão de Guerrilha SOA, porém também seguindo para diferenciar as abordagens para que você possa encontrar um caminho que melhor se adapte às suas circunstâncias.
Esta abordagem inclui:
- Web Services: para estes tipos de desenvolvedores "SOA é tudo sobre como criar os melhores WS-*código compatível, em Java ou .NET, no conhecimento em que cada serviço da Web pode chamar ou ser chamado usando as normas do WS evoluindo na Web".
- Agile: "Agile pode ser aplicado para SOA para diminuir tempo de desenvolvimento, porém devemos tomar cuidado para aplicar a abordagem de desenvolvimento de serviços, não da aplicação inteira, de outra maneira você irá acabar com um simples serviço aplication-sized".
- Provedores de Serviço: "Com o Software como Serviços (SaaS) tornando-se cada vez mais a corrente principal, os provedores de serviços (i.e. vendedores) por trás destas funções web-baseds estão promovendo o uso de abordagem de um navegador mais widgets para o desenvolvimento de aplicações, onde você justamente deve fazer um "misturar e combinar" o SaaS como oferta para atender suas necessidades de negócio".
- Vendedores de Produtos: "Existem ainda uma enorme e crescente população de vendedores de produtos SOA, excluídos do mercado, lutando com unhas e dentes por seu negócio. Muitos deles tem ferramentas de sistema engenhosos que podem assistir você, e eles ainda usam slogans como: "Compre nossa ferramenta e você não irá precisar comprar nada mais para fazer SOA", ou palavras que tenham este efeito. O ponto que os vendedores destas ferramentas estão tentando trazer é o seguinte: sua ferramenta é apenas uma parte da infra-estrutura Orientada a Serviço que você precisará, ou isto é tão grande que eles irão cobrar $250M [para setar uma infraestrutura SOA numa grande empresa]".
Jim Webber, Dave Chappell, Steve Jones e outros comentaram sobre este artigo, com o primeiro comentário sobre o custo aparente de fornecedores de soluções baseadas em SOA:
Meus empregadores (Oracle) ficariam muito felizes se $250M para cada projeto SOA em uma grande companhia se destinasse ao nosso middleware.
Mas, então, ele foca no core do argumento de John:
O maior custo de todo projeto, seja ele SOA ou outro qualquer, é o tempo das pessoas. Eu gostaria de argumentar que tentando fazer um projeto baseado nos princípios de SOA sem nenhum middleware é exatamente gastar mais tempo reinventando as rodas do que utilizar frameworks proprietários que têm que ser mantidos ao longo de tempo, ou pior, apenas deixado para trás pelos consultores de "Guerrilla"
Vindo da multidão "não-vendedor", Steve concorda com Dave:
+1É besteira dizer que o custo do produto é uma enorme parte dele. A maioria de seus projetos é de cerca de 10 a 1 ou maior ao longo de um programa de longo prazo e pelo menos 4 ou 5 a 1 sobre compromissos curto. Qualquer um que está gastando mais em licenças que em uma implementação SOA é um ignorante.
Jim, de uma outra companhia não-vendedora, , utiliza outra evidencia humorística para contrariar isso. Ele discute com base em um projeto de telecom que ele e sua equipe estava envolvido:
Antes de iniciar nosso primeiro projeto, onde o cliente já havia empreendido algumas analises de sua futura arquitetura (que necessitava de escalabilidade para 1 bilhão de transações por mês) usando uma consultoria blue-chip. A conclusão desta consultoria foi para que desenvolvessem um barramento para integrar os sistemas existentes e tudo o mais deveria vir junto. O custo do upfront foi de aproximadamente £10 milhões. Não é muito dinheiro para a maioria dos esquemas deste tipo, mas estes £10 milhões não proviam uma solução funcional, era somente o primeiro passo no processo que viria algum dia, porém, agregaria valor ao negócio, com poucos dados empíricos para sustentar esta informação.
O custo do vendedor foi muito grande, deixando uma porta aberta para uma alternativa. Portanto, usando as abordagens por trás de Agile e da Guerrilha SOA, a equipe de Jim foi capaz de gastar...
... duas semanas de trabalho através de uma análise do problema, incluindo alguns modelos matemáticos simples de como dominar o problema através do tempo, e como a solução iria se compensar. Nós utilizamos algum tempo para entender como alterar incrementalmente a arquitetura da empresa para entregar valor antes e propusemos fazer isso usando a comodidade de servidores HTTP com custo zero para o middleware. É importante que tenhamos a arquitetura de nossa abordagem sustentadas com números: nós medimos a taxa de transferência e as características latentes de um ataque representativo (uma peça de código utilizada para responder uma questão) através de nosso desenho de alto nível, e mostramos que ambos - HTTP e o Web Server de nossa escolha - foram adequados para os volumes de tráfego que o sistema deveria suportar.
De acordo com Jim o projeto foi de vento em popa, entregando, finalmente, a solução para o cliente com um pouco mais de despesas financeiras. O sucesso deste primeiro projeto levou a um segundo engajamento que também obteve sucesso. Jim conclui com uma resposta direta para a consideração de Dave sobre o custo das pessoas:
Mas o que é particularmente interessante, voltando ao assunto de custo de pessoas versus o custo do middleware, é isto: não gastamos nada com o middleware. No lugar disso, gastamos por volta de £1 milhão em pessoas, o que é favorável se comparado com os £10 milhões do custo da gambiarra proposta inicialmente. Para ser mais específico:Custo total de tocar o software em produção: £0 (middleware) + £1,000,000 (staff) = £1,000,000
Custo total da abordagem middleware: £10,000,000 (middleware) + £? (staff) = > £10,000,000
Steve respondeu ainda para Jim:
É maravilhoso se ele faturou nos custos o suporte para os próximos 5 (ou mais) anos....
Ele então concentrou na figura que Jim usou no seu exemplo, especificamente nos $10 milhões no middleware:
[...] se alguém gasta $10 milhões no upfront do middleware então esta pessoa é um completo e total idiota. Eu estou realmente lutando para pensar que alguém que tenha gasto este valor no upfront do middleware, inferno eu estou lutando para pensar em algum lugar que tenho gasto este valor fora de uma organização cujo gasto total é de mais de US $500 milhões por ano somente com TI.
É difícil de basear decisões sobre evidências anedóticas em ambas direções (pior ainda, uma instância não é uma boa amostra estatística para tirar quaisquer conclusões). Todos os praticantes SOA, vendedores ou não, terão em departamento análises do porque seus projetos obtiveram sucesso ou falhas, porém tem boas razões para não reabri-los. Sem dados verdadeiros e independentes sempre será difícil julgar os verdadeiros benefícios de uma abordagem versus outra. Entretanto, Steve conclui com um ponto interessante:
O ponto no post de Jim é que ele não considera que existem idiotas envolvidos na decisão dos $10 milhões... e exatamente agora meu dinheiro poderia estar lá.
Então, o debate continua!
Nenhum comentário
Acompanhar Discussão Responder