domingo, 30 de setembro de 2007

Papéis em SOA - Identificando Serviços

No post anterior - "Desenvolvimento de Software e SOA"- , foi abordada a importância da utilização de métodos, como SOMA, na identificação de serviços de negócio.

O objetivo deste post é exercitar os desafios do desenvolvimento de software, em uma SOA, quanto aos aspectos de comunicação, estabelecimento de responsabilidades e inter-relacionamentos entre papéis, com foco em identificação de Serviços de Negócio.

O relacionamento entre os diferentes papéis dentro de SOA é fator fundamental para que Processos e Serviços de Negócio sejam identificados, elaborados e construídos utilizando-se de forma sábia os recursos do projeto. Uma mesma solução pode ser atingida de formas diferentes. Mas se puder ser otimizada, promovendo reuso e definindo corretamente os Serviços de Negócio, o sucesso da solução de um projeto refletirá na empresa dentro de outros projetos.

Para não perder o foco - da identificação de serviços - serão explorados apenas aqueles papéis cujas responsabilidades mais se aproximam das atividades de modelagem de negócio, levantamento de requisitos e definição de serviços.

Definição e Responsabilidades
A tabela abaixo apresenta as definições e responsabilidades dos principais papéis, no que se refere a Identificação de Serviços de Negócio, no contexto de uma SOA.

Papel

Definição

Responsabilidade

Cliente

Interessado maior na solução, dono do processo.

Expor necessidades do negócio, gerenciar o processo de negócio.

Analista de Negócio

Profissional de TI ou de área de Negócio que atua como a “ponte” entre cliente e TI.

Entender as necessidades do negócio, auxiliar na modelagem do negócio (desenho, simulação, otimização).

Analista de Requisitos

Profissional de TI que realiza o levantamento dos requisitos de software.

Entender as necessidades do negócio e como estas se traduzem em requisitos de software (funcionais e não-funcionais), procurando identificar serviços em potencial.

Arquiteto de Solução

Arquiteto com foco em integração de aplicações e identificação de serviços.

Entender as necessidades do negócio quanto a integração de soluções, reutilização de serviços, procurando identificar os serviços candidatos.

Arquiteto de Software

Arquiteto com foco em design de aplicações e de serviços.

Entender os requisitos de software e de integração, procurando elaborar o design de aplicações de forma a viabilizar serviços de aplicação e facilitar a composição de destes em serviços de negócio.


SOA - Papéis x Responsabilidades


Há outros papéis muito importantes dentro da construção de projetos focados em SOA. Alguns papéis como Gerente de Projetos, Desenvolvedor e Testador são cruciais para qualquer projeto de TI. Também poderíamos explorar papéis novos, como um Administrador de Serviços. Contudo, o foco deste post está na identificação das necessidades do negócio do cliente, no levantamento de requisitos e no mapeamento destas necessidades e requisitos em Serviços e Processos de Negócio.

Fluxo de Comunicação
O fluxo de comunicação entre os papéis apresentados anteriormente é mostrado na figura abaixo.
As principais trocas de informação entre estes papéis são representadas pelas setas. Certamente, algumas interações não apresentadas aqui podem ocorrer. Este fluxo procura ressaltar aquelas comunicações mais relevantes na Identificação de Serviços em uma SOA.

