SOA Componentização e Reúso
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
Motivação Muito difícil de entender, manter e evoluir
Motivação Mundo de conexões Ponto-a-ponto Construímos rastros de ratos, decisões caso-acaso Visão de curto prazo
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
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
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
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
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
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
Dimensões
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
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
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
Como aumentar a produtividade? Trabalhando mais rápido (Ferramentas) 8% Trabalhando mais inteligentemente (Processos) 17% Evitando o trabalho desnecessário (Reúso) 47%
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)
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
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 9.3.4 Processo: gerencia de reutilizaçao (GRU)
Participação
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
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
Conceitos-Chave
Conceitos-chave Baixo acoplamento: Capacidade dos ativos de TI trabalharem integrados embora existam independentemente
Conceitos-chave Abstração: Permite que agentes humanos interajam com sistemas complexos de uma forma simples
Conceitos-chave <não dá pra ler!>: Elemento de software que encapsula o conhecimento e que pode ser reusado: Quais são os seus?
E como SOA se encaixa nesse contexto?
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
Stages of SOA adoption
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
Nem tudo são flores
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
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!!
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
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.
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
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
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)
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
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
Funcionamento Básico SOA
Dinâmica
Dinâmica É muito mais comum encontrar integração integração com ligação ponto-a-ponto usando Web Services
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
Agência de Viagens... Aqui tem que criar uma modelagem para uma agencia de viagens (está ilegível) + 2 slides similares tb
Como SOA vem Transformando Negócios
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
Amazon
Amazon
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
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?
Implementando SOA com Web Services
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
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.
Dinâmica de funcionamento Ex.: Submarino Loja virtual Ex.: Correios Tracking de pacotes
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...
Conclusão: Quem tem amigos não precisa de páginas amarelas
Governança SOA
Evitando acidentes
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
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
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.
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
Governança SOA
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
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
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
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
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
Praticando Tipos de Assets: Atributos:
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...
Ciclo de vida dos serviços Qual o diagrama de estados de um ativo? Identificado Em aprovação Disponível Em desenvolvimento Aposentado
Discussão Quais são os estágios que um serviço passa ao longo do seu ciclo de vida?
Roadmap de adoção e maturidade
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
Processo de implantação SOA Iniciation SOA Planning and Design SOA Implementation SOA Monitoring and Compliance
Níveis CMMI
Processos CMMI
Stages of SOA adoption
Para começar Pensar grande Começas pequeno Avançar rápido
Business Case SOA
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)
Business Case SOA Estrutura Básica: Dificuldades atuais / motivadores Benefícios buscados Plano de Implementação Investimentos necessários Conclusões
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!!
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
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)
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
Business Case SOA Investimentos necessários: Apresentar os investimentos que a empresa deverá fazer para conseguir ter sucesso em sua estratégia SOA
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)
Pré-Assessment SOA
Assessment SOA Objetivos: Fotografia da situação atual Avaliação de aspectos positivos e pontos de atenção.
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.
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
Exemplo Projeto Piloto Definição do projeto seguindo boas práticas Utilização da metodologia Metodologia sendo evoluída BLA BLA BLA coorporativo
Modus operandi Plano de trabalho: Entrevistas Questionário Decisões internas para oferecer o diagnóstico
Serviços: Identificação e Granularidade
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
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.
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
Alguns tipos diferentes de serviços: User Interface Services Process Composite Services Application Services Business Services Data Services Infrastructure Services Integration Services
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
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?
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
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
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
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
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
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
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
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
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.
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
Identificação dos serviços e design dos serviços WebServices = SOA The Silo Approach Misbehaving Repositories
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
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.
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.).
SOA Implementação / Realização dos serviços Chatty Services Point-to-point Services Component-less Services (also know as: Logical Layering is obsolete)
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.
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.
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.
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
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.
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.
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.
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.
Only-Code Reuse Acreditar que somente código pode ser reutilizado. Vimos que ativos são muito mais abrangentes que apenas código.
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.
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.
Production Before Consumption Desenvolvedores que tentam criar ativos reutilizáveis sem uma experiência significativa acabam criando ativos não-reutilizáveis.
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!
SOA: Componentização e Reúso
Componentização
Motivação Arquitetura de Software Componentes de Software UML Components Modelando a Interface de Componentes Modelando a Implementação do Componente Empacotando o Componente
Motivação
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
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).
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.
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...
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
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
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
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
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
Como aumentar a produtividade Trabalhar mais rápido (Ferramentas): 8% Trabalhar mais inteligentemente (Processo): 17% Evitar retrabalho (reuso): 47%
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
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.
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
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