Arquiteturas Orientadas a Serviços SOA

Transcrição

1 SOA Componentização e Reúso

2 Motivação Top-down Enterprise Drivers: Agilidade Flexibilidade dos processos Inovação contínua Fusões e Aquisições Desafios constantes de TI: Fazer mais com menos Alinhamento TI x negócio Qualidade Time-to-delivery Bottom-up Business Drivers: Integração de processos B2B Real-time Outsourcing de atividades não-chave

3 Motivação Muito difícil de entender, manter e evoluir

4 Motivação Mundo de conexões Ponto-a-ponto Construímos rastros de ratos, decisões caso-acaso Visão de curto prazo

5 SOA não é: SOA não é uma tecnologia; SOA não é um produto ou plataforma; Nenhum fornecedor pode vender SOA para você; SOA não é uma revolução ou bala prata ; SOA WebServise XML BPM SOA não é Puro Marketing

6 SOA Não há como evitar SOA: Because SOA comes so many places, SOA will happen to everyone Frank Kenney, abril 2007 Service Orient or be Doomed Jason Bloomberg, março 2006

7 SOA Service-Oriented Architecture SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócios interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas

8 Novidades O mundo é orientado!! Vocabulário aderente às demandas de negócios dos clientes Baseado em tecnologias padronizadas Integração de aplicações intra e entre empresas é um fardo pesado Construído sobre o existente usando uma abordagem incremental O legado é muito importante

9 Abordagem Corporativa Application Infrastructure Application Development Service Infrastructure Composite Application Framework Business Service Orchestration Cross-platform management Governance and control Service discovery, publishing and security Message routing and transformation

10 O que o mercado anda dizendo Em 2008, mais de 60% das empresas utilizarão SOA como princípio básico para a criação de aplicações e processos de missão crítica O mercado SOA na América Latina deve crescer de US$ 71 milhões para US$ 1,6 bilhão de 2006 para 2011 o que representa um crescimento acumulado de 86% ao ano Companies with even basic governance in place see the benefits through high levels of services reuse and low levels of service duplication SOA é a nova fundação para a entrega mais rápida e eficiente de valor ao negócio através da TI

11

12 Dimensões

13 Visão de Mercado Qual a relevância da questão produtiva na industria de TI de forma geral? Top 4 of fundamental problems (faster and cheaper)! Sob pressão devido movimento de offshore Quais serão as principais plataformas de desenvolvimento nos próximos 5 anos? Alguma novidade? J2EEE e.net dominam completamente novos desenvolvimentos. J2EEE continua a liderar o movimento de aplicações de missão critica

14 Visão de Mercado Quais novas tecnologias são esperadas para os próximos 5 anos que possam impactar significantemente a produtividade no desenvolvimento? No killer development tolls are emerging Onde estao as apostas de médio e longo prazo para a questao da produtividade? Without reuse there is no way to improve productivity. No tecnology will give into to you

15 Como aumentar a produtividade? Trabalhando mais rápido Automação, ferramentas, ambientes Trabalhando mais inteligentemente Melhoria dos processos Evitando o trabalho desnecessário Reuso dos artefatos do projeto

16 Como aumentar a produtividade? Trabalhando mais rápido (Ferramentas) 8% Trabalhando mais inteligentemente (Processos) 17% Evitando o trabalho desnecessário (Reúso) 47%

17 Como aumentar a produtividade? Paradigmas-chave: Component-Based Development (CBD) SOA (Software Oriented Architecture) e Web Services MDA (Model Driven Architecture) Software Product Lines (SPL)

18 Por que agora? Amadurecimento da arquitetura de sistemas distribuídos (J2EEE, MS.Net), servidores de aplicação e ferramentas Modelos de qualidade (CMMI e MPS.br) Massa crítica: Mercado crescente de componentes prontos para uso (COTS Commercial off the Shelf) Vendors

19 MPS.br Criado em Dez/2003 MCT/Softex Objetivo: Melhoria de processo de software brasileiro Práticas de gestao do reúso são obrigatórias a partir do nível E Processo: gerencia de reutilizaçao (GRU)

20 Participação