Fluxo de comunicação
  • Cliente e Analista de Negócios: O Cliente, normalmente, inicia a conversação com um Analista de Negócios. O Cliente expõe seus problemas e necessidades de negócio. O Analista de Negócios precisa ter habilidades de ouvir, interpretar, questionar, conduzir a conversa, auxiliar o Cliente na elaboração do problema, colocar-se na posição do Cliente e identificar oportunidades de Negócio não vislumbradas pelo Cliente.
  • Analista de Negócios e Analista de Requisitos: Após o entendimento das necessidades de negócio do Cliente, o Analista de Negócios precisa interagir com o Analista de Requisitos. Serão repassados ao Analista de Requisitos as necessidades de negócio, os critérios e limitações de regras de negócio. O Analista de Requisitos, então, inicia seu trabalho de levantamento de requisitos funcionais para atender ao negócio.
  • Analista de Requisitos e Cliente: Após ter um entendimento inicial do problema do Cliente e dos principais requisitos de negócios repassados pelo Analista de Negócio, o Analista de Requisitos inicia sua interação diretamente com o Cliente para coletar informações mais específicas. Os requisitos funcionais são refinados e começa a tomar corpo uma visão de sistema para o projeto.
  • Analista de Negócios e Arquiteto de Solução: O Analisa de Negócio necessita interagir com o Arquiteto de Solução a fim de que oportunidades de reuso de serviços sejam identificadas. Também são importantes as informações de negócio que demandarão trabalhos de integração de sistemas. O Arquiteto de Solução inicia seu trabalho de definição das arquiteturas candidatas.
  • Analista de Requisitos e Arquiteto de Solução: O Analista de Requisitos precisa interagir constantemente com o Arquiteto de Solução, principalmente, no início da definição de escopo e visão do projeto, para a definição dos requisitos não-funcionais do projeto. É muito importante nesta fase que os potenciais reusos de serviços e elaboração de novos serviços sejam identificados.
  • Arquiteto de Solução e Arquiteto de Software: Dentro do projeto, é muito importante que as figuras do Arquiteto de Solução e de Software mantenham uma comunicação estreita. O trabalho do Arquiteto de Software deve permitir que os serviços candidatos identificados pelo Arquiteto de Solução possam ser realizados pelos sistemas das camadas de aplicação e de componentes. O Arquiteto de Software deve ter discernimento para elaborar designs flexíveis para as aplicações e propor soluções adequadas para adaptar as aplicações legadas a fim de que estas possam ter o melhor aproveitamento de sua vida útil dentro da plataforma de integração da empesa.
  • Arquiteto de Software e Analista de Requisitos: Uma vez que o Analista de Requisitos e o Arquiteto de Software são os "mais próximos" da solução de software, estes precisam ter um grau alto de relacionamento. O Arquiteto de Software, assim como o Arquiteto de Solução, participam ativamente da definição de requisitos não-funcionais da solução.

Pensamentos Finais
O fluxo de comunicação apresentado considera que os papéis serão executados por diferentes pessoas dentro do processo. Todavia, é possível que uma mesma pessoa exerça mais de um papel. Isto seria compreensível para os papéis de Analista de Negócios e Analista de Requisitos, ou Arquiteto de Solução e Arquiteto de Software. Por um lado, o acúmulo de papéis pode acrescentar riscos dentro de um projeto e comprometer a qualidade final do trabalho. Por outro lado, a divisão excessiva de papéis entre pessoas diferentes pode apresentar dificuldades de comunicação. Foi ponderando os benefícios e as dificuldades que apresentei tal configuração.

Links de referência:
New Techniques for Requirement Management
Requiremens Process for SOA Projects
An Introduction to SOA Solution Scenarios
Create the Ideal SOA Team
SOA Project Planning Aspects

quinta-feira, 27 de setembro de 2007

Desenvolvimento de Software e SOA

O desenvolvimento de software é um trabalho complexo. Esta complexidade é evidenciada nas dificuldades enfrentadas pelos projetos de software. Para contornar estas dificuldades, as pesquisas em engenharia de software geraram, ao longo dos anos, várias técnicas e metodologias de desenvolvimento visando tornar este trabalho mais simples. Evoluções partiram da programação estruturada, passando pela programação orientada a objetos, dirigida a componentes e, enfim, orientada a serviços. Estas evoluções tiveram, em comum, o objetivo de simplificar, reutilizar e utilizar-se de abstrações para tornar a unidade fundamental do software mais próxima da linguagem natural.

Níveis de Abstração
Segundo Grady Booch, os fundamentos de engenharia como abstrações e separação de interesses são sempre válidos. E há oportunidades reais para elevar o nível de abstração novamente. SOA introduz dois níveis de abstração: Serviços de Negócio e Processos de Negócio Corporativos. Serviços de Negócio Corporativos representam as capacidades de TI que estão alinhadas com as funções de negócio da empresa. Processos de Negócio definem o funcionamento geral do negócio da empresa, normalmente realizando orquestramento de Serviços de Negócio.

