IBM compra a Sterling Commerce

A "Big Blue" comprou mais uma empresa... Dessa vez foi a Sterling Commerce, empresa irlandesa do grupo AT&T por US$ 1,4 Bilhão focada em integração, B2B, EDI e SOA. Após a confirmação da compra (visto que ainda está sujeita a aprovação dos órgãos reguladores), os produtos da Sterling irão fazer parte do portifólio das soluções IBM WebSphere. Uma outra parte da estratégia com a aquisição da Sterling  por parte da IBM é prover um número maior de soluções como serviço (SaaS).

Dos produtos que eu conheço da Sterling, posso destacar o C:D (Connect Direct), software  (de ótima qualidade) para transferência de arquivos controlada que substitui o tradicional e problemático FTP, muito utilizado para a integração de arquivos entre parceiros.

Segue pequeno press-release do site da Sterling:

http://www.sterlingcommerce.com/about/about-us/IBM+Agrees+to+Acquire+Sterling+Commerce+from+ATT+for+1.4+Billion.htm

Progress Software compra a Savvion

Sempre que me perguntam sobre a qualificação dos fornecedores que estão nos institutos de pesquisa como o Forrester e o Gartner eu alerto sobre algo que em muitos casos passa despercebido pelas pessoas: A EMPRESA. Isto porque empresas de nicho, cedo ou tarde são compradas por grandes fornecedores (ou em casos piores fecham). Aqui está mais um exemplo. A Savvion, que tem uma excelente suíte de BPM agora é da Progress. Abaixo segue o link do press release:

http://web.progress.com/en/inthenews/progress-software-co-01112010.html

Sinceramente, não conheço a fundo a política da Progress quanto à aquisição de empresas, ou seja, se ela irá manter o produto ou criar um novo. Da experiência que eu tenho, ela manteve a linha de produtos totalmente separada (DataDirect). Um bom sinal para as pessoas que utilizam a suíte da Savvion é que a Progress não possuía produtos para BPM, tendo apenas produtos para SOA, o que quer dizer que é mais provável que o produto passe por um reposicionamento de marcas do que de tecnologia (com um merge de produtos)... Mas tudo é suposição neste momento! (apesar de que se você entrar no site da Progress você já verá o produto "Progress Savvion BusinessManager").

Segundo o Gartner (Magic Quadrant for Business Process Management Suites - 2009) a Savvion tem os seguintes pontes fortes e fracos (A Progress não aparece neste relatório):

Strengths

• Savvion BusinessManager 7.5 is one of the most-mature BPMS products. Its ability to handle high-volume workflows, requiring tight coordination of people and systems, has contributed to Savvion's growing success in the BPO market, in addition to direct sales to enterprises.
• This product has an open, multitiered, service-oriented and standards-based architecture, with well-documented application programming interfaces. Thus, it is easy to integrate with software infrastructures and application development tools, as well as to embed for partners.
• Visualization of many process aspects is innovative and easy to use for business professionals. Examples include its modeler, design time repository, dashboards and reports, and a new graphic for analysis of process execution paths.
• Business Expert supports real-time analysis of in-flight processes and dynamically suggests changes to process conditions and rules to keep running processes optimal. It has strong reporting capabilities. Users can dynamically add new process performance metrics in the runtime environment to gain insight into current execution data.

Cautions

• Savvion's current release reflects the tactical needs of a few of its best customers more than its own, market-driven innovations. Two examples (which we find inconsistent with the requirements of this market) are a new tabular method of data entry for process activities and new support for project management (which is somewhat competitive with Microsoft Project). Customers should watch for developments that evolve in directions inconsistent with mainstream market demand.
• Beyond the U.S., Savvion serves its customers primarily through indirect sales channels, partners and resellers. (Savvion has a small direct presence in Europe and a larger direct and indirect presence in India.)
• As Savvion expands its sales through more indirect channels, such as system integrators and consulting partners, business process outsourcers, and OEM relationships, enterprises should watch for any impact to support and product release plans from resources being spread too thin.

IBM compra a Lombardi Software

A IBM anunciou hoje a compra da Lombardi Software, uma das empresas líderes no Gartner em soluções de BPMS (Business Process Management System). Abaixo segue o link do press release. Agora vamos aguardar os próximos passos, que deve ser a integração dos produtos da Lombardi com a atual linha de software IBM WebSphere.

http://www-03.ibm.com/press/us/en/pressrelease/28890.wss

Segundo o Gartner (Magic Quadrant for Business Process Management Suites - 2008 2009) a Lombardi tem os seguintes pontes fortes e fracos:

Strengths (Lombardi)