21 Empresas que possuem uma iniciativa de reúso de ativos de software podem aumentar sua produtividade, qualidade e agilidade em um fator de, pelo menos, 5 para 1 e o coração dessa iniciativa está na possibilidade das equipes de projeto localizarem e reusarem os ativos de software. Enterprises can substantially improve application development productivity and quality, while also decreasing time-to-market, by a factor of 5-1 or more through a committed software asset reuse program. At the heart of this initiative must be ability for analysis and developers to easily locate and reuse these assets

22 Benefícios esperados de SOA Redução de custos em novos projetos Time-to-market / Agilidade Facilidade / Flexibilidade de manutenção Melhoria da Qualidade dos serviços Otimização dos processos Transformação dos negócios / Oportunidades de Receita

23 Conceitos-Chave

24 Conceitos-chave Baixo acoplamento: Capacidade dos ativos de TI trabalharem integrados embora existam independentemente

25 Conceitos-chave Abstração: Permite que agentes humanos interajam com sistemas complexos de uma forma simples

26 Conceitos-chave <não dá pra ler!>: Elemento de software que encapsula o conhecimento e que pode ser reusado: Quais são os seus?

27 E como SOA se encaixa nesse contexto?

28 Dimensões envolvidas Metodologia / Processos / Governança Em 2010, a carência de planejamento relacionado a governança será a razão mais comum dos fracassos em SOA Capacitação e estruturação organizacional Arquitetura Tecnológica Patterns, Frameworks, Componentes e Boas práticas Fator crítico de TI: Reutilização Ferramentas em Design-time e Infra-estrutura de Run-time

29

30 Stages of SOA adoption

31 Em 2010, menos de 25% das grandes empresas terão desenvolvido as habilidades técnicas e organizacionais necessárias para implantar SOA de forma corporativa Throught 2010, fewer than 25 percent of large companies will have developed the technical and organizational skills needed to deliver enterprise wide SOA

32 Nem tudo são flores

33 Principais desafios Organização e Pessoas Papéis e responsabilidades Mudança de cultura Promoção, acompanhamento e Enforcement Tecnologias e Ferramentas Arquiteturas Padronizadas Middleware de Integração Padrões de Classificação e Documentação Repositório de Ativos e Reutilizáveis Organização e Pessoas Ciclo de vida dos ativos Metodologia de Desenvolvimento revisada Processos de Manutenção

34 Organização Requer mudança de mentalidade Apoio executivo Capacitação nos conceitos-chave Política de incentivos Divulgação e visibilidade dos ativos existentes: é necessário um trabalho de endo-marketing Um excelente componente ou serviço, flexível, bem documentado, e que resolve um problema recorrente só pode ser considerado um bom ativo se as pessoas conseguirem encontrá-lo, entende-lo, avaliá-lo e reusá-lo, caso contrário, será um ótimo segredo!!

35 Organização Estrutura organizacional / Papéis: Administração de componentes Perfil semelhante à administração de dados Conhecimento do negócio Gestão de arquitetura de referência ICC (Integration Competency Center) ou SOA CoE (Center of Excelence) Desenvolvimento / suporte de componentes Perfil: desenvolvedores seniors com ampla capacitação em orientação a objetos Conhecimento de oferta de componentes de mercado

36 Processos e políticas Adaptações no processo de desenvolvimento atual para tornar SOA uma prática sistemática Como as atividades abaixo se encaixam no processo de desenvolvimento de software atual? Identificação de serviços; Modelagem de serviços; Publicação dos serviços; Definição das interfaces dos serviços; Testes; Deploy de serviços.

37 Dificuldades relacionadas a tecnologia Volatilidade Tecnológica Falta de padronização de arquitetura Repositório de Assets Massa crítica de serviços Middleware para invocação dos serviços

38 Repositório de Serviços Embora a adoção de uma ferramenta de administração de ativos focada em reúso não garanta por si só o sucesso da iniciativa de reutilização da empresa, ele irá aumentar significantemente suas chances Fonte: Enterprise Unified Process The Strategic Reuse Discipline Scott Ambler, John Nalbone e Michel J. Vizdos

39 Ritmo Em 2010, menos de 25% das grandes empresas terão desenvolvido habilidades técnicas e organizacionais necessárias para implantar SOA de forma corporativa Through 2010, fewer than 25 percent of large companies will have developed the technical and organizationalskills needed to deliver enterprise wide SOA (0.8 probability)

40 Quando não usar SOA Em ambientes estáveis, homogêneos e quando a empresa não oferece serviços de software para parceiros, clientes ou fornecedores

