finito

Tag: SOA

  • [SOA # 6] – MDA (Model Driven Architecture)

    Outra iniciativa relativamente recente que pode agregar alto valor a uma implementação SOA é a Arquitetura Guiada por Modelos (MDA – Model Driven Architecture), proposta e mantida pelo OMG (Object Management Group) . MDA é um framework para o desenvolvimento e manutenção de aplicações fortemente baseado em modelos e, conseqüentemente, na UML (Unified Modeling Language), que também é um padrão mantido pelo OMG. MDA propõe separar a especificação das funcionalidades de um sistema da especificação de sua implementação. Além da portabilidade obtida, haveria considerável ganho nas tarefas de construção e atualização das soluções. Várias ferramentas realizam, de certa forma, esta visão, automatizando as tarefas de modelagem e, principalmente, a transformação entre modelos. Esta “automatização” do processo de desenvolvimento geraria reduções de até 50% nos esforços e custos de desenvolvimento .

    Mas o primeiro impacto positivo que a adoção da MDA pode trazer para a implementação de uma Arquitetura Orientada a Serviços é a adoção de modelos que, utilizando variações de um mesmo padrão de linguagem, podem facilitar a visualização e compreensão das arquiteturas vigentes na organização e daquelas a serem realizadas.

    Um Serviço em uma SOA, como descrito anteriormente, é a representação fiel de um Processo de Negócio. A correta assimilação deste processo, seus sub-processos e atividades, requerimentos e restrições são cruciais para o seu desenvolvimento na forma de um Serviço. MDA fornece dois tipos de modelos que podem facilitar a absorção, desenho e eventualmente até mesmo o redesenho do processo de negócio. São os modelos CIM (Computation Indenpendent Model) e PIM (Platform Indenpendent Model).

    O CIM, como o próprio nome indica, pode representar o processo de negócio em sua forma mais pura, sem a influência da estrutura de sistemas que eventualmente o suporta. Este modelo, também conhecido como Modelo de Domínio, utiliza diretamente o vocabulário do negócio, meta-requerimento fundamental em uma implementação SOA.

    Já o PIM pode mostrar o processo de negócio devidamente apoiado por recursos computacionais sem no entanto entrar em detalhes de sua implementação. A indicação dos recursos necessários para a realização do Serviço conforme especificado em seu Contrato pode facilitar o trabalho dos arquitetos na seleção da melhor estratégia de implementação, que é desenhada na forma de um PSM (Platform Specific Model), outro tipo de modelo MDA. O framework MDA possibilita a execução de simulações na conversão dos modelos, o que pode facilitar e apoiar o processo de tomada de decisões pelos arquitetos.

    Observação: há um quarto modelo no MDA, chamado PM (Platform Model). Ele provê uma visão de uma plataforma específica, seus elementos e serviços oferecidos. Se devidamente enriquecido de forma a representar as peculiaridades daquela plataforma na empresa ele também pode ser muito útil nas tarefas de simulação citadas acima. Além, é claro, de ser base para a modelagem do Bus que é um dos 4 principais elementos de uma SOA.

    >>>>>>>>>> SOA #7 – Os Projetos SOA

    8. “MDA Guide V1.0”, OMG – Object Management Group
    OMG (2003). (http://www.omg.org/mda)
    9. “Executive Justification for Adopting Model Driven Architecture (MDA)”, Stanley J. Sewall
    Artigo (2003).
    10. “What Senior Management Need to Know About the Value of MDA”, Louis J. Eyermann III
    Artigo (2004).

  • [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 # 4] – O Programa SOA

    SOA representa uma nova forma para se desenvolver, manter, comprar e vender aplicações de negócios. Ela pode afetar praticamente todos os sistemas de informação de uma empresa. E, quando bem sucedida, não possui um prazo para terminar. Como a construção de cada novo Serviço pode ser gerenciada como um projeto em si, é recomendável que uma iniciativa para implementação de uma SOA seja tratada e gerenciada como um Programa. Como tal, deve possuir definições acerca de sua Estrutura, Processos e Padrões.

    Um programa SOA deve ser dirigido por um Comitê Gestor, desenhado e populado especificamente para a iniciativa. Dentre as responsabilidades deste Comitê destacam-se :

    • Estabelecimento e revisão das estruturas, processos e padrões utilizados tanto no âmbito do programa quanto no nível dos projetos;
    • Acompanhamento da execução de todos os projetos SOA;
    • Garantia do apoio e participação das áreas de negócio durante todo o programa;
    • Manutenção do plano estratégico e do foco da iniciativa; e
    • Execução de atividades de evangelização, como treinamento, coaching e divulgação dos benefícios e restrições do programa para toda a organização.

    O Comitê Gestor de um programa SOA possui algumas funções bastante particulares. A figura 3 abaixo apresenta um modelo padrão desta estrutura, destacando seus principais atores:


    O Gestor do Programa responde por ele perante toda a organização. Dada sua importância estratégica não será estranho se algumas empresas optarem por alocar o próprio CIO ou Diretor da área de TI nesta função. Ele é apoiado diretamente por um Engenheiro do Processo, que pode ser um representante do Escritório de Projetos (PMO – Project Management Office), caso exista. A uniformidade e respeito aos processos de desenvolvimento e manutenção são fatores críticos de sucesso. O Engenheiro do Processo deve garantir que tanto o programa quanto os projetos SOA estejam sendo executados dentro dos padrões estipulados pela corporação. Também é sua responsabilidade a indicação dos Coordenadores de Projetos, seu acompanhamento e apoio.

    No entanto, o “braço direito” do gestor do programa é o Arquiteto SOA. Ele é o principal responsável técnico pela elaboração e implementação da arquitetura orientada a serviços. Devido a abrangência, complexidade e criticidade de tal iniciativa, o Arquiteto SOA compartilha suas responsabilidades com outros 5 arquitetos, cada um especialista em uma parte do programa.

    O Arquiteto de Negócio é o principal representante do programa perante as áreas de negócio. Visto de outra maneira, ele também representa as comunidades usuárias no Comitê Gestor. Ele deve coletar, avaliar, apresentar e defender os requerimentos de negócio. Portanto ele faz uso, em alto nível, das disciplinas Modelagem de Negócios e Engenharia de Requisitos. Se estivessem representadas na figura 3 acima, as áreas de negócio estariam no lado esquerdo do desenho. Entende-se então que os membros do comitê gestor que se relacionam de maneira direta com a comunidade usuária, além do Arquiteto de Negócio, são o Gestor do Programa, o Engenheiro do Processo e o Arquiteto SOA. Mas sua representação é uma atribuição exclusiva do Arquiteto de Negócio.

    O Gestor da Biblioteca de Ativos (GBA) é um personagem raríssimo nos ambientes e projetos de TI. Mas sua existência é fundamental para o sucesso de um empreendimento SOA. Além do gerenciamento do Repositório, apresentado anteriormente, o GBA também é responsável pelos principais processos de reutilização de ativos , ou seja: publicação e manutenção dos Contratos; introdução e coordenação do reuso de ativos; evolução do processo de reutilização etc. Com o tempo e conseqüente aumento no número de serviços disponíveis cresce também a importância do GBA.

    O Arquiteto dos Frontends das Aplicações tem sua alocação no comitê justificada pelo fato destas interfaces serem o único ponto de interação dos usuários com a SOA. São críticas as atividades de padronização das interfaces e garantia de usabilidade, que são atribuições exclusivas deste arquiteto.

    O Arquiteto de Serviços, por sua vez, concentra-se na padronização, acompanhamento do desenvolvimento e avaliação dos Serviços. Nos momentos iniciais do projeto são de sua responsabilidade a elaboração de padrões para os quatro tipos de Serviços existentes em uma SOA, ou seja: Básicos, Intermediários, Processos e Públicos.

    Por fim, temos o Gestor da Infra-estrutura Tecnológica, o membro do comitê responsável por garantir que os recursos computacionais disponíveis sejam adequados para atender a demanda que SOA e seus serviços gerarão. Além do sizing e estudo de capacidade de carga dos servidores, redes e softwares de infra-estrutura, este Gestor também acompanha os serviços em ambiente de produção visando garantir os níveis de serviço esperados.

    Percebe-se que o Comitê Gestor é praticamente uma representação do corpo gerencial de uma organização de TI. Em muitos casos talvez seja uma estrutura ainda mais sofisticada e completa. Acontece que em um “mundo ideal”, quando SOA encontra-se em estágio avançado de maturidade e todos os processos de negócio são representados por Serviços, o comitê gestor do programa SOA torna-se praticamente a equipe de gestão de toda a organização de TI. Apesar de ser um conceito relativamente novo, alguns casos de sucesso comprovam que tal “metamorfose” é uma conseqüência bastante plausível de uma implementação SOA bem sucedida. É curioso notar também que em uma situação onde a empresa decide pela total terceirização de sua área de TI, as 8 funções apresentadas acima talvez sejam as únicas que a empresa decida manter internamente. Para não correr o risco de perder o alinhamento de TI com o negócio.

    >>>>>>>>>> SOA #5 – Processos

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).
    4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
    Springer (2002).

  • [SOA # 3] – É o Negócio, Estúpido!

    Um dos principais apelos e, porque não dizer, motivo de estranheza quando se analisa uma proposta de implementação de uma SOA, é o fato dela não apresentar ou forçar a utilização de nenhuma nova tecnologia. Pelo contrário. SOA deve promover a sobrevida dos ativos de software de uma organização, tanto das aplicações de negócio quanto dos elementos de infra-estrutura (como servidores de aplicações, middleware para comunicação assíncrona, dentre outros). Martin Frick chega a sugerir que troquemos o termo “sistema legado” por “Sistema Herdado” .

    O fato é que há muito conhecimento codificado na forma de software e espalhado pelas organizações. Mesmo após a implementação de soluções de integração de larga escala como os ERPs e sistemas CRM, a arquitetura de software das empresas continuou fragmentada, com diversos silos de informação. A característica “monolítica” destas soluções tornou cada esforço de integração uma espécie de barreira para a implementação de mudanças e novas funcionalidades no nível do negócio.

    O “ovo de Colombo” de uma proposta SOA está em seu linguajar, totalmente orientado ao Negócio. Os Serviços, suas Interfaces e Contratos são apresentados na língua de seus usuários e clientes. Elimina-se desta forma aquela distância e confusão que sempre caracterizou as interações das áreas de TI com seus usuários. Mas esta nova aproximação requer uma revisão na estrutura e processos da organização de TI, como será apresentada nos capítulos seguintes.

    Não é objetivo deste artigo tratar de questões acerca dos aspectos tecnológicos de uma implementação de uma Arquitetura Orientada a Serviços. Mas é importante lembrar que o conceito SOA nasceu logo após o advento dos Web Services. Estes nasceram com escopo relativamente limitado, propondo uma forma de integração de aplicações utilizando padrões abertos da Internet. Apesar de não serem obrigatórios para a realização de uma SOA, os Web Services e os padrões que os viabilizaram, como XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol) e WSDL (Web Service Definition Language), dentre outros, podem favorecer, e muito, a implantação de uma SOA. Mas deve-se lembrar que SOA não é um conjunto de Web Services e, por outro lado, o fato de uma empresa ter uma porção de serviços Web não significa necessariamente que ela possua uma arquitetura de aplicações orientada a serviços.

    As organizações de TI têm, talvez pela primeira vez em sua história, a oportunidade de fazer com que seus investimentos e custos tenham claro e inequívoco objetivo de negócio atrelado. Mas o sucesso de uma implementação SOA depende de uma ampla e compartilhada visão de seus objetivos, restrições e roteiro de construção. Como será exposto nos capítulos seguintes, a gestão do Programa SOA e respectivos projetos desempenha papel fundamental nesta realização.

    >>>>>>>>>> SOA #4 – O Programa SOA

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).

  • [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).

  • Scrum !

    Para o artigo que estou desenvolvendo sobre “Projetos SOA” tive que mergulhar em alguns “Processos Ágeis”. Gostei um tanto do Scrum, e agora tento adaptá-lo para o desenvolvimento de Serviços em uma SOA. Trabalho legal.

    BTW, muito legal tb é o trabalho do Jeff Sutherland, criador do Scrum. Ele mantém um blog sobre o assunto. Foi lá que surrupiei a charge legalzinha aí de baixo:

    Espero voltar ao tema em breve.