PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Reuso

  • [SOA # 5] – Processos

    Da mesma forma que SOA não requer nenhuma nova tecnologia, o mesmo vale quando tratamos de processos ou metodologias para gestão de programas e projetos. A corporação pode e deve reaproveitar os processos existentes, principalmente as práticas com benefícios comprovados.

    Mas algumas mudanças podem ser necessárias, visando atender principalmente os meta-requerimentos Agilidade, Flexibilidade e Simplicidade. Um processo burocrático ou resistente a mudanças, como aqueles baseados em modelos waterfall (cascata), é incompatível com tais requisitos. Por outro lado, processos muito “leves” como XP (eXtreme Programming) podem resultar em redundância e retrabalho por não fornecerem uma visão geral da empreitada e por carecerem de atividades gerenciais.

    O equilíbrio entre a agilidade de um processo e robustez de seus mecanismos de administração e controle, alvo de vários estudos e propostas, é crítico para a realização das promessas de uma iniciativa SOA. Por isso trata-se de uma definição que deve ocorrer no âmbito do Programa, logo em seus primeiros momentos.

    Para um processo ser considerado adequado para a implementação de uma SOA ele deve:

    • Promover Agilidade: o que não significa apenas ganho de produtividade dos desenvolvedores. Um processo ágil elimina barreiras e integra atividades visando aumento da qualidade de todos os produtos gerados;
    • Absorver Mudanças: e não combatê-las. Um Serviço em uma SOA deve assimilar e refletir as mudanças que ocorrem em um processo de negócio de forma quase imediata. É vital que o processo saiba tratar tal volatilidade;
    • Respeitar a Arquitetura: ou seja, garantir que todos os participantes de uma iniciativa SOA tenham uma visão do todo, da Arquitetura, seus padrões e princípios;
    • Incentivar o Reuso: valorizando todos os ativos existentes e aqueles produzidos no programa e facilitando sua reutilização e combinação com outros ativos;
    • Facilitar a Comunicação: entre todos os participantes do programa e respectivos projetos e destes com as áreas de negócio.

    ===============

    Gestão do Portfólio de Serviços

    Uma das responsabilidades mais críticas do Comitê Gestor SOA é a administração do portfólio de serviços. A garantia do alinhamento do programa com as estratégias da organização e da satisfação de seus requerimentos são realizadas através de uma correta gestão do portfólio de serviços. Existem no mercado várias ferramentas que apóiam tal atividade, normalmente direcionadas para o acompanhamento de vários projetos. Elas podem ser adaptadas para o gerenciamento de um programa SOA.

    Os idealizadores da ferramenta Balanced Scorecard, Robert Kaplan e David Norton, lançaram recentemente um novo conceito que pode agregar considerável valor à gestão de um programa SOA. É o Mapa Estratégico , que “é a representação visual da estratégia de uma empresa. Sua principal finalidade é demonstrar a Prontidão de determinado ativo intangível para atendimento dos processos internos críticos: gestão de operações, gestão de clientes, inovação e processos regulatórios e sociais. Ele se torna uma visão consolidada das quatro perspectivas do Balanced Scorecard (Financeira, do Cliente, dos Processos Internos e de Aprendizado e Crescimento). Os ativos intangíveis foram estruturados em 3 grandes grupos: Capital Humano, Capital Organizacional e Capital da Informação. De acordo com os estudos conduzidos pelos autores e parceiros ao redor do globo, para o chamado Capital da Informação, o grande objetivo das empresas é a ‘disponibilidade de sistemas de informação, de infra-estrutura e de aplicativos de gestão do conhecimento necessários para suportar a estratégia’” .

    A relativa simplicidade desta ferramenta e a clareza com a qual demonstra as estratégias corporativas e sua relação de dependência com ativos de TI, o Capital da Informação, a tornam bastante adequada para a gestão, em alto nível, do portfólio de serviços. Como um serviço em uma SOA é a representação direta de um processo ou atividade de negócio, a comunicação do comitê gestor SOA com as áreas de negócio é bastante facilitada pelos mapas estratégicos.

    No entanto, serão necessárias várias alterações no formato original da ferramenta. Os ativos de TI são apresentados na obra em 4 grandes grupos: Sistemas Transacionais, Aplicações Analíticas, Aplicações Transformacionais e Infra-Estrutura de Tecnologia. Tal classificação deve ser trocada pelos 4 tipos de serviços (Básicos, Intermediários, Processos e Públicos) mais o Frontend das Aplicações e a Infra-Estrutura tecnológica.

    Uma nova dimensão deve ser criada para indicar a relevância estratégica de determinado serviço. Esta alteração também deveria afetar o modelo original, de forma a possibilitar que sistemas transacionais ou analíticos também possam ser classificados como “Transformacionais”, ou seja, como sistemas que alteram drasticamente um ou mais processos de negócios.

    Outra mudança necessária é na escala de avaliação da prontidão dos ativos. O estudo original apresenta seis níveis de prontidão :

    1. OK. Ativo atende plenamente os requisitos do negócio
    2. Leves Melhorias são necessárias
    3. Novos desenvolvimentos a caminho
    4. Novos desenvolvimentos atrasados
    5. Grandes Melhorias necessárias
    6. Nova Aplicação necessária

    A nova escala deveria refletir o ciclo de vida dos serviços, o que a deixaria da seguinte forma :

    1. Publicado: em Produção;
    2. Classificado: alocado na arquitetura e agendado para publicação;
    3. Certificado: aprovado nos testes de qualidade. Atende todos os requisitos especificados no Contrato do Serviço;
    4. Submetido: em processo de Certificação;
    5. Em Desenvolvimento;
    6. Identificado / Especificado: serviço já foi identificado e modelado – encontra-se na fila para início de sua construção.

    Deve-se lembrar que a principal utilidade desta ferramenta é a comunicação com o corpo diretivo da empresa. Daí a relativa superficialidade da escala de avaliação do grau de prontidão dos serviços. No entanto nada impede que extensões sejam desenvolvidas de forma a enriquecer o relatório e municiar os processos de tomada de decisão do comitê gestor SOA. As alterações mais desejadas talvez sejam aquelas que propiciem:

    • Visibilidade dos prazos de transição entre as etapas do ciclo de vida dos serviços;
    • Opções de aquisição ou desenvolvimento do serviço (compra no mercado, desenvolvimento interno, desenvolvimento terceirizado ou utilização de ativo livre e aberto disponível na Internet); e
    • Estimativas de custos de cada serviço.

    >>>>>>>>>> SOA #6 – MDA (Model Driven Architecture)

    4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
    Springer (2002).
    5. “Gestão Estratégica de Ativos e Portfólios de Projetos de TI”, Paulo F. Vasconcellos
    Artigo publicado em Out/2004.
    6. “Mapas Estratégicos”, Robert S. Kaplan e David P. Norton
    Editora Campus / Elsevier (2004).

  • [SOA # 2] – Conceitos Básicos

    SOA não é e também não promove uma nova tecnologia. Também é equivocada sua apresentação como uma nova “metodologia”. Trata-se de um conceito ou, como colocado anteriormente, uma Estratégia de TI. A principal motivação para sua implementação é a realização do tão sonhado (e raramente concretizado) Alinhamento Estratégico de TI com o Negócio. Entende-se que tal alinhamento acontece de fato quando :

    • TI agrega real valor ao plano de negócios;
    • Não resiste às mudanças;
    • Combate a resistência às mudanças; e
    • É planejado.

    Os três primeiros itens da lista são traduzidos em considerável ganho de Agilidade. SOA promete a criação de uma estrutura que reproduz fielmente, em mapeamento um-para-um, os processos e atividades de negócios. Tamanha aproximação deve gerar uma arquitetura flexível, que favorece as mudanças. Mas os ganhos possibilitados pela implementação de uma Arquitetura Orientada a Serviços não ocorrem por acaso ou de forma pontual. Uma implementação SOA é uma iniciativa de longo prazo – é a execução de um bem elaborado Plano Estratégico.

    SOA é uma arquitetura de software. Uma arquitetura de software é “um conjunto de definições que descreve componentes de software e associa a funcionalidade do sistema a tais componentes. Descreve a estrutura técnica, restrições e características dos componentes e das interfaces entre eles. A arquitetura é uma ‘planta baixa’ para o sistema e um plano de alto nível para sua construção” .

    Serviços em uma SOA são a representação direta de entidades, tarefas, atividades ou processos de negócio. Por representação direta entende-se a paridade em sua granularidade e o uso de um vocabulário comum, que deve ser a terminologia padrão do negócio. São características-chave de uma Arquitetura Orientada a Serviços:

    • Acoplamento fraco dos serviços;
    • Independência de tecnologias e protocolos;
    • Uso irrestrito de padrões; e
    • Incentivo à reutilização de ativos.

    SOA é composta de quatro elementos principais: Frontends de Aplicações, Serviços, um Repositório de Serviços e um Mecanismo de Execução e Comunicação (Bus) para os serviços.

    Os Frontends de Aplicações representam a “ponta do iceberg” de uma SOA. Eles são a interface dos serviços para os usuários finais. Portanto são de sua responsabilidade a iniciação e o controle da execução dos Serviços.

    Os Serviços são componentes de software que representam um processo, entidade, atividade ou tarefa de negócio. É importante salientar que são componentes de alto nível, diferentes daqueles existentes em plataformas como o J2EE e o Microsoft .NET, que são muito granulares e mais orientados a tecnologia, não ao negócio. Existem quatro tipos de Serviços:

    • Básicos: que representam os elementos básicos de um processo de negócio, como Entidades e Tarefas básicas de Negócios;
    • Intermediários: são o único tipo de Serviço mais orientados a tecnologia em uma SOA. Fornecem pontes, conversores ou funcionalidades adicionais aos demais serviços;
    • Processos: são os serviços que representam de forma direta um processo ou atividade de negócio, do início ao fim.
    • Públicos: extensão aos serviços do tipo Processo que possibilita sua exposição para clientes (usuários) que estejam fora das fronteiras da organização.

    Todo serviço, independente de seu tipo, é sempre composto por três partes principais, como ilustrado na Figura 1 acima. A primeira parte é um Contrato, um acordo que é fechado entre os consumidores de um serviço e seus provedores. Este documento explica os propósitos do serviço, contexto, regras de utilização, restrições, níveis de serviço esperados, além de apresentar uma definição formal da interface do serviço.

    Interface esta que é implementada em separado, sendo o segundo elemento de construção de um serviço. Trata-se do único meio de comunicação com um serviço, seja seu cliente um frontend de uma aplicação ou outro serviço. A terceira e última parte de um Serviço é sua Implementação propriamente dita, através da realização da Lógica do Negócio e acesso e manutenção de seus Dados, de forma a atender todos os objetivos fixados no Contrato.

    O Repositório armazena todos os Contratos dos Serviços disponíveis, o que o torna o ponto de partida para utilização destes. Além dos Contratos, o Repositório pode armazenar informações adicionais e mais específicas acerca dos serviços, como localização física, restrições de uso e segurança etc. Apesar de ser apresentado por alguns autores como um elemento opcional em uma SOA, o Repositório pode ser fator crítico de sucesso em grandes implementações, principalmente naquelas que envolverem a disponibilização de serviços do tipo Público.

    Por fim temos o Mecanismo de Execução e Comunicação para os Serviços, ou simplesmente Bus, que interconecta todos os participantes de uma SOA, abstraindo a complexidade técnica que existe nas camadas inferiores. Um Bus pode ser constituído de várias tecnologias e/ou produtos, dependendo da infra-estrutura existente e dos requerimentos de distribuição dos serviços.

    >>>>>>>>>> SOA #3 – É o Negócio, Estúpido!

    2. “The Squandered Computer”, Paul Strassmann
    The Information Economics Press (1997).
    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).

  • [SOA # 1] – Introdução

    As organizações de Tecnologia da Informação (TI) lidam há tempos com dois meta-requisitos conflitantes: ao mesmo tempo em que as áreas de negócio exigem mais e mais agilidade, a pressão por redução de custos se torna mais forte. “Fazer mais com menos” virou regra geral. Mas os ambientes de TI viram, nos últimos 10 anos, sua complexidade aumentar em escala exponencial. Diversas tecnologias, pacotes de software e sistemas desenvolvidos in-house se entrelaçam e se sobrepõem de forma que beira o caos.

    Não se trata de má administração, não na maioria dos casos. Acontece que a urgência dos requisitos de negócio e o relativo curto ciclo de vida de algumas tecnologias levaram as organizações a erguerem verdadeiras torres de Babel. Durante um tempo foi possível apagar fogueiras localizadas com certa agilidade. Mas esse imediatismo também criou uma infra-estrutura de aplicações com muita redundância de funções e responsabilidades, pouco flexível, cara de ser mantida e, principalmente, pouco ágil.

    Mesmo as tecnologias que surgiram para promover padronização e integração, particularmente aquelas chamadas Middleware, em pouco tempo passaram a se digladiar na mesma infra-estrutura de TI, acrescentando mais complexidade e heterogeneidade.

    Testemunhamos hoje o nascimento de uma série de tecnologias, processos e modelos que visam combater a imensa complexidade das estruturas de TI. Consolidação de servidores, virtualização e grid-computing, dentre outras, miram a racionalização dos recursos. Porém são propostas que visam quase exclusivamente os ativos palpáveis, desconsiderando as principais causas da falta de agilidade e flexibilidade das organizações de TI: as aplicações e os dados.

    Por isso que a proposta de implementação de uma Arquitetura Orientada a Serviços (SOA – Service-Oriented Architecture) ganha importância e faz com que alguns institutos, como o Gartner, prevejam que será a arquitetura dominante nas corporações já em 2007.

    SOA é uma estratégia que propõe a organização dos ativos de software de forma que eles possam representar Processos, Atividades ou Tarefas de Negócio de forma direta. Tais representações são chamadas de Serviços, que devem ser baseados em padrões e facilmente combinados e reutilizados visando a satisfação dos requisitos do negócio.

    A dinâmica do mundo dos negócios exige que as organizações de TI sejam ágeis, flexíveis e simples. São os mesmos meta-requisitos que governam os Programas e Projetos SOA. Esta série apresenta as particularidades dos projetos SOA, os novos desafios apresentados e a possibilidade de realização, enfim, de antigas promessas como a Reutilização de Ativos de Software.

    Apesar do aparente ceticismo e da profusão de definições desencontradas, naturais quando se trata de uma novidade apresentada como “panacéia” pelo mercado de TI, SOA deve se consolidar como uma nova forma de desenvolver, comprar e vender sistemas de informação. Se tal hipótese se confirmar, será a maior evolução da área desde a invenção do COBOL*. Que seja bem-vinda.

    >>>>>>>>>> SOA #2 – Conceitos Básicos

    * 1964

    1. “Service-Oriented Architecture Scenario”, Yefim Natis
    Gartner, artigo AV-19-6751 (2003).