Abordagens SOA

[Former Member]

Olá Pessoal,

Gostaria de saber como estão focadas as abordagens aos clientes no que diz respeito a SOA, desde o final de 2006 que de uma forma ou de outra estou envolvido com o assunto, tive oportunidades de vivenciar diferentes abordagens aos clientes:

1 - Foco na ferramenta: Pré-vendas chega ao cliente diz que vai resolver todos os problemas existentes com o seu ESB/BPEL/Gerenciador de Web Services e BAM, em momento algum, ou raramente são mostrados os benefícios reais de se usar SOA ou uma análise mais aprofundada sobre ROI (retorno de investimentos) realmente é feita. Apenas é dito que o ROI é garantido, afinal está no folder do produto. Ok, o projeto é vendido, concluído, porém pode ser que apenas complexidade foi adicionada ao landscape do cliente e nada de TI alinhada aos negócios foi alcançada.

Resultados dessa abordagem que já vivenciei: Clientes dizendo que gostou do que foi feito, que agora ele tem serviços que serão reaproveitados etc. e clientes dizendo que "ficou legal", mas que não conseguiu enxergar de onde ele terá o seu ROI (nesse caso especifico, um ponto que faltou foi metodologia, os serviços selecionados de fato não foram os que realmente precisariam de uma remodelada).

Minha visão: As vezes o foco é muito em cima da ferramenta e negócio do cliente nao é de fato avaliado.

2 - Foco nos Ativos: Empresa especializada em soluções de governança (parões, leis, gerencia de mudanças, SLA), tenta de todas as formas mostrar ao cliente que ele precisa adquirir a ferramenta deles para poder gerir seu maior ativo (codigos), não deixa de ser verdade.

3 - Processos: Empresas especializadas em analisar os processos existentes, usam de fato BPM, normalmente se preocupam com governança.

Ou seja, na minha visão várias formas de vender SOA. Seria ideal que uma empresa tivesse tudo isso pra oferecer aos clientes (Ferramentas, metodologias)

Seria legal ver como as empresas estão tratando essas questões com os clientes SAP.

Será que alguém compartilha dessa mesma visão? tem outra opinião?

[]'s e parabéns pela iniciativa de criação desse forum.

[henrique_pinto]

Movendo para o fórum de tecnologia.

[Former Member]

Laércio,

A minha analogia com "arquitetos" e "pedreiros" tem, a meu ver, muito a ver com estas dificuldades de estabelecimento de SOA como plataforma realmente "útil" para o Cliente.

SOA é o território dos "arquitetos", profissionais que entendem dos processos do Cliente e que "mapeiam" estes processos em ferramentas como Aris e, em seguida, modelam estes processos (A SAP está lançando sua ferramenta de BPM esta semana) utilizando os serviços do Composition Environment (já disponível a partir do ECC 6.0 EhP 3), "conectando-os" para que possam recriar tais processos dentro do SAP, sem criar (ou com um mínimo de) linhas de código ABAP.

Até hoje todos os gaps de um blueprint eram "preenchidos" com um código ABAP, concebido por um Analista Funcional e codificado por um programador, que representa o meu conceito de "puxadinho", obra típica de "pedreiros", sem sentido pejorativo, por favor.

SOA permite a criação "elegante" e "flexível" de processos específicos que "cobrem os gaps" correspondentes a um momento específico de mercado de uma empresa, podendo ser reconfigurados quando o mercado mudar novamente (criando novos gaps), enquanto o "puxadinho" é rígido e fica lá, atrapalhando, até que seja demolido, com uma marreta, quando não for mais útil.

Mudar a mentalidade do Ecossistema para que tenhamos mais "arquitetos" e menos "pedreiros" é o principal desafio da Cumunidade SOA que estamos promovendo.....

Existe também toda a discussão do novo modelo econômico que os parceiros do Ecossistema vão precisar adotar, com poucos programadores ABAP e muitos Business Process Experts e Business Process Analysts.

Uma mudança e tanto. Mas isso é tema para o Blog do SOAT2.

Confiram:

[Former Member]

Fernando,

Architect, developer, tester... são apenas papéis que assumimos, em maior ou menor escala, durante um projeto e ainda não vejo ligação direta com SOA.

Acredito que isso é efeito da ambigüidade causada pelos diversos pontos de vista sob os quais SOA é definido. Desenvolver software nunca foi função para u201Cpedreirosu201D e muitos projetos falharam miseravelmente por não aceitarem isso. Afinal, flexibilidade e uma coerente representação do domínio sempre foram requisitos para uma solução.

Nós, que estudamos o desenvolvimento de software há algum tempo, reconhecemos que numa perspectiva técnica, SOA baseia-se em conceitos que a indústria não soube (ou não quis?) utilizar, tais como: enterprise architecture (building blocks), domain-driven development, CBA, agile...