• Lombardi has keen insights into the functions required by each user role involved in the business process life cycle. Lombardi consistently
• produces highly intuitive software that addresses each role's perspective, while providing an integrated round-trip user experience.
• Because Teamworks is easy for business analysts to use, it is well-suited to continuous process improvement programs where empowering business users or business analysts is key.
• The business process executes from the process model, thereby simplifying dynamic changes to in-flight business processes at runtime and preventing design-time artifacts from getting out-of-sync with implementation artifacts.
• Lombardi customer references are among the most advanced in BPM maturity. They demonstrate broad adoption of BPM across an
• organization that yield transformative business results.
• Blueprint appeals to business managers and strategic planners who seek a tool for high-level process diagramming and knowledge capture. It complements the Teamworks process models and is available via low-cost SaaS.

Cautions (Lombardi)

• Customers with smaller deal sizes may find it challenging to command Lombardi's attention.
• Lombardi's support for case management processes is not as strong as some of its competitors.
• Lombardi Teamworks does not offer multitenant SaaS, which some ISVs may need for highly scalable cloud services or enterprises may want for private cloud services.
• Lombardi does not invest in process templates or frameworks or recruit partners to build solution accelerators. These factors may be
• an obstacle for organizations looking for specific process-based applications.

Baseado nas informações acima, grande parte dos pontos fracos da Lombardi devem diminuir, visto a estratégia da IBM, porem é fato (no meu ponto de vista) que estas "fraquezas" devem ser substituídas pelas fraquesas atuais da IBM, conforme abaixo:

Cautions  (IBM)

• IBM doesn't have one BPMS product; rather, it fulfills its BPM strategy through federated interoperability across two basic offerings augmented by extended offerings. IBM has made significant progress with integration across the two basic offerings, but has not yet achieved full integration.
• The broader software division’s acquisition strategy will continue to augment IBM's BPMS vision and product road map. Customers will need to monitor the integration of new technologies.
• Individual products in the suite have strong and rich functionality. However, in combination, the permutations of configuration possibilities are overwhelming. Customers usually require help from a service provider.
• WebSphere Dynamic BPMS edition has few references.

Ps: Usei como referência o relatório do Gartner de fevereiro/2009.

Baixo Acoplamento (Loose Coupling) de Serviços

A falta de dependência entre os serviços (consumer e provider) é muito importante para um projeto de arquitetura SOA, por isso é muito importe que os serviços tenham um baixo acoplamento (Loose Coupling).

O baixo acoplamento é divido em 5 dimensões, conforme a seguir:

• Localização: Consumidores (service consumers) não devem ser dependentes da localização do serviço.  Por isso os serviços, para um máximo desacoplamento na dimensão da localização devem ser expostos em um ESB.

• Plataforma: Consumidores e Provedores (services consumers e providers) devem ser independentes de plataforma, por isso o uso de padrões aberto é importantíssimo nesta dimensão, fazendo com que plataformas diferentes como J2EE e .NET conversem uma com a outra sem saberem que estas estão interagindo com outra plataforma. 

• Linguagem: Nesta dimensão a preocupação é a mesma da dimensão plataforma. Por exemplo, o uso de Java object streams serializados pode ser altamente eficaz para certos consumidores e provedores, mas pode limitar o reuso porque algum ponto da arquitetura SOA evoluiu. O uso de formatos e protocolos abertos dentro da linguagem de programação é a melhor maneira de evitar o acoplamento. 

• Formato: Formatos proprietários ou feitos sob medida são utilizados por enumeras razões, mas introduzem uma dependência muito grande que se transforma em um obstáculo muito grande para uma arquitetura SOA flexível. Os formatos abertos, como SOAP, XML, etc. trazem o desacoplamento necessário para esta dimensão, por isso são altamente recomendados. Nem sempre é possível utilizar padrões de formatos abertos. Neste caso a utilização de um ESB expondo um formato proprietário como um formato aberto traz o desacoplamento necessário nesta dimensão. 

• Protocolo: Assim como os formatos, vários protocolos proprietários são utilizados. A solução para este dimensão dentro de uma arquitetura SOA é exatamente a mesma da dimensão formato, ou seja, a utilização de protocolos abertos, como SOAP over HTTP.
  

Camadas de Abstração

Há um grande número de frameworks que dividem a arquitetura em camadas de abstração. SOA traz um pequeno número de novas considerações e artefatos arquiteturais que devem ser adicionados aos frameworks existentes.

SOA é divido em 5 camadas de abstração:

• Camada Corporativa: Na camada corporativa são definidos os modelos de negócios da empresa (enterprise business model), como quais são seus principais processos baseados em seu objetivo e mercado.
  

