Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Existem notícias recorrentes de que boa parte dos projetos de SOA falham. Falham por não gerarem o retorno esperado, falham por excesso de complexidade ou simplesmente não chegam ao fim.
SOA parece ser o nome de mais uma síndrome da bala de prata – a solução de todos os problemas.
Vi isto acontecer com a Orientação a Objetos. Em 96, a empresa de informática que não estivesse usando OO não tinha futuro. Não havia profissionais com experiência em OO suficientes no mercado, mas todos faziam produtos baseados neste paradigma. E muitos falhavam.
Se tiver que fazer uma analogia, projetos SOA parecem ter mais em comum com projetos de Datawarehouse (DW) do que com OO. Como no DW, muitos tendem a querer abraçar o mundo e fazer projetos gigantescos – o que é excelente para consultorias mas nem sempre para seus contratantes. Se aprendemos com o DW o quanto é difícil definir conceitos mais simples como, por exemplo, um “produto” (imagine as diferenças de significados e atributos para áreas distintas como Vendas e Produção), imaginem o quanto isto aumenta se agora tivermos que definir também os verbos e seus argumentos!? Não é isto que temos que fazer na SOA?
Parece que projetos SOA têm mais sucesso quando têm escopo pequeno e crescem de acordo com o ganho de maturidade das equipes de desenvolvimento (criação e consumo de serviços), de operação e governança. Boa dose de pragmatismo, cuidado técnico e respeito à cultura da empresa são fundamentais.
Nunca construir WebServices para um dia serem usados (bottom-up). Nunca construir uma grande visão para definir ao fim os WebServices (top-down). Parece que aqui também a virtude está no meio.
Comments
Anonymous
September 01, 2008
Otavio, Passei por uma história semelhante. Em 98, trabalhava numa empresa de TI que a área de metodologia insistia em implementar OO em VB5. Eu argumentava que não tinha herança e o que propunham na época era inviável. Alegavam que uma grande instituição financeira usava OO com VB5. Até sairam alguns livros disso. Desnecessário dizer o que aconteceu com essa iniciativa. Acho que pecamos pelo desejo de expor todo o negócio, ou boa parte dele, como serviço. Quando falamos em tecnologia, é comum nos esquecermos dos requisitos não funcionais do software que estamos construindo. Desempenho e alta disponibilidade são resolvidos com escalabilidade horizontal e balanceamento de carga. Ai chega um desavisado e pergunta, mas por que você precisa mesmo expor isso como serviço? É nessa hora que acho escolha por SOA é mal sucedida. Vão acabar colocando a culpa na tecnologia, em vez de perceber que foi o emprego equivocado da tecnlogia que fez falhar. SOA é excelente, só temos que usá-la a nosso favor. []sAnonymous
September 12, 2008
Otavio, Não acho nem que a explosão do OO nem que o atual boom do SOA sejam prejudiciais. O grande problema do passado foi exatemente o que você disse, não era a OO e sim quem estava aplicando o tal paradigma sem conhecimento de causa (muita gente até hoje tem problemas com ele). Quando se fala em SOA hoje logo se pensa em Webservices. Acho que esse é o nosso grande erro hoje. Pensar em sistemas hoje é pensar em Serviços de software. Sejam eles apresentados para a nuvem(como gosta de falar o Cambiuci) ou não. Diogo Curto