De acordo com o Gartner, SOA deslocará o foco do desenvolvimento das funções de software para funções de negócio, transformando software instalado de um inibidor a facilitador de mudanças rápidas no negócio. SOA tornar-se-á o framework dominante para criar e entregar software, movendo o valor do software empacotado para serviços de subscrição, e de suites monolíticas para aplicações compostas. A forma de pensar (abstrair) o software é novamente mudada.

Levantamento de Requisitos
Dentre as dificuldades do desenvolvimento de software, o levantamento de requisitos é freqüentemente apontado como um dos “vilões” responsáveis pelas falhas nos projetos de TI. São freqüentes os projetos que estouram o budget e/ou o prazo devido a requisitos incorretos, não levantados ou que sofreram mudanças. Segundo o Chaos Report, os três principais fatores que contribuem para dificuldades em projeto de software representam mais de 36% do total e estão relacionados à engenharia de requisitos. A tabela abaixo apresenta o resultado do Chaos Report para os fatores de dificuldades em projetos de TI.

Fatores de Dificuldade em Projetos de TI. [Fonte: Chaos Report]

Apesar da "defasagem" deste relatório (data de 1994), o que se percebe é que as dificuldades relacionadas a entender a diferença entre o que o usuário quer e o que ele precisa ainda existem. Por outro lado, muitos esforços foram e continuam sendo empregados para melhorar esta questão. O avanço da Engenharia de Requisitos, aumento de maturidade no uso de processos incrementais e uma maior "aceitação" quanto à natureza mutante dos requisitos têm contribuído.

Com a disseminação de SOA, o foco em desenvolvimento de serviços que apóiem o negócio faz ressaltar a importância do levantamento de requisitos. O uso de novas tecnologias e metodologias por si só não eliminarão os problemas. Faz-se necessário rever alguns artefatos, redefinir papéis e a interação entre eles, assim como definir ou redefinir processos.

SOMA
Recentemente, algumas metodologias têm ganhado espaço e amadurecido. É o caso da SOMA (Service-Oriented Modeling and Architecture) que aborda técnicas para identificar, especificar e realizar Serviços.
Método SOMA

Identificação
Consiste da combinação de técnicas top-down, bottom-up e middle-out, para elencar Serviços Candidatos.
  • Na visão top-down, realiza-se a decomposição de domínio de negócio em suas áreas funcionais, processos, subprocessos e casos-de-uso de negócio. Estes casos-de-uso de negócio são fortes candidatos a Serviços de Negócio.
  • Na visão bottom-up, os sistemas existentes são analisados e selecionados como candidatos viáveis a prover soluções de baixo custo para implementação das funcionalidades de Serviço que suportam os Processos de Negócio.
  • Na visão middle-out, adota-se uma estratégia de identificar os Serviços candidatos que atendem a objetivos de negócio, associando-se métricas e KPIs aos Serviços. O principal objetivo desta visão é garantir o alinhamento com o negócio.
Especificação
Nesta fase ocorre a classificação dos Serviços, definindo características de hierarquia e composição. Avalia-se a interdependência entre serviços, mantendo a preocupação com sua granularidade. Especifica-se os detalhes dos componentes que implementam os Serviços.

Realização
Neste ponto decide-se sobre que sistema irá prover Serviços especificados, e que novos Serviços serão construídos. Também são exploradas as decisões quanto a segurança, gerenciamento e monitoração de Serviços.

(Um exemplo prático de aplicação do método SOMA pode ser visto no post de outro colega blogueiro.)

Pensamentos Finais
A realização de promessas por reuso, agilidade e time-to-market atualmente são esperadas pela SOA. Realizar estes benefícios, porém, irá requerer maior investimento em software, infra-estrutrua, habilidades (skills) e mudança de processos.

terça-feira, 18 de setembro de 2007

Certificação SOA

Segue um material de referência e dicas para estudar para os testes de Certificação SOA da IBM.
São duas certificações:
  • IBM Certified SOA Associate - valida a habilidade do candidato em articular o valor de SOA quanto a aspectos técnicos e de negócio. Para obter esta certificação, deve-se realizar o Test 664. São 54 questões de múltipla escolha a serem realizadas em 90 minutos e o score mínimo de 67%.
  • IBM Certified SOA Solution Designer - validada a habilidade do candidato em traduzir os requisitos do cliente de flexibilidade e agilidade do processo de negócio em uma solução de software com foco em serviço usando princípios de SOA. Para obter esta certificação, deve-se realizar o Test 665. São 59 questões de múltipla escolha a serem realizadas em 90 minutos e o score mínimo de 66%.