Enfim, IMHO, SOA é território para um bom time de consultores. Concordo com vc em relação a mudança de pensamento e este é um grande desafio, mas nunca é tarde pra começar!

[]s

Laércio Queiroz

http://laercioqueiroz.wordpress.com

[Former Member]

Pessoal,

Estou achando interessante que existe um consenso a respeito do tipo de profissional que deve atuar nas frentes SOA. Ou seja sabemos que o profissional deve ser multidisciplinar, que saiba do negócio e que conheca a parte técnica da "coisa".

Nomeclaturas realmente estão aí e cada dia teremos uma nova, em 2006 quando comecei atuar no mundo SOA, apereceu na empresa que estava, o nome Arquiteto de Soluções, pelo menos por aqui até então era comum Arquiteto de sistemas apenas, sendo que na verdade os Arquitetos de Solucoes eram os mesmos Arquitetos de sistemas das empresas e é o que continua acontecendo até hoje.

Concluindo, o mais importante é mapear o perfil necessário para esses novos desafios.

[]'s

Isaías Barroso

Belo Horizonte - MG

[Former Member]

Isaias,

Obrigado pelo post.

Certamente a SAP está fugindo destes cenários que você menciona. Nosso foco é mostrar valor E evolução técnica. Eu costumo dizer que a SAP está sinalizando ao mercado que os Clientes vão exigir mais "Arquitetos' e menos "Pedreiros" daqui em diante. Ou seja, numa analogia com um projeto de uma casa, vamos criar mais espaços inteligentes que possam ser reconfigurados à medida que os moradores também mudem suas necessidades. Tradicionalmente a cada necessidade de mudança, a família construiría um "puxadinho", que atende à necessidade, mas altera o projeto de forma definitiva. Em algum tempo o projeto original está totalmente desconfigurado e precisamos de uma "nova casa".... Vamos alavancar o discurso da flexibilidade com SOA. O Business Suite 7 é todo construído baseado em SOA. Será possível "reaproveitar" serviços de CRM em um processo de APO, por exemplo. Cada empresa pode configurar e reconfigurar seus processos à medida que o mercado as obrigue a mudar produtos, modelos, processos.

Esta é a promessa. Estamos convidando o Ecossistema SAP de parceiros a "evoluir" para um modelo que torne esta promessa uma realidade. Não adianta a SAP fazer o discurso e nossos Parceiros não adotarem em suas práticas de consultoria.

Todos teremos que "evoluir" juntos.

A SAP criou uma comunidade de estudos de SOA, chamada SOAT2 (SOA Transformation Team), aberta a todos os nossos Parceiros. Esta foi a rezão da abertura deste Forum. Para que a comunidade pudesse trocar experiências e conhecimentos.

Você e todos estão convidados a participar......

[Former Member]

Fernando,

Obrigado pela resposta, não marcarei o post como respondido por enquanto, talvez alguem de outra empresa queira dar alguma opinião a respeito.

Creio que não irei conseguir participar diretamente do SOAT2, por não estar ligado diretamente a um parceiro, mas vou ficar de olho no fórum.

[]'s

Isaías Barroso

Belo Horizonte

[Former Member]

Isaias, meu amigo, bom vê-lo por aqui!

Evitar o vendor lock-in é um dos principais desafios na adoção de SOA. Alguns fabricantes estão mais preocupados em vender seus produtos, do que agregar valor ao negócio do cliente.

Lembro de uma frase do médico Drauzio Varella, bastante interessante e que serve como analogia ao que estamos discutindo:

u201CAtualmente investe-se cinco vezes mais em remédios para a virilidade masculina e silicone para mulheres do que na cura de Alzheimer. Daqui por uns anos, vamos ter velhas de seios grandes e velhos de pinto duro, mas que não vão se lembrar para que servemu2026u201D.

Não adianta empurrar produtos nos clientes sem que estes entendam o que é e como se tem SOA. Você certamente já deve ter visto grandes investimentos em ferramentas, como se os clientes quisessem u201Ccomprar SOA do fabricante xxxu201D.

Particularmente, gosto da abordagem da SAP (referente à packaged services) e de outro fabricante (modelo conceitual e ferramentas). Contudo, acredito que não há uma que se encaixe em todas as soluções, por isso é importante conhecer as opções de mercado.

Entendi seu exemplo sobre arquitetos e pedreiros, Fernando, apesar de não ver uma relação direta com SOA.

[]s

Laércio Queiroz

http://laercioqueiroz.wordpress.com

[Former Member]

Grande Laércio,

É isso aí, os desafios são grandes para não acabar criando os chamados "filhos feios" que depois ninguém quer ser o pai.

[]'s

Isaías Barroso

Belo Horizonte