• Camada de Processos: Na camada de processos, os processos do modelo de negócios são identificados. Cada processo é único para cada área funcional de negócio e pode ser composto por vários sub-processos. A camada de processos é muito importante dentro da arquitetura SOA, porque muitos processos podem ser modelados e executados como serviços. É comum a confusão entre as terminologias de “serviços” e “processos”. Processos são definidos uma única vez e usados dentro de um único contexto, já serviços também são definidos uma única vez, mas este pode ser reutilizado (reuso) em diferentes “processos”.
  

• Camada de Serviços: A camada de serviços é caracterizada por um número de serviços que realizam funções individuais de um negócio. Dentro da arquitetura SOA, esta camada fornece uma ponte entre as camadas de alto (camada corporativa e de processos) e baixo nível (camada de componentes e objetos). Usualmente, é nesta camada que as funções críticas necessárias para o negócio são identificadas, visto que é nela que usualmente são identificadas e expostas as funções para suportar o negócio.

• Camada de Componentes: Na camada de componentes são identificados e caracterizados os componentes que podem ser mapeados como serviços. Normalmente através de técnicas “bottom-up” (análise das aplicações e identificação de funções que podem ser serviços, por terem um potencial de reaproveitamento em vários sistemas).
  

• Camada de Objetos: A camada de objetos, estão as classes, atributos e relacionamentos de um objeto. Na arquitetura SOA há um reaproveitamento dos conceitos de orientação a objeto, porem com o desacoplamento dos objetos, transformando em serviços reutilizáveis.

Tipo de processamento... Quais opções nós temos?

Quando falamos de integração de aplicações, independente da abordagem utilizada (EAI, ponto a ponto, SOA, ETL, etc. ) um ponto fundamental que deve estar na análise é o tipo de processamento que será utilizado. A itenção aqui não é falar se uma é certa ou não, até porque na minha visão todas são... Tudo depende do requisito para se escolher o tipo mais adequado. As opções são:

• Processamento Batch: Processos executados em “lotes”. Em geral, os processos batch são processados em um determinado período (semanalmente, diariamente, de 5 em 5 horas, etc.). Atualmente, o uso de processos batch é freqüente em sistemas onde a carga de dados se faz necessária. Este tipo de processamento deve ser assíncrono.
  

• Processamento On-Line: Processos executados a cada interação. A atualização dos dados do processo são efetivadas no momento em que ocorrem o fato correspondente, porem o tempo de resposta pode ser ”indeterminado”. Este tipo de processamento pode ser síncrono ou assíncrono.
  

• Processamento Real Time: Processos executados a cada interação. A atualização dos dados do processo são efetivadas no momento em que ocorrem o fato correspondente, porem o tempo de resposta deve ser “determinado” (finito). Este tipo de processamento deve ser síncrono.
  

• Processamento Síncrono: Processo onde o resultado obrigatoriamente deve ser enviado para o sistema que requisitou, em um determinado período (time out), mesmo no caso de uma falha. Os dois sistemas envolvidos devem estar no ar. Exemplo: Páginas Web/Conexão HTTP.
  

• Processamento Assíncrono: Processo onde o resultado não precisa (mas pode) ser enviado para o sistema que requisitou, mesmo no caso de uma falha. Caso um sistema não esteja no ar, este não interfere no funcionamento do outro (Connection Less). Exemplo: E-Mail.

SOA sem governança?

Para quem está (seriamente) estudando, implementando ou implantou os paradigmas da abordagem SOA dentro de uma empresa, sabe que não existe a opção “sem governança” e PONTO FINAL.

Vejam alguns dos principais problemas que acontecem (notem que eu nem utilizei a frase “problemas que podem acontecer”):

• O potencial não é totalmente utilizado;
• Desenvolvimento e implantação sem padrões;
• Serviços são criados sem controle;
• Serviços são duplicados;
• Serviços são criados, porém as aplicações não os chamam… “Continua da maneira antiga”;
• Serviços não são reutilizados.

Mas da para ter uma “governança mínima”?

Muitas vezes, pessoas responsáveis pela implantação de SOA dentro de uma empresa me dão o seguinte argumento: Não tenho budget e/ou tempo para a implantação da governança SOA mas não quero perder a oportunidade de começar a implantar os conceitos, ferramentas, etc. O que faço? Bem, geralmente eu tenho duas respostas, cada uma de acordo com o meu humor na hora em que eu acordei:

• Quando acordo irado com o mundo digo: Desista!  

• Quando acordo um pouco mais simpático: Implante o mínimo de governança, criando pelo menos padrões e um repositório de serviços (nada de planilha Excel hein!)... Mas não ache que com isso você tem governança SOA, você só está um pouco organizado e assim que você tiver a oportunidade inicie um projeto sério de governança SOA.

Tirando a brincadeira acima, a resposta final é SIM, da para iniciar um projeto com  uma "governança mínima". A opção que não existe é "não ter nada de governança". 