Links
Site para Certificações IBM SOA:
http://www-03.ibm.com/certify/certs/soa_index.shtml

IBM's SOA Foundation
: http://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/

Artigo com dicas de preparação para a certificação
: http://www.ibm.com/developerworks/webservices/edu/ws-dw-ws-soacert1.html

Dicas
A certificação SOA Associate é mais teórica. Foca em conceitos, boas práticas e padrões. É importante assimilar a visão SOA de alinhar TI ao negócio. Quando SOA se aplica e quando não.

A certificação SOA Solution Designer é mais complexa. Nela são exigidos os conhecimentos explorados na anterior, mas com uma visão de aplicação destes conhecimentos na solução de problemas com foco em SOA. São várias questões com cenários de problema onde SOA pode ou não se aplicar. Além disso, é fundamental o conhecimento da "solução" SOA da IBM. Esta certificação, diferente da anterior, explora o uso das ferramentas da IBM que apóia sua visão de SOA (ver IBM's SOA Foundation e IBM SOA Reference Architecture). Muito importante conhecer bem os padrões de tecnologia relacionadas a SOA: W3C, OASIS, WS*. São exploradas também questões de granularidade de serviços e governança.

Boa Sorte!

terça-feira, 11 de setembro de 2007

WTC 11/9 - IBM Forum Brasil

Ok. Foi intencional o título. Era pra chamar atenção mesmo! (aprendi isto em outro blog)

Mas tirando a coincidência do local e data, não se trata de choques ou explosões. Pelo menos, não fisicamente.

Estou usando este espaço para passar um pouco da minha visão sobre este evento, o IBM FORUM Brasil. Diga-se de passagem, um GRANDE evento. Considerando que é realizado por uma única empresa, mesmo do porte da IBM, é impressionante a quantidade de pessoas e temas. Nesta primeira edição do Forum no Brasil, a Big Blue, comemorando seus 90 anos no país, juntou seus funcionários, parceiros e clientes num evento cuja palavra de ordem é Inovação.
Aliás, Inovação foi repetida várias vezes e frisada pela jornalista Fabiana Scaranzi, condutora das sessões plenárias.

Bom, vamos aos resumos dos principais assuntos que pude acompanhar. Mas, antes, é importante esclarecer que o intuito aqui é despertar a atenção para assuntos interessantes, inovadores, e não nos produtos da IBM. Mas é inevitável falar deste evento sem citar tais produtos.

GIO (Global Innovation Outlook)
Eu não conhecia esta iniciativa. Trata-se de uma reunião de líderes de opinião, do mundo, que discutem sobre oportunidades emergentes da intersecção da tecnologia, dos negócios e da sociedade.
A última edição, chamada de GIO 2.0, reuniu 248 líderes de opinião de 36 países e regiões que discutiram sobre as três áreas de foco:

  • Futuro da Empresa: o que muda com a era do conhecimento?
  • Transporte: a mobilidade será facilitada? e os grandes centros?
  • Ambiente: quais áreas de sustentabilidade ambiental contêm a maior promessa para a inovação dos setores público e privado?
Cada uma abre espaço para oportunidades de Inovação.

Freaknomics
O co-autor do livro "Freaknomics - o lado oculto e inesperado de tudo que nos afeta", Stephen J. Dubner, jornalista colaborador do The New York Times apresentou, baseado nas histórias do livro, uma visão diferente, inovadora, de enxergar as questões econômicas. A idéia básica passada é que "... a economia é mola propulsora das atitudes e dos relacionamentos humanos.". Tudo depende de um incentivo, e incentivos têm relação direta com a inovação.
Lembrei-me de uma palestra sobre Empreendedorismo em que o palestrante frisou muito a importância da inovação, de enxergar os fatos de forma diferente, de questionar o óbvio, de se sobressair, de evitar a mesmice.
Nota: não li este livro, mas fiquei empolgado para ler!

Após estas introduções de Inovação, fomos às palestras.

Palestras
Dynamic Warehousing
Ou, segundo os jargões: Information on Demand.
O objetivo principal é "integrar" os mundos Transacional e OLAP. Utilizar dados analíticos (modelos preditivos) em sistemas transacionais.
Na visão SOA, pode-se dizer que é um BI orientado a serviço.
Com relação ao BI tradicional, ao trabalhar com a informação, a intenção é mudar o foco do Analista de BI para o Consumidor de Serviços.
Ex.: Supermercado. Diferente de realizar análises para encontrar quais produtos são comumente adquiridos em conjunto pelos clientes (caso clássico das Fraldas e Cervejas), a fim de montar as pratileiras com estes produtos próximos, a idéia é oferecer produtos ao cliente no momento do pagamento, "analisando" em real-time que outros produtos relacionados ele poderia, potencialmente, adquirir.
É uma visão mais dinâmica, em tempo-real. Montar tal solução expondo serviços gera oportunidades mais flexíveis de negócio, além de promover uso mais efetivo da solução de BI da empresa. E, certamente, requer uma solução (soft+hard) voltada especificamente para tratar estas necessidades. (Nem tudo são flores)

DataPower
De forma resumida, e até simplista, DataPower é o nome de uma solução da IBM para resolver, via hardware, problemas de desempenho de software.
Especificamente a solução DataPower SOA Appliance, auxilia em resolver:

  • Desempenho em transformação de mensagens XML (além de outros formatos)
  • Processamento de alto volume de mensagens XML
  • Segurança (triple A, criptografia, segurança contra ataques, etc)
Tudo isto via hardware. Estes hardwares são dividos em três categorias:

  • Verde: acelerador de XML (transformação, parsing, etc)
  • Amarelo: segurança
  • Azul: similar a um ESB, um ESB light
A solução Amarelo inclui as features da Verde, e a Azul inclui as features das outras duas.

Governança SOA
Há muita discussão no evento sobre Governança SOA, ciclo-de-vida de Serviços, etc
É possível perceber que, apesar de haver soluções sofisticadas para tratar destes assuntos, elas, aparentemente, ainda não se conversam totalmente. Isoladamente, já estão bem maduras, mas alguns pontos de intersecção entre estas soluções ainda estão soltos.
Assim, citando algumas das ferramentas:

  • RAM - Rational Asset Manager: ferramenta que apóia o cliclo de desenvolvimento, promovendo o reuso de ativos digitais; foco no build;
  • WSRR - WebSphere Service Registry and Repository: ferramenta usada para gerenciar o ciclo-de-vida de um Serviço; foco no runtime;
  • CCMDB: base de Itens de Configuração; suporte para ITIL;
  • ITCAM for SOA: ferramenta que monitora os Serviços atualizando suas informações nas bases do WSRR e CCMDB.
É possível pesquisar/incluir Ativos Digitais na base corporativa durante o ciclo de desenvolvimento, promovendo assim o reuso de componentes e Serviços. É possível definir o ciclo-de-vida de Serviços e suas características (WSRR), é possível acompanhar o status destes Serviços em runtime (ITCAM for SOA + WSRR + CCMDB).
Mas, há menos que se empregue algum esforço (customização), parece ainda não ser possível rastrear impactos de outros Ativos (servidores, sistemas, etc) nos Serviços, mantendo todas estas soluções sincronizadas.

Perguntas sem uma resposta concreta:

  • Quais informações/artefatos que compõem um Serviço são registradas no RAM? E quais são registradas no WSRR? É necessário, realmente, ter estas duas ferramentas separadas?
  • Uma mudança em um servidor irá afetar a disponibilidade de quais Serviços?
  • A alteração de informação/status de um Serviço será refletida, automaticamente, no CCMDB?


developerWorks
O portal developerWorks reúne demos, trials, apresentações, etc sobre os produtos da IBM. Mas também contém uma quantidade enorme de artigos técnicos. Muitos destes artigos sequer citam produtos da IBM. São diversos canais como: fóruns, blogs, wikis, Second Life.
Considero de leitura obrigatória pra quem usa/depende de soluções de desenvolvimento da IBM. E mesmo pra quem não usa nada da IBM, há artigos excelentes sobre os mais diversos temas, como J2EE, SOA e Grid Computing.


Por enquanto é isso, mas o evento continua.