sexta-feira, 11 de dezembro de 2009
quarta-feira, 11 de novembro de 2009
terça-feira, 7 de julho de 2009
quarta-feira, 17 de junho de 2009
quarta-feira, 1 de abril de 2009
sexta-feira, 31 de outubro de 2008
Veja como se dar bem na onda da arquitetura orientada a serviços
Venho percebendo o quanto SOA está crescendo no mercado atualmente. Por este motivo começarei a postar aqui alguns artigos sobre esse assunto, segue o primeiro deles publicado na Info:
A cena se repete na maior parte das empresas. São dezenas de sistemas independentes operando ao mesmo tempo, e fica difícil fazer tudo conversar. É aí que entra o SOA (Service Oriented Architecture, conceito voltado para a integração), a arquitetura orientada a serviços. A idéia é integrar as tecnologias, num conceito análogo a peças de um jogo de Lego. Uma pesquisa do IDC aponta que 58% das empresas no mundo estão estudando o SOA, 18% colocaram o conceito em produção e 13% têm um projeto piloto. Somente 11% declararam que não estão fazendo nada a respeito.
Para que o SOA entre em prática, começa a surgir uma demanda por profissionais de TI. “Vários de nossos clientes têm nos pedido indicações nessa área”, afirma Fernando Lemos, diretor de consultoria e serviços profissionais da BEA Systems. “O salário desse profissional pode chegar ao patamar do de um gerente de tecnologia ou de projeto, algo entre 8 a 12 mil reais”, diz.
A GVT é uma das empresas que embarcaram no SOA, com um grupo de 16 profissionais. “Em telecom, precisamos de produtos cada vez mais inovadores e isso tem muito impacto nos sistemas. O SOA é uma maneira inteligente de controlar processos e reutilizar as coisas”, diz Alessandra Bomura, 36 anos, gerente de arquitetura e tecnologia da GVT. Na operadora desde a sua criação, há seis anos, Alessandra é graduada em Ciência da Computação pela Unesp e fez MBA de Gestão Empresarial pela FGV. Antes de aderir ao SOA, trabalhava com BI e sistemas de engenharia.
Alessandra espelha o perfil do profissional que tem se dado bem na área, aliando o conhecimento técnico e a formação de negócios. Além disso, em boa parte das empresas as equipes de SOA estão sendo formadas por pessoas que, como ela, trabalham na companhia há algum tempo. “É fundamental ter profissionais que conheçam bem os processos da empresa”, afirma Márcio Butuem, gerente sênior de consultoria de vendas da Oracle.
Outro exemplo é o engenheiro químico Marcelo Jaccoud Amaral, 43 anos, na Petrobras desde 1987. Há dois anos ele é um dos arquitetos tecnológicos da companhia, parte de um grupo de 30 profissionais. Além do conhecimento do negócio, trazia na bagagem o mestrado de Engenharia de Software pela PUC-Rio. “Fui me envolvendo com tecnologias de web e XML”, diz.
Como não há uma formação específica para atuar em SOA, o que conta é a combinação da experiência do profissional, a habilidade técnica e a visão do negócio. “Você tem de conhecer um pedacinho de cada sistema que está integrando, ser multidisciplinar”, diz Marcelo Galvão, gerente de plataforma de integração de negócio da TIM Brasil. Ele é formado em Engenharia da Computação pela Unicamp, com mestrado em Sistemas Distribuídos pela Universidade de Lyon. O grupo de SOA da TIM tem 35 pessoas. Já no Deutsche Bank, são oito analistas. “Investimos na nossa equipe, que já era próxima das áreas de negócio”, diz Keiji Sakai, CIO do Deutsche.
Para quem quer investir na área um dos caminhos são as certificações e eventos promovidos pelos fornecedores de soluções. “Estamos fazendo parcerias com universidades para desenvolvermos cursos na área, como extensões e MBAs”, afirma Marco Bravo, diretor de software da IBM.
O SOA também abre frentes de trabalho entre os fornecedores de TI. É o caso da IBM. Um de seus especialistas é o arquiteto de TI Mauro Ceccini, de 43 anos. Formado em Engenharia Eletrônica pela Poli/USP, ele presta consultoria a clientes da IBM na área de SOA, dentro de uma equipe de 12 profissionais.
Fonte: http://info.abril.com.br/professional/desenvolvimento/pronto-para-o-soa.shtml
Pronto para o SOA?
Débora Fortes, da INFO 25 de setembro de 2008A cena se repete na maior parte das empresas. São dezenas de sistemas independentes operando ao mesmo tempo, e fica difícil fazer tudo conversar. É aí que entra o SOA (Service Oriented Architecture, conceito voltado para a integração), a arquitetura orientada a serviços. A idéia é integrar as tecnologias, num conceito análogo a peças de um jogo de Lego. Uma pesquisa do IDC aponta que 58% das empresas no mundo estão estudando o SOA, 18% colocaram o conceito em produção e 13% têm um projeto piloto. Somente 11% declararam que não estão fazendo nada a respeito.
Para que o SOA entre em prática, começa a surgir uma demanda por profissionais de TI. “Vários de nossos clientes têm nos pedido indicações nessa área”, afirma Fernando Lemos, diretor de consultoria e serviços profissionais da BEA Systems. “O salário desse profissional pode chegar ao patamar do de um gerente de tecnologia ou de projeto, algo entre 8 a 12 mil reais”, diz.
A GVT é uma das empresas que embarcaram no SOA, com um grupo de 16 profissionais. “Em telecom, precisamos de produtos cada vez mais inovadores e isso tem muito impacto nos sistemas. O SOA é uma maneira inteligente de controlar processos e reutilizar as coisas”, diz Alessandra Bomura, 36 anos, gerente de arquitetura e tecnologia da GVT. Na operadora desde a sua criação, há seis anos, Alessandra é graduada em Ciência da Computação pela Unesp e fez MBA de Gestão Empresarial pela FGV. Antes de aderir ao SOA, trabalhava com BI e sistemas de engenharia.
Alessandra espelha o perfil do profissional que tem se dado bem na área, aliando o conhecimento técnico e a formação de negócios. Além disso, em boa parte das empresas as equipes de SOA estão sendo formadas por pessoas que, como ela, trabalham na companhia há algum tempo. “É fundamental ter profissionais que conheçam bem os processos da empresa”, afirma Márcio Butuem, gerente sênior de consultoria de vendas da Oracle.
Outro exemplo é o engenheiro químico Marcelo Jaccoud Amaral, 43 anos, na Petrobras desde 1987. Há dois anos ele é um dos arquitetos tecnológicos da companhia, parte de um grupo de 30 profissionais. Além do conhecimento do negócio, trazia na bagagem o mestrado de Engenharia de Software pela PUC-Rio. “Fui me envolvendo com tecnologias de web e XML”, diz.
Como não há uma formação específica para atuar em SOA, o que conta é a combinação da experiência do profissional, a habilidade técnica e a visão do negócio. “Você tem de conhecer um pedacinho de cada sistema que está integrando, ser multidisciplinar”, diz Marcelo Galvão, gerente de plataforma de integração de negócio da TIM Brasil. Ele é formado em Engenharia da Computação pela Unicamp, com mestrado em Sistemas Distribuídos pela Universidade de Lyon. O grupo de SOA da TIM tem 35 pessoas. Já no Deutsche Bank, são oito analistas. “Investimos na nossa equipe, que já era próxima das áreas de negócio”, diz Keiji Sakai, CIO do Deutsche.
Qualificação técnica
J2EE, Java, XML, .Net, Ajax, PHP e Python estão entre os termos que são bem-vindos no currículo do candidato a arquiteto SOA. Mas há uma safra de siglas em alta sintonia com a área de negócios. BPM (Business Process Management), ESB (Enterprise Service Bus), BRE (Business Rules Engine), Itil (Information Technology Infrastructure Library) são alguns exemplos.Para quem quer investir na área um dos caminhos são as certificações e eventos promovidos pelos fornecedores de soluções. “Estamos fazendo parcerias com universidades para desenvolvermos cursos na área, como extensões e MBAs”, afirma Marco Bravo, diretor de software da IBM.
O SOA também abre frentes de trabalho entre os fornecedores de TI. É o caso da IBM. Um de seus especialistas é o arquiteto de TI Mauro Ceccini, de 43 anos. Formado em Engenharia Eletrônica pela Poli/USP, ele presta consultoria a clientes da IBM na área de SOA, dentro de uma equipe de 12 profissionais.
Fonte: http://info.abril.com.br/professional/desenvolvimento/pronto-para-o-soa.shtml
terça-feira, 16 de setembro de 2008
Criatividade & Produtividade, cada caso tem sua hora
Ao se deparar com um problema no desenvolvimento de um sistema, qual a melhor e mais sustentável maneira para se encontrar uma solução? Buscar na literatura ou colocar os miolos para funcionar e desenvolver sua própria solução?
Olha só o que diz Leonardo Kenji:
Criatividade e Design Patterns September 15, 2008 1:16 pm
Ninguém pode negar que os Design Patterns, ou “padrões de projeto” ou “padrões de desenho”, formalizados no famoso livro do GoF (gang of four - a turma dos quatro, ou Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) foi uma mudança muito significativa em toda a indústria de software. A proposta era simples: uma vez estudadas diversas práticas de programação de “bons programadores”, eram identificadas algumas técnicas de design inteligentes que sempre apareciam mais ou menos de forma parecida para resolver problemas parecidos. Cada padrão era estudado e, voilá, junte vários destes e classifique-os e você tem um manual de “boas maneiras” para o desenvolvimento de software.
O benefício imediato, óbvio, é que ao se deparar com um problema de design, o desenvolvedor não precisa pensar numa solução do zero. Basta ir no compêndio de design patterns e procurar qual design resolve que tipo de problema.
Outro benefício indireto, mas igualmente importante, é trazer uma série de nomes para determinadas estruturas mentais, que facilitam a comunicação entre desenvolvedores. Ninguém precisa ficar explicando o que é um singleton se todo mundo já sabe o que é. Ganha-se tempo e leva-se a discussão um nível acima. E daí você pode ter ferramentas que automatizam a geração destes códigos, discussões acerca das vantagens e desvantagens de cada pattern, e etc.
Hoje em dia, existem patterns para praticamente todas as áreas específicas do desenvolvimento de software. É uma forma de reuso do conhecimento. Mas como tudo na vida, nem tudo é perfeito. Alguns anos atrás, eu estava conversando com um economista e falando dessa coisa de design patterns, e o cara mostrou uma cara de espanto, e falou: “que engraçado… em algumas situações na economia, pedimos para o aluno nunca procurar as soluções prontas, mas sempre tentar encontrar a solução por ele mesmo primeiro, para só depois recorrer à literatura… assim incentivamos a criatividade dos alunos e forçamos eles a pensarem…” Pode parecer improdutivo, e de fato, na engenharia de software, é uma bela vantagem ter na manga uma série de soluções prontas que “funcionam comprovadamente” e não perder tempo reinventando a roda.
Mas do ponto de vista criativo, assumir que os design patterns estão sempre certos, ou que são sempre a solução, também é uma faca de dois legumes. A postura do inovador deve ser sempre questionadora.
Haveria maneira melhor de resolver este problema? Este design pattern é realmente o mais adequado para a minha demanda? Quais são os fatores que poderiam levar este design a uma possível desvantagem? Quais tipos de problema poderiam advir do uso desta solução?
Se seu negócio é prazo, ficar pensando demais é perder tempo. Mas se seu negócio é inovar e criar soluções que sejam vantajosas diante do que é praticado em toda a indústria, nem sempre seguir o que existe pode ser a vantagem. E no fim das contas, espírito crítico nunca faz mal a ninguém.
Olha só o que diz Leonardo Kenji:
Criatividade e Design Patterns September 15, 2008 1:16 pm
Ninguém pode negar que os Design Patterns, ou “padrões de projeto” ou “padrões de desenho”, formalizados no famoso livro do GoF (gang of four - a turma dos quatro, ou Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) foi uma mudança muito significativa em toda a indústria de software. A proposta era simples: uma vez estudadas diversas práticas de programação de “bons programadores”, eram identificadas algumas técnicas de design inteligentes que sempre apareciam mais ou menos de forma parecida para resolver problemas parecidos. Cada padrão era estudado e, voilá, junte vários destes e classifique-os e você tem um manual de “boas maneiras” para o desenvolvimento de software.
O benefício imediato, óbvio, é que ao se deparar com um problema de design, o desenvolvedor não precisa pensar numa solução do zero. Basta ir no compêndio de design patterns e procurar qual design resolve que tipo de problema.
Outro benefício indireto, mas igualmente importante, é trazer uma série de nomes para determinadas estruturas mentais, que facilitam a comunicação entre desenvolvedores. Ninguém precisa ficar explicando o que é um singleton se todo mundo já sabe o que é. Ganha-se tempo e leva-se a discussão um nível acima. E daí você pode ter ferramentas que automatizam a geração destes códigos, discussões acerca das vantagens e desvantagens de cada pattern, e etc.
Hoje em dia, existem patterns para praticamente todas as áreas específicas do desenvolvimento de software. É uma forma de reuso do conhecimento. Mas como tudo na vida, nem tudo é perfeito. Alguns anos atrás, eu estava conversando com um economista e falando dessa coisa de design patterns, e o cara mostrou uma cara de espanto, e falou: “que engraçado… em algumas situações na economia, pedimos para o aluno nunca procurar as soluções prontas, mas sempre tentar encontrar a solução por ele mesmo primeiro, para só depois recorrer à literatura… assim incentivamos a criatividade dos alunos e forçamos eles a pensarem…” Pode parecer improdutivo, e de fato, na engenharia de software, é uma bela vantagem ter na manga uma série de soluções prontas que “funcionam comprovadamente” e não perder tempo reinventando a roda.
Mas do ponto de vista criativo, assumir que os design patterns estão sempre certos, ou que são sempre a solução, também é uma faca de dois legumes. A postura do inovador deve ser sempre questionadora.
Haveria maneira melhor de resolver este problema? Este design pattern é realmente o mais adequado para a minha demanda? Quais são os fatores que poderiam levar este design a uma possível desvantagem? Quais tipos de problema poderiam advir do uso desta solução?
Se seu negócio é prazo, ficar pensando demais é perder tempo. Mas se seu negócio é inovar e criar soluções que sejam vantajosas diante do que é praticado em toda a indústria, nem sempre seguir o que existe pode ser a vantagem. E no fim das contas, espírito crítico nunca faz mal a ninguém.
--
Assinar:
Postagens (Atom)