finito

Tag: Ativos de Software

  • Reuso: Conceitos, Justificativas e Desculpas

    Continuação de “Gerenciando Ativos de Software“.

    Obs importante: por se tratar de um compilação de idéias que estou realizando em “run time”, a seqüência e conteúdo dos artigos desta série podem ser consideravelmente modificados em sua versão final, um PDF que espero publicar até o dia 11/jan/2007. Nem todas as revisões se refletirão no blog. Optei por falar sobre REUSO nesta 2ª parte por se tratar do grande objetivo da série. O capítulo seguinte, que deve ser publicado na próxima semana, falará sobre Ativos de Software de uma maneira mais específica. Inclusive (re)apresentando* a proposta RAS (Reusable Assets Specification) do OMG e fazendo uma relação da especificação com os elementos que compõem uma SOA.

    * A primeira vez que publiquei um material sobre RAS foi em 2004. Está no artigo “Gestão Estratégica de Ativos de Software” . Desta vez espero ser um tanto mais específico.

    Foto da Crystal.

    Reuso é a prática sistemática de se desenvolver software a partir de um conjunto de ‘blocos de construção’, de forma que as similaridades dos requisitos e/ou da arquitetura entre as aplicações possa ser explorada para que sejam alcançados benefícios substanciais na produtividade, qualidade e na performance do negócio.

    O texto acima, transcrito diretamente de “Practical Software Reuse” , é uma das mais recentes (re)definições do termo Reuso de Software. É forte porque desconsidera aquilo que Steve McConnell chamou de “reuso oportunista” . O reuso oportunista/casual parece ser a única alternativa oferecida na versão original do RUP, por exemplo . A definição acima também é completa, porque encerra em uma única frase aquilo que seus autores consideram as 4 características-chave do reuso:

    • É uma prática sistemática para o desenvolvimento de software;
    • Emprega um conjunto de ‘blocos de construção’ (artefatos reutilizáveis);
    • Explora similaridades dos requisitos e/ou da arquitetura entre as aplicações; e
    • Oferece benefícios substanciais para a produtividade, qualidade e performance do negócio.

    Antes de uma análise de cada uma das características listadas, é interessante confrontar a definição acima com o Reuso prometido pela proposta SOA. O artigo anterior citou uma pesquisa que diz que as empresas esperam reutilizar apenas 30% dos serviços implementados. É interessante notar que trata-se de um tipo de reuso relativamente diferente daquele apresentado acima.

    Assim como em propostas anteriores, notadamente Orientação a Objetos (OO) e Componentização, o reuso em uma SOA pode acontecer em dois momentos muito distintos:

    • Em Tempo de Construção, realizado diretamente por um analista ou programador; e
    • Em Tempo de Execução, realizado por outro ativo.

    O reuso em tempo de execução é parte central na implementação de uma SOA. Todos os serviços, particularmente aqueles que representam entidades ou processos de negócios, devem encapsular um ativo existente, independente da sua tecnologia. Uma SOA propõe dar sobrevida para todos os sistemas legados de uma organização. Por isso não faria muito sentido falar de níveis de reuso em tempo de construção de uma SOA.

    A pesquisa, encomendada pela Bea , não fala explicitamente mas leva a entender que se trata do reuso em tempo de execução. De qualquer forma, a meta (30% de reuso) parece bastante modesta. Os ‘blocos de construção’ em uma SOA são os seus serviços que, conceitualmente, podem ser categorizados da seguinte maneira:

    • Básicos: representam entidades (clientes, produtos) ou pequenas atividades (validação de crédito, verificação de disponibilidade em estoque);
    • Intermediários: únicos que mantêm relação direta com a parte tecnológica da arquitetura (fornecendo pontes, conversores etc);
    • Processos: representam diretamente atividades ou processos de negócios (vendas, baixa de duplicatas etc).

    Espera-se que um serviço em uma SOA seja único na função ou conjunto de dados que oferece. Não faz sentido, por exemplo, que existam dois serviços representando a entidade Clientes. Por isso parece estranha a expectativa de que apenas 1/3 dos serviços seja reutilizado por outros em tempo de execução. De qualquer maneira, os dados disponíveis sobre implementações SOA existentes ou em andamento ainda são raros e vagos.

    Experiências com a adoção do reuso sistemático anteriores à SOA mostram que é factível a colocação de metas mais ambiciosas. Alguns casos reportam níveis de reuso entre 50% e 95%! Mais relevantes que as taxas de reutilização são os benefícios gerados diretamente por ela: ganhos de produtividade de 58% por ano em um período de 4 anos ; redução de 84% nos custos de desenvolvimento ; redução de 70% no tempo de desenvolvimento . Um programa SOA não deve alcançar números tão altos, mas eles devem servir, no mínimo, como uma boa referência para os projetos SOA.

    ===

    ===

    Referências:
    1. Practical Software Reuse
      Michel Ezran, Maurizio Moricio e Colin Tully
      Springer (2002).
    2. Rapid Development
      Steve McConnell
      Microsoft Press (1996).
    3. The Rational Unified Process – An Introduction (Second Edition)
      Philippe Kruchten
      Addison-Wesley (2000).
    4. SOA Research – SOA Justification (PDF – Requer registro)
      GCR Custom Research
      Patrocinada pela Bea Systems.

  • Gerenciando Ativos de Software

    A crescente aceitação da proposta de Arquiteturas Orientadas a Serviços (SOA) fez com que voltasse para agendas e debates um velho tabu da área de TI: o Reuso de Ativos de Software. Uma pesquisa recente, tratando especificamente de SOA, mostra que a maioria das empresas espera reutilizar apenas 30% dos serviços criados. Apesar de 84% delas dizerem que a possibilidade de reutilização de ativos é uma das maiores promessas de uma SOA; uma das maiores justificativas para sua adoção. Vamos aproveitar o debate para tratar o tema de uma maneira mais aprofundada. Este post inaugura uma série sobre o assunto. Gestão de Ativos; Reuso Sistemático; Adequação de processos; RAS (Reusable Asset Specification); GBA (Gestor da Biblioteca de Ativos); dentre outros, serão tratados de maneira específica nos próximos artigos*.

    Reuso: Um Tabu

    O assunto é tão antigo e batido, com sucessivas ressurreições e decepções, que fará com que muitos profissionais da área simplesmente ignorem a discussão e a nova fase de oportunidades aberta pelo conceito SOA. Data de 1968 a primeira tentativa para tornar o reuso sistemático uma prática , uma disciplina obrigatória em Engenharia de Software. Muito tempo depois, de maneira menos impositiva, foi a vez da Orientação a Objetos e da Componentização proporem e facilitarem o reuso de ativos de software. A princípio, os resultados sempre foram desprezíveis. Quando havia algum resultado.

    A reutilização de experiências e conhecimentos externos – normalmente apresentados como aplicações, frameworks, componentes, design patterns ou até mesmo código fonte – é prática corriqueira na maioria das organizações que desenvolvem sistemas atualmente. O grande problema, o tabu em torno do reuso de software, é o não aproveitamento dos ativos criados internamente. Qualquer tipo de ativo.

    O reuso do capital intelectual – do conhecimento e da capacidade de aprendizado e inovação – é um desafio para todas as áreas de praticamente todo tipo de empresa. Não se trata de uma carência específica da área de TI, apesar de sua natural orientação a projetos e sua intimidade com tecnologias indicarem que seria teoricamente mais simples a adoção de métodos e ferramentas para uma excelente gestão de conhecimentos. Trata-se de uma área que tem muito a evoluir. Erros e falhas recorrentes indicam que o conhecimento não está fluindo de forma adequada. “Os que não conseguem lembrar-se do passado estão condenados a repeti-lo“, dizia George Santayana.

    No entanto, de todos os ativos que formam o grande inventário da área de TI, aquele que parece mais esquecido ou, colocando de outra forma, relegado a um segundo plano, são os ativos de software. Seus co-irmãos palpáveis, notadamente o hardware e todas as instalações físicas, herdaram métodos e ferramental de controle de todos os outros ativos tangíveis de uma organização. Eles aparecem no controle patrimonial (nos sistemas de Ativo Fixo e Contabilidade) da empresa. Cadeiras, servidores e caminhões merecem uma “etiqueta” de patrimônio. Você usa, e reusa, aquilo que você sabe que possui. Quando conhece sua localização, utilidade, modos de uso, restrições, idade etc.

    Autores como Robert Kaplan e David Norton, criadores do Balanced Scorecard, classificam os ativos de software como intangíveis . Talvez sejam exatamente a percebida intangibilidade e a infinita maleabilidade do software que façam com que ele seja um ativo muito mal tratado e pouco controlado. Outro motivo, sugerido por Paul Strassmann , seria a falsa idéia de que o ciclo de vida do software obedece aquele ditado pelo hardware (com uma total depreciação em um prazo de 4 anos). É sabido que algumas empresas, particularmente no ramo financeiro, possuem código com mais de duas décadas de vida.

    “Sem o legado, cada geração começaria na idade da pedra.”
    – Paul Strassmann


    Visando à valorização dos ativos de software, Strassmann sugere que as organizações :

    • Adotem ferramentas que forcem a construção de software a partir de um repositório de peças padrão reutilizáveis;
    • Façam da acumulação e preservação dos ativos de software úteis um de seus principais objetivos;
    • Ofereçam incentivos para que o staff de sistemas inclua a acumulação de ativos de software como um de seus objetivos-chave; e
    • Aumentem a longevidade dos ativos de informação ao invés de aceitar a suposição de que eles não valerão nada após o período de breakeven.

    Viabilidade

    A era industrial se consolidou através do reuso de peças padrão. A economia de escala é indissociável do reuso. As linhas de montagem ganharam a forma que conhecemos hoje após a adoção de conceitos de reuso. O mercado de TI lançou suas “fábricas de software” mas parece ter se concentrado exclusivamente na parte (des)humana da metáfora.

    Apesar do reuso sistemático ser considerado um claro indicador de maturidade , não há em propostas como o CMMI ou MPS.br uma área ou processo específico para incentivá-lo e controlá-lo. No RUP, amplamente divulgado e relativamente aceito, o reuso de ativos é citado como “facilitado” pelo processo . No entanto, não há uma única disciplina que tente fazer do reuso uma prática sistemática, intencional.

    “Os ativos intelectuais, ao contrário dos ativos físicos, aumentam de valor com o uso.”
    – James Brian Quinn

    O mesmo se aplica para ativos de software (que são um tipo de ativo intelectual): quanto maior seu uso (e reuso), maior seu valor. Por isso causa estranheza, particularmente naqueles “não-letrados” na área, nossa incapacidade ou resistência em fazer do reuso uma prática central, obrigatória. Assim como parece estranha e extremamente pessimista a meta aferida na pesquisa citada no início deste artigo: a reutilização de 30% dos serviços em uma SOA. Casos documentados , anteriores à onda SOA, reportam ganhos de até 72% em organizações que adotaram o reuso de ativos de software como uma prática sistemática. Se sua viabilidade é provada em empresas que não têm no desenvolvimento de software uma atividade fim, o que dizer então daquelas que vivem de produzir e comercializar software?

    ===

    * Como em alguns casos anteriores, este artigo é parte de um estudo/trabalho em desenvolvimento. Ao término da série será publicada uma compilação, em formato PDF, com as devidas revisões e considerando eventuais críticas e/ou sugestões recebidas. Sinta-se à vontade para participar.

    ===

    Referências:

    1. Outside the Box (blog de Todd Biske): Use or Reuse?
    2. Software Reuse: Principles, Patterns, Prospects
      Mária Smolárová e Pavol Návrat
      Slovak University of Technology
    3. Mapas Estratégicos
      Robert S. Kaplan e David P. Norton
      Editora Campus / Elsevier (2004).
    4. The Squandered Computer
      Paul A. Strassmann
      The Information Economics Press (1997).
    5. Practical Software Reuse
      Michel Ezran, Maurizio Moricio e Colin Tully
      Springer (2002).
    6. Hoje (11/Dez/2006) fiz uma consulta ao grupo de discussão CMM-Br. Tudo indica que o MPS.br receberá um processo específico para tratar de Reuso a partir de Abril/2007.
      Agradeço os colegas Rafael Prikladnicki e Marcio Pecegueiro do Amaral pelas informações.
    7. The Rational Unified Process – An Introduction (Second Edition)
      Philippe Kruchten
      Addison-Wesley (2000).

  • [SOA # 8] – Processo de Gestão e Desenvolvimento

    Uma implementação SOA não deve significar a adoção de um conjunto totalmente novo de processos e métodos. Principalmente se a empresa contar com uma equipe relativamente estável e um conjunto de melhores práticas comprovadamente eficazes. O processo existente deveria ser customizado de forma a implementar atividades, perfis e produtos específicos de um programa SOA. A principal barreira para a adoção de um processo atual seria o fato deste não prover um ciclo de vida de desenvolvimento que seja iterativo e incremental. Um modelo waterfall, definitivamente, não é adequado para o desenvolvimento de Serviços SOA. Também é desejável que o processo utilizado seja :

    • Cooperativo: aproxime a equipe de projeto com os futuros usuários dos serviços;
    • Direto: o método deve ser de fácil aprendizado e bem documentado;
    • Adaptável: fácil de ser customizado de forma a atender particularidades de determinado projeto;
    • Escalável: de forma que possibilite sua adoção em projetos dos mais variados portes e níveis de complexidade;
    • Orientado pela Arquitetura: ou seja, pressupõe que os produtos dos projetos em desenvolvimento fazem parte de algo maior e devem, conseqüentemente, respeitar os padrões fixados; e
    • Incentivador do Reuso de Ativos: uma conseqüência direta de sua orientação à arquitetura.

    Não há um único processo no mercado que, em seu formato padrão, atenda todos os requisitos listados acima. Os 3 primeiros itens da lista mais as características “iterativo e incremental” configuram o que se chama de um “Processo Ágil”. Porém todos os mais conhecidos são indicados para pequenas equipes ou seja, não escalam. Já processos que atendem os 3 últimos requisitos da lista, como o Rational Unified Process (RUP), raramente são considerados “Cooperativos” ou até mesmo “Diretos”.

    Uma combinação do RUP, Scrum e eXtreme Programming (XP) pode gerar um excelente processo para a gestão e desenvolvimento de Projetos SOA. Abaixo é apresentada uma visão geral deste modelo customizado.

    Visão Geral de um Processo Customizado

    Dos 3 processos listados acima, o RUP é o mais completo. Por isso muitas vezes é tido como excessivamente burocrático e “pesado”. Seus críticos, na maioria das vezes, desconsideram o fato dele ser bastante customizável. O RUP é a base desta sugestão exatamente por sua completitude e adaptabilidade. Geralmente ele é apresentado, em alto nível, da seguinte maneira :


    As disciplinas do RUP mais afetadas em uma customização para atendimento dos requisitos de um processo SOA são:

    • Modelagem de Negócios: que passa a gerar, como principal produto, o Contrato do Serviço que, por sua vez, é a base para elaboração do Backlog do Serviço (Produto, na terminologia Scrum). A captura de indicadores de qualidade e níveis de serviço esperados também merece destaque;
    • Implementação: que deve incorporar algumas práticas XP, particularmente a liberação de produtos em ciclos curtíssimos;
    • Teste: que incorpora testes específicos de uma Arquitetura Orientada a Serviços, como a validação da abrangência das interfaces expostas, potencial de reuso, dentre outros;
    • Implantação: que deve assimilar também todas as atividades de publicação dos Serviços, dentre elas o encapsulamento final dos artefatos e o agendamento da publicação;
    • Gerenciamento do Projeto: que é totalmente trocada pelo método Scrum. Veja mais abaixo.

    Gerenciamento de um Projeto SOA

    Como adiantado no sub-capítulo “Equipes de Projetos” acima, a responsabilidade pelo Gerenciamento de um Projeto SOA é compartilhada pelo Coordenador do Projeto e pelo Dono do Serviço (Product Owner, na terminologia Scrum original). O primeiro cuida de todas disciplinas previstas no PMBoK (Project Management – Body of Knowledge) exceto a “Gestão do Escopo”, que seria de responsabilidade exclusiva do Dono do Serviço*. Mas a adoção do Scrum como método para a gestão de um projeto SOA implica em mudanças ainda mais profundas na rotina de trabalho do coordenador de projetos.

    Sua principal atividade pode ser vista como uma “obsessiva (extrema) gestão de riscos”. Ele deve buscar e eliminar todas as barreiras que estejam impedindo a equipe de atingir seu ponto máximo de performance. O diagrama abaixo expõe uma visão geral do processo Scrum adaptado para o desenvolvimento de projetos SOA:


    Na etapa de Planejamento é compilada a primeira versão do Contrato do Serviço. Em tempo de desenvolvimento é desejável que este contrato seja a principal ferramenta de controle e acompanhamento do projeto. Para tanto ele deve contemplar também :

    • Estimativas de Custos e Prazos para o projeto;
    • Plano de Desenvolvimento e das Iterações (Sprints);
    • Definições de sincronismo com outros projetos;
    • Plano de Testes; e
    • Plano de Publicação.

    O contrato é desenvolvido a partir dos requerimentos coletados pelo Analista de Negócios e de definições prévias oriundas do Comitê Gestor do Programa SOA. O contrato deve respeitar integralmente os Padrões SOA definidos por este comitê nos momentos iniciais do programa. É parte integrante do Contrato um desenho em alto nível da arquitetura do serviço. Por isso ele é elaborado em conjunto pelo Dono do Serviço e pelo Analista de Negócios.

    A negociação final do contrato com as áreas usuárias é conduzida diretamente pelo Dono do Serviço. O processo pode prever uma etapa de revisão de contratos pelo Comitê Gestor, que ocorreria antes da elaboração do Backlog do Serviço. Esse backlog é desenvolvido pelo Dono do Serviço. Sua elaboração é acompanhada pelo Coordenador do Projeto, que pode discutir prioridades e definir a estrutura de divisão de tarefas. É também neste momento que as estimativas de prazos e custos podem ser refinadas, com apoio de integrantes das equipes de desenvolvimento.

    A partir do Backlog do Serviço o Coordenador do Projeto elabora o Backlog do Sprint (Iteração), que é o plano de trabalho da próxima iteração a ser executada. Um sprint, na concepção original do método Scrum, é uma iteração com duração fixa de 30 dias. Apesar dos benefícios da fixação de um prazo comum para todas as iterações de todos projetos, entende-se que em muitos casos tal “regra” pode se tornar uma barreira a ser derrubada pelo Coordenador de Projetos. Um serviço, dependendo de sua granularidade, pode demandar ciclos de duração mais curta. No entanto trata-se de um excelente balizador para projetos mais complexos.

    Um sprint contempla todas as fases tradicionais de um processo de desenvolvimento de sistemas, ou seja: engenharia de requerimentos, análise, modelagem, codificação, testes e liberação. No entanto, é vital que ao término de cada sprint aja uma nova versão do serviço em condições de uso, mesmo que ainda não estejam satisfeitos todos os seus requerimentos fundamentais.

    Como mostrado anteriormente, a construção de um serviço normalmente envolverá o trabalho de dois times distintos: os desenvolvedores dos Frontends das Aplicações e os desenvolvedores dos Serviços propriamente ditos. É crucial que o backlog do Sprint contemple a total sincronização destas duas frentes de trabalho. O gráfico a seguir mostra um zoom de como deve ocorrer o Sprint :


    O processo prevê a realização de scrums diários, breves reuniões que ocorreriam sempre no mesmo local e horário. Nelas o Coordenador afere os progressos obtidos desde o dia anterior, refina a lista de riscos e impedimentos e ajusta o planejamento de atividades do dia. Radical, a proposta original do Scrum sugere que estas reuniões tenham a duração máxima de 15 minutos. O coordenador pode optar por realizar duas reuniões diárias, uma com cada time de desenvolvimento.

    No último dia do sprint realiza-se uma reunião de revisão com a presença do Dono do Serviço, Analista de Negócios e representantes das áreas usuárias. O Coordenador e a equipe de desenvolvimento apresentam as realizações do último sprint. Neste momento o Dono do Serviço e o Coordenador do Projeto revisam o Backlog do Produto, registrando mudanças ou novas solicitações. A partir desta atualização o Coordenador elabora o Backlog do próximo sprint.

    Quando todos os itens do Contrato do Serviço estiverem satisfeitos inicia-se a terceira e última fase do projeto, que na versão original do Scrum é chamada Postgame Phase. Neste momento o Serviço e respectivo Cliente são submetidos ao processo de certificação, que deve garantir a total adequação dos novos artefatos aos Padrões SOA.

    Por fim temos o processo de Publicação, que envolverá o encapsulamento de todos os artefatos gerados e o agendamento da publicação do Serviço.

    Representantes do Comitê Gestor do Programa SOA envolvem-se em três momentos de um projeto:

    • Validando o Contrato elaborado na primeira fase;
    • Acompanhando as Reuniões de Revisão, que no formato padrão ocorrem mensalmente; e
    • Certificando e Publicando a versão final do Serviço.

    O processo Scrum sugere que as equipes de projeto se auto-gerenciem, promovendo a livre interação entre todos os membros. O Coordenador do Projeto, mais que um “controlador”, é um Facilitador. Outra característica marcante do processo é a “blindagem” da equipe, que em seu dia-a-dia fica livre de influências externas. Este desenho valoriza todos os integrantes da equipe e pode representar consideráveis ganhos de produtividade.

    Evolução do Processo

    O Scrum é um modelo organizacional desenhado para a execução de projetos cuja previsibilidade é limitada . Os princípios básicos que levaram ao seu desenvolvimento foram Flexibilidade, Adaptabilidade e Produtividade. A coincidência com os meta-requerimentos fundamentais de uma iniciativa SOA é total. Mas ambas propostas, tanto o Scrum quanto as Arquiteturas Orientadas a Serviços são relativamente recentes. Praticamente não existem referências do uso do Scrum em projetos SOA.

    O trabalho mais recente de Jeff Sutherland descreve a última evolução do Scrum, chamada “Tipo C”. As principais alterações referem-se à adoção de sprints simultâneos e a elaboração de um MetaScrum. Este meta-processo pode ser muito útil na gestão do Programa SOA, como sugerido neste artigo. E a habilidade de gerenciar múltiplos sprints pode ser crucial em uma iniciativa SOA que se encontre em um estágio mais avançado de maturação.

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

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).
    14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
    Artigo (2005)
    16. “Rational Unified Process”, IBM Corp.
    http://www-306.ibm.com/software/awdtools/rup/

    * Na realidade, a versão original do Scrum prevê a existência de um terceiro gestor, não considerado nesta proposta.

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