Mas atenção: Se iniciar com uma governança mínima, tenha consciência que será necessário evoluir na governança em um futuro próximo (principalmente com a evolução do uso da abordagem SOA dentro da empresa).

PS: Geralmente, quando a empresa não tem budget e/ou tempo para a implantação da governança é que ao querer implantar SOA a empresa se preocupou muito mais com a compra de produtos e não deu o foco adequado para serviços. Por isso deve-se sempre escutar uma consultoria (vejam post Adotando BPM e/ou SOA - Parte 6).

Fabricantes e ferramentas fazem diferença na implementação de BPM e SOA?

Na minha opinião, ferramentas são itens de tecnologia. BPM e SOA são muito mais do que isso... Essas abordagens utilizam tecnologias, mas não são só tecnologias, por isso insisto quando me referencio a estas utilizando o termo “abordagens”. As vezes falar isso parece confuso, principalmente para quem é de TI, mas esse é o fato.

A escolha de ferramental vai muito mais de encontro com a arquitetura tecnológica de uma empresa (obviamente atendendo todos os requisitos), adequação com os usuários, sua infra, condições que o fabricante faz, suporte, entre outros motivos. Independente do que uma ferramenta é melhor ou pior que a outra, o diferencial é a equipe que vai implantar a abordagem. Há casos de sucesso e insucesso de implementações em Oracle, IBM, Microsoft, Red Hat, etc.

Mas o que faz a diferença na escolha de um ferramental então? Abaixo seguem algumas perguntas que não devem ficar sem uma boa resposta.

1. Qual é o road-map da plataforma?
2. Qual é a situação financeira do fabricante?
3. Qual é o investimento em P&D?
4. Qual é o tamanho da empresa (Brasil e exterior)
5. Quantos anos a empresa está no mercado (Brasil e exterior)?
6. Qual é o posicionamento do fabricante nos institutos de pesquisa (afinal, se alguém já fez estudos sérios porque você vai contrariar...)?
7. Qual é a quantidade de parceiros de negócios?
8. Qual é a quantidade de profissionais certificados na tecnologia?
9. O fabricante possui braço de serviços?
10. Possui agenda de treinamentos oficiais?
11. Possui suporte técnico local do fabricante 24X7 (você não vai querer ficar ligando para a Índia, por mais que passe por um telefone local né...)?
12. Possui suporte técnico do parceiro de implementação?
13. Quais são os casos de sucesso e conseqüentemente a maturidade?
14. A suíte oferecida é compatível com minha infra-estrutura (pense no passado, presente e futuro, por exemplo, atualmente você só tem máquinas UNIX... mas será que não haverá mudanças no futuro...)?
15. A utilização de padrões abertos é ampla?

É muito importante que em todas as fases de seleção das ferramentas e conseqüentemente do fabricante estes requisitos sejam observados com muito carinho, além da óbvia questão financeira.

Observação 1: Obviamente, a maioria das perguntas acima devem ser desmembradas em várias outras perguntas e distribuídas nas RFIs, RFPs, POCs, demos, entre outros passos da seleção de acordo com a metodologia da sua empresa ou utilizada pela consultoria.

Observação 2: Apesar de eu ter falado que ferramentas são itens de tecnologia não quer dizer que a suíte não influencie. Algumas suítes, com toda a certeza irão facilitar ou não a implantação. Nada de levar ao pé da letra... Olhando as perguntas você verá que várias direcionam para suítes e fabricantes de mercado com boa capacidade de implantação.

Adoção de SOA nas empresas (EUA e Europa)

Esta é um pesquisa feita no final de 2008 sobre a adoção de SOA em empresas dos Estados Unidos e Europa (que está publicada no The Forrester Wave™: North American SOA Systems Integrators, Q2 2009). Nunca vi um estudo completo sobre a adoção de SOA em empresas no Brasil ou América Latina (não quer dizer que não tenha, mas os que eu vi são mais baseados em enquetes do que em estudos profissionais)... Mas pelo meu sentimento, conversa com fornecedores, clientes e colegas de trabalho, acho que por aqui não está muito diferente.

Adoption Of SOA By North American And European Enterprises.

Fonte: Forrester, www.forrester.com

Most Distinguished Achievement Latin America 2009

Um pouquinho de auto-propaganda não faz mal a ninguém né...rs

Bem, aconteceu no final de outubro deste ano o evento mundial da IBM para a brand "Information Management" denominado IOD (Information On Demand). A Escala Informática foi a ganhadora do prêmio "Most Distinguished Achievement Latin America 2009". Para entender um pouco da importância deste prêmio, nesta brand de software estão alguns dos principais produtos da IBM, como: Cognos, Informix, DB2, InfoSphere DataStage, FileNet entre vários outos.

https://www-304.ibm.com/events/wwe/iod/iodbpawards09.nsf/$StaticContent/Winners