41 Quando não usar SOA Como SOA é baseado em troca de mensagens e baixo acoplamento, para os casos que necessitem de desempenho real-time, SOA pode não ser a melhor abordagem

42 Funcionamento Básico SOA

43 Dinâmica

44 Dinâmica É muito mais comum encontrar integração integração com ligação ponto-a-ponto usando Web Services

45 Mais alguns exemplos Serviços Básicos: Stock Quotes Previsão do tempo Serviços com valor estratégico para o negócio: Status de Pedido Consulta de Extrato Consulta de índice de risco

46 Agência de Viagens... Aqui tem que criar uma modelagem para uma agencia de viagens (está ilegível) + 2 slides similares tb

47 Como SOA vem Transformando Negócios

48 Alguns (bons) exemplos Algumas empresas já vêm destacando-se e reinventando sua forma de realizar negócios Alguns destaques globais: Amazon.com Strike Iron Salesforce.com HP

49 Amazon

50 Amazon

51 CRM on-demand Salesforce: Plataforma ondemand para automação de força de vendas e CRM SaaS tomando força Desconfiança sobre disponibilidade Resposta: Governança dos principais serviços trust.salesforne.com

52 E quanto a nós? Discussão: Componentização e Arquitetura Orientada estão sendo implementadas na empresa? Existem iniciativas criando componentes e Web Services?

53 Implementando SOA com Web Services

54 Web Services Baseados em padrões abertos com grande aceitação no mercado Aplicações podem ser desenvolvidas em qualquer linguagem que possua suporte a WebServices de forma bastante simples Forma padronizada para se descrever as interfaces dos serviços Infra-estrutura de transporte e comunicação já existente - a web (custo baixo de adoção) O melhor: as ferramentas dão suporte e cuidam de quase todos os detalhes

55 Principais conceitos Sopa de letras: XML SOAP WSLD UDDI Reescrevendo a definição: WebService é um serviço de software exposto na web, descrito via WSDL, disponível em um registro UDDI e acessado via SOAP.

56 Dinâmica de funcionamento Ex.: Submarino Loja virtual Ex.: Correios Tracking de pacotes

57 UBR Catálogo global com informações sobre provedores de serviços e serviços disponíveis para invocação Função de páginas amarelas para descoberta de serviços públicos UBR s públicos: Microsoft, IBM e SAP...

58 Conclusão: Quem tem amigos não precisa de páginas amarelas

59 Governança SOA

60 Evitando acidentes

61 Fatores críticos Executive level buy-in Comunicação e colaboração efetiva Escolher corretamente o projeto piloto Requisitos de escopo bem definido Valor de negócio claro e visível Disciplina formal e governança Ownership de serviços e incentivo as equipes de projetos Adoção incremental baseada em uma combinação de critérios técnicos e de negócio

62 Governança Em 2010, a carência de planejamento relacionado a governança será a razão mais comum dos fracassos em SOA Through 2010, lack of working SOA governance arrangements will be the moust common reason for SOA falilure

63 Definição Governança SOA é um subset da Governança de TI relacionada ao estabelecimento de políticas, controles e obrigações relacionados aos serviços SOA.

64 Definição Governança SOA deve endereçar como os serviços reusáveis são definidos, modelados, criados, acessados, executados e mantidos (papéis e responsabilidades) Governança SOA identifica: Business Processes and Services Ownership Alocação de custos em modelos compartilhados

65 Governança SOA

66 Governança SOA Definições importantes para o sucesso da Governança SOA: Organização da empresa para suportar a estratégia SOA: Grupos, papéis, processos, políticas e ferramentas It s all about Ownership Qualificação os Assets: Tipos, atributos, documentos e relacionamentos Levantamento dos domínios para os atributos Ciclo de vida dos Assets: Da identificação a aposentadoria

67 Organizando para SOA Formas de organização mais comuns: ICC = Integration Competency Center SOA CoE = SOA Center of Excelence Mais alguns exemplos de organizaçao interna das empresas para acomodar as responsabilidades relacionadas a SOA: SOA Business Transformation Architecture Council SOA Technical Architecture Board Component Design and Development Center Operations Center

68 Mais grupos e papéis É necessário definir papéis que atuarão em cada etapa do ciclo de desenvolvimento Novamente há sobreposição com o processo de desenvolvimento de software Exemplo de organização: RACI Tables (R) esponsible (A) ccountable (C) onsulted (I) nformed

69 Qualificando os Assets Algumas formas possíveis: Classificação / Taxonomia / Ontologia Passos importantes: 1.Determinar os tipos de Assets que serão gerenciados/governados 2.Para cada tipo de Asset: Determinar os atributos que melhor representam/documenta o asset Levantar amostragem dos domínios das informações Verificar o que é comum a todos 3.Determinar os relacionamentos possíveis entre os assets

70 Discussão Quais os assets e quais informações são necessárias para melhor documentá-los e governá-los? Que facilitem sua descoberta Que facilitem a reutilização Que facilitem a gestão

71 Praticando Tipos de Assets: Atributos:

72 Alguns exemplos Gerais: Nome / Versão Descrição Categorização Release notes... Para o reuso: Palavras-chave para busca Documentos (requisitos, exemplos, binários) Referências (pessoas e projetos / sistemas) Dependências Compatibilidade... De controle: Tracking de utilização (quais áreas / sistemas / projetos com seus contatos utilizam quais versões de quais componentes) Número de linhas de código Esforço de implementação Situação do componente Formas de licenciamento...

73 Ciclo de vida dos serviços Qual o diagrama de estados de um ativo? Identificado Em aprovação Disponível Em desenvolvimento Aposentado

74 Discussão Quais são os estágios que um serviço passa ao longo do seu ciclo de vida?

75 Roadmap de adoção e maturidade

76 Colocando para rodar Vários conceitos: Níveis de maturidade Estágios de adoção Processo de implantaçao Abordagem incremental Fatos críticos para o sucesso E agora? Don t try to boil the ocean

77 Processo de implantação SOA Iniciation SOA Planning and Design SOA Implementation SOA Monitoring and Compliance

78 Níveis CMMI

79 Processos CMMI

80 Stages of SOA adoption

81 Para começar Pensar grande Começas pequeno Avançar rápido

82 Business Case SOA

83 Business Case SOA Objetivo: Capacitá-los a estruturar um plano de como introduzir uma inovação/mudança de paradigma dentro da empresa Estruturar uma venda interna do conceito SOA para os executivos da empresa O que fazer? Preparar um Business Case (BC)

84 Business Case SOA Estrutura Básica: Dificuldades atuais / motivadores Benefícios buscados Plano de Implementação Investimentos necessários Conclusões

85 Business Case SOA Dicas: Research and Reuse! Existe bastante material disponível: Internet Material bibliográfico Apresentação de empresas de TI Apresentação de vendors SOA Google!!

86 Business Case SOA Dificuldades atuais / motivadores: Procurar exemplificar com itens reais do dia-a-dia mostrando dificuldades ou custos que poderiam ter sido evitados e antecipações de possíveis problemas futuros

87 Business Case SOA Benefícios buscados: Deve-se procurar listar, de forma genérica os principais objetivos Podem ser classificados em tangíveis e nãotangíveis Para os tangíveis, é necessário assumir premissas, fazer estimativas e estabelecer metas Dicas: Evitar lugares comuns como: Redução de custo (esse é um ponto importantíssimo, mas devemos dar exemplos reais com qualificação numérica, por exemplo)

88 Business Case SOA Plano de implementação: Essa seção deve apresentar a ordem em que os investimentos e as decisões serão tomadas na implementação do programa SOA São pontos importantes a serem destacados: Seleção de projeto piloto Cronograma macro das atividades Matriz geral e responsabilidades Indicadores a serem acompanhados e suas metas

89 Business Case SOA Investimentos necessários: Apresentar os investimentos que a empresa deverá fazer para conseguir ter sucesso em sua estratégia SOA

90 Business Case SOA São investimentos comuns: Infra-estrutura de hardware e software Capacitação e treinamento Apoio externo (consultoria) Equipe interna (tempo das pessoas que já são da equipe e eventuais novas contratações)

91 Pré-Assessment SOA

92 Assessment SOA Objetivos: Fotografia da situação atual Avaliação de aspectos positivos e pontos de atenção.

93 Assessment SOA Visão de benefícios SOA: Patrocínio executivo; Mobilização técnica; Projeto piloto a ser implementado; Visibilidade dos benefícios: Integração de aplicações e customização para clientes Entrega de partes / modularização do produto. Equipe enxuta e motivada.

94 Exemplo Organização e Pessoas Mudança de Cultura Alinhamento técnico e de expectativas Processos e Políticas Novos papéis e responsabilidades Aplicação da Governança em projetos Promoção, Acompanhamento e Enforcement Tecnologias e Ferramentas Visibilidade do acervo e ferramental Produção / Reuso dos ativos nos próximos projetos

95 Exemplo Projeto Piloto Definição do projeto seguindo boas práticas Utilização da metodologia Metodologia sendo evoluída BLA BLA BLA coorporativo

96 Modus operandi Plano de trabalho: Entrevistas Questionário Decisões internas para oferecer o diagnóstico

97 Serviços: Identificação e Granularidade

98 Top-down Identificando as necessidades de negócio e modelando essas necessidade sem serviços de alto valor agregado Bottom-up Disponibilizando um conjunto de funcionalidades já disponíveis nos sistemas existentes (legados) Recomendação ( meet in the middle ) Primeiro a análise top-down e depois bottom-up para preservar o alinhamento com o negócio que é o principal objetivo de uma arquitetura orientada a serviços

99 Serviços Princípios da orientação a serviços: Serviços são Reutilizáveis; Serviços compartilham um contrato formal; Serviços possuem um baixo acoplamento; Serviços abstraem a lógica; Serviços são capazes de se compor; Serviços são autônomos Serviços evitam a Alocação de recursos por longos períodos; Serviços são capazes de ser descobertos.

100 Identificação dos Serviços Top-Down, algumas técnicas: BPM Business Process Management PBS Product Breakdown Structure Análise/Design de Domínio Bottim-up, algumas técnicas: Bases de dados existentes Aplicativos existentes Funcionalidades existentes

101 Alguns tipos diferentes de serviços: User Interface Services Process Composite Services Application Services Business Services Data Services Infrastructure Services Integration Services

102 De onde vem os serviços Em 2008 pelo menos 65% dos serviços desenvolvidos em projetos SOA serão implementados através do encapsulamento ou reengenharia de aplicações já existentes

103 Discussão: Qual o tamanho correto dos serviços? Quais aspectos devem ser levados em consideração para a empresa definir a granularidade correta para seus serviços?

104 Performance e Tamanho Evitar overhead de processamento entre chamadas e diminuir o tamanho das mensagens Estados e Transações Chamadas subsequentes que precisam compartilhar o contexto e deveriam estar agrupadas em um mesmo serviço Encaixe no negócio Os serviços que representam partes dos processos de negócio da empresa possui maior potencial de reuso Integração: não podemos esquecer de nos integrar! Gestão Dificuldade de manutençao x reusabilidade

105 Experience in the name every one gives to their mistakes Experience is what causes a person to make new mistakes instead of old ones, Googando SOA Anti-Pattern

106 Top 6 concerns Try to boil de ocean Vamos implementar alguns web services Pensaremos em governança mais tarde Governar vs Ser Governado A nossa empresa é diferente Vamos as compras

107 As estratégias SOA devem ser corporativas (não se deve pensar apenas em um projeto ou uma área) Tratar como corporativo, patinar e não sair do lugar! vs Avançar rápido com risco de negligenciar áreas e pessoas Dicas: Reflita sobre o todo Resolva para o imediato Aceite e se planeje para mudanças

108 SOA é muito mais que um punhado de web services Principais perspectivas: Arquitetura (não podemos esquecer o A do SOA) Metodologias / Processos / Governança Estruturação Organizacional Capacitação Ferramenta em design-time Infraestrutura em run-time

109 A nossa empresa é dif. Todas as empresas possuem particularidades, mas acreditem, muitas outras possuem problemas parecidos com os seus! Dicas: Participe de conferencias Ouça as histórias das outras empresas Conheça o mercado e as ofertas

110 Adoção de SOA Technology Bandwagon So, what s news: The Big Bang Identificação de Serviços e design de serviços WebService = SOA The Silo Approach Misbehaving Repositories Implementação / Realização dos Serviços Chatty Service Point-to-poitnt Service Component-less services Mais alguns SOA adoption Pifalls

111 Descrição: Empresas decidem pular no vagão de adoção de SOA sem avaliar os ganhos para o negócio Sintoma: Inabilidade dos sponsors de articular os ganhos de SOA Solução: Elaborar uma proposta de valor Selecionar os pontos específicos

112 Adoção Descrição: Céticos dizem que não há novidades em relação a SOA, pois se trata apenas de tecnologia que já existia, com uma nova roupagem. Sintoma: Oposição forte de gerentes técnicos a adoção de SOA. Solução: Comunicar e enfatizar como as tecnologias introduzidas e a padronização em torno de especificações abertas evoluíram a interoperabilidade entre soluções.

113 Adoção Descrição Oposto do So, What s news, um antipatterns que ocorre quando toda a corporaçao se mobiliza para mover todas as suas aplicaçoes de uma vez para a nova abordagem. Solução Assessment do nível de maturidade para SOA da empresa Pilotos menores, avaliações constantes dos ganhos obtidos

114 Identificação dos serviços e design dos serviços WebServices = SOA The Silo Approach Misbehaving Repositories

115 Descrição: SOA é considerado um sinônimo de web services Sintoma: Mera conversão de APIs para WebServices e implementação de serviços que não estão alinhados com necessidades de áreas de negócios Solução: Identificar serviços de alto valor agregado e de alta granularidade que façam sentido para o negócio

116 Design: The Silo Approach Descrição Serviços são identificados exclusivamente sob a perspectiva de aplicativos, e não, de todo o negócio. Sintoma Mesmos serviços identificados em contextos diferentes por grupos diferentes. Solução Implantar um processo de modelagem de serviços que considere todos os processos core da corporação de forma integrada.

117 Design: Misbehaving Repositories Descrição Serviços com informações faltantes, não padronizadas, duplicações de informações etc. em repositórios de serviços. Sintoma Falta de clareza dos papéis responsáveis (duplicação), repositórios duplicados. Solução Estabelecimento de um modelo de governança SOA (processos, responsáveis, etc.).

118 SOA Implementação / Realização dos serviços Chatty Services Point-to-point Services Component-less Services (also know as: Logical Layering is obsolete)

119 Descrição: Vários serviços interagem para implementar uma atividade do processo de negócio. A interface é orientada a poucos dados ao invés de ser orientada a um documento de entrada/saída. Solução: Quando o anti-pattern for identificado, realizar refactoring para consolidar o serviço.

120 Impl.: Point-to-point Services Descrição WebServices e serviços são utilizados como mecanismo padrão para várias integrações ponto-a-ponto entre aplicações internas. Solução Utilizando um ESB para diminuir o acoplamento.

121 Component-less Services Descrição Os serviços não são implementados seguindo-se uma clara arquitetura baseada em componentes e camadas lógicas. Solução Contemplar na estratégia de implantação SOA, a implantação das melhores praticas de implementação de serviços.

122 Reuseless Artifact and Declareted Reusable NIH Syndrome Unique Organization Reuse Comes Free Only-Code Reuse Technology-Driven Reuse Repository-Driven Reuse Production Before Consumption Project-Driven Reuse

123 Reuseless Artifact and Declareted Reusable Algum ativo é declarado como reusável, mas na verdade não é. Uma opçao é que outra pessoa, além do autor, verifique se é de fato. Outra, é que seja declarado reusável somente quando tiver sido reusado. Reuso é qualidade e não quantidade.

124 NIH Syndrome Os desenvolvedores e as equipes de projeto deixam de utilizar determinado ativo pois não foram eles que criaram. Normalmente, equipes mais maduras, reutilizam, desde que o ativo tenha qualidade, esteja bem documentado e seja fácil de entender.

125 Unique Organization Muitas pessoas gostam de pensar que sua situação é radicalmente diferente de todos os outros, que, de alguma forma, eles são únicos e por isso devem construir tudo a partir do zero. A solução é aceitar que vocês trabalham com as mesmas tecnologias e resolvem o mesmo problema que milhares de outras pessoas.

126 Reuse Comes Free Trata-se da crença que o reuso acontece gratuitamente. Como temos visto, é preciso investimento e disciplina para se obter os benefícios.

127 Only-Code Reuse Acreditar que somente código pode ser reutilizado. Vimos que ativos são muito mais abrangentes que apenas código.

128 Technology-Driven Reuse A idéia de que a adoção de determinada tecnologia irá direcionar o reuso. Sim, algumas tecnologias podem tratar níveis elevados de reuso, no entanto, um ativo é reutilizado se ele possui qualidade e não somente se tiver sido desenvolvido em Java, por exemplo.

129 Repository-Driven Reuse Acreditar que a adoção de um repositório específico pode promover o reuso na empresa. Sim, as ferramentas auxiliam bastante e suportam o reuso, mas não garantem que ele ocorra.

130 Production Before Consumption Desenvolvedores que tentam criar ativos reutilizáveis sem uma experiência significativa acabam criando ativos não-reutilizáveis.

131 Project-Driven Reuse O benefício obtido com a criação de ativos reutilizáveis dentro de um projeto é muito pequeno. O reuso é uma iniciativa multiprojeto!

132 SOA: Componentização e Reúso

133 Componentização

134 Motivação Arquitetura de Software Componentes de Software UML Components Modelando a Interface de Componentes Modelando a Implementação do Componente Empacotando o Componente

135 Motivação

136 Motivação 1 em cada 3 grandes projetos é cancelado 1 em cada 8 é considerado projeto de sucesso 9% dos projetos terminam dentro do prazo e do custo esperado Projetos finalizados possuem 42% das funçoes propostas originalmente 53% dos projetos custam 190% das suas estimativas iniciais

137 Componentização Componentização de software é uma abordagem arquitetural baseada na divisão de sistemas de software em unidades menores, denominadas components. Estas unidades devem respeitar alguns princípios, muitos deles herdados do desenvolvimento orientado a objetos (OO).

138 Qual a diferença entre Componentização e Modularização? Componentes devem respeitar o princípio básico da orientação a objetos de combinar funcionalidade de dados no contexto da mesma unidade (o componente). Além de outros princípios como baixo acoplamento, alta coesão, dependências orientadas a interfaces.

139 Componentização em outras indústrias Na indústria automobilística: Peças de um motor Suspensão produzida por uma fábrica e utilizada na montagem Peças pré-fabricadas Na construção civil: Blocos de concreto Estruturas metálicas...

140 Riscos Indústria trabalha com produção em série (potencial de reúso é maior) Desenvolvimento de software muitas vezes é sob medida (mesmo quando fazemos uma implantação de produto ERP por exemplo) Objetivo do software geralmente é mais intangível que um produto físico Software é mais maleável Desta forma, exige-se mais agilidade de software do que de novos modelos de carros Um edifício, depois de construído, não pode chegar mais meio metro para a esquerda

141 Criação de produtos sob medida Processo de fabricação e design originais Peças padronizadas (componentes) Ex.: Fabricação de roupas sob medida Isso nos leva a pensar quanto mais básico o componente maior a sua chance de reuso

142 No cenário atual dos negócios, com muitas mudanças, muita instabilidade, fusões, aquisições, a única certeza é a da mudança. Soma-se isso uma indústria de software imatura. Amadurecimento implica em: Maior agilidade Maior produtividade Sem perder a qualidade

143 Benefícios da Componentização Controlando o impacto da mudança Também conhecido como controlando a complexidade do software Para que a mudança seja ágil e com poucos efeitos colaterais Ex.: empresas que atendem a necessidades semelhantes em vários de seus clientes

144 Benefícios da Componentização Controlando o impacto da mudança Novas versoes causam menos efeitos colaterais = maior agilidade Potencializando o reuso Menos codificação = Mais produtividade Código mais testado = Mais qualidade

145 Como aumentar a produtividade Trabalhar mais rápido (Ferramentas): 8% Trabalhar mais inteligentemente (Processo): 17% Evitar retrabalho (reuso): 47%

146 Minha empresa nunca vai reutilizar esses componentes!! OK! Mas você vai usufruir do benefício do controle da complexidade do software Você conseguirá evoluir mais rápido a sua aplicação O número de efeitos colaterais será menor

147 Mudança Aspectos de mudança de mentalidade: Envolvimento do nível gerencial; Rápida comprovação de resultados; Estratégia de comunicação efetiva; Política de incentivos/metas relativos a componentização e reuso.

148 Mudança Integrando a componentização e reuso ao seu processo de desenvolvimento Promover coleta e identificação de novos componentes nos projetos; Definir o papel do grupo de administração de componentes e sua interação com os outros grupos da organização Encorajar o reuso efetivo em projetos

149 Reuso Maior Dentro de uma mesma empresa Ex.: reuso de componentes entre sistemas distintos dentro de uma empresa de manufatura Empresas de TI com foco em produção de produtos Ex.: ERP, CEM, etc