Componentes vs Servicos

3.576 visualizações

Publicada em

Uma comparação entre duas abordagens de desenvolvimento de software: componentes serviços.

Publicada em: Tecnologia, Negócios
0 comentários
7 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.576
No SlideShare
0
A partir de incorporações
0
Número de incorporações
30
Ações
Compartilhamentos
0
Downloads
154
Comentários
0
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Script:Let’s dig into what it means to be an on demand business. It is all about business processes. Let’s take a look at a division in a company and its Order-to-Cash process. Notice this is a divisional process. Many companies have autonomous divisions all with their own processes and ways to execute. Let’s not pay any attention to how the IT department may implement this process yet. Let’s just look at what is happening in the business.Within the Order to Cash process there are multiple business functions involved (roughly represented by different color blocks here). There is marketing and catalog management, order entry, inventory management, fulfillment and delivery logistics, accounting and receivables, and reconciliations, audit, and business intelligence.In the past, the division in the company may have taken care of all of these business functions all internally.This has changed.
  • Script:With the emergence of the internet, customers can now access you directly via the web. Customer self-service is the order of the day. This started with Amazon and Dell, but its applicable to every business today. So this part of the business process has moved to the customer, it may be through a web interface you provide or for businesses, it may be direct access to your systems via a web service. Regardless of the technology, the key is that customer’s are now directly invovled in the business process as opposed to all the interaction being through a customer service agent.
  • Script:Many companies are examining how they do business internally, if they have the scale of a multi-divisional organization they often determine that different parts of their business actually do the same thing, many times over and over and haven’t taken advantage of the organization’s scale or haven’t taken advantage of specialization. This can often times be infuriating to customers because each division acts and operates with different policies and procedures.The solution to this problem is a Shared Services organization – organizations that are set up to perform functions common across the organization – in this example, we’ve show:Marketing– email generation that should represent consistency company branding, and may require specialized expertise that individual divisions do not have.Billing – common billing, often into a consolidated billReceivables – common receivables – common credit status, visibility across the entire organization.So, now, the divisional process must be modified to take advantage of the shared services of the company in order to consolidate the customer experience and to obtain economies of scale over common business functions.Another change might be
  • Script:If you take a look at inventory, many organizations are looking for ways to minimize or eliminate the inventory they have to manage. Over time, the concept of vendor managed inventory has emerged where the vendor is actually responsible for all of the inventory functions. This requires exchanging consumption information with the supplier, but it enables this organization to handle this function and reduce an organization’s costs and also get better service at lower costs.Another change might be
  • Script:Shipping – who is really good at shipping and logistics? Well companies like FedEx, DHL, and UPS excel in these areas. Often times, they have capabilities you couldn’t even imagine of. You can make them part of the business process.Another change might be
  • Script:Outsourcing – most organizations are examining what they do well and what others to better. For those functions that are not strategic differentiators and where others do them better, outsourcing is an answer. You can move part of the business process to an outsourcer.These last two charts emphasize one of the principles of On Demand which is to concentrate on your Core Competencies. Only those things that give your company a competitive advantage.Another change might be
  • Script:Not all changes involve moving work outside of your organization. Through analytics, you can identify bottlenecks in your processes. You can identify areas where you have high costs. Areas for improvements. For these, you want to have the flexibility to optimize your business processes maybe different flows for different types of customers.In this case, the division may decide that there are high value customers for which if there is a collection issue, the company wants to handle that situation themselves and not send it to an outside collection firm. Therefore, Business Rules and Policies must come into play when executing these processes.What is clear is that the rate of change keeps increasing and the need for speed, flexibility and adaptability to change is becoming more important. The Conference Board, an organization providing research for leading companies, recently did a survey of 539 CEO’s who were asked to rate their Top 10 challenges. Number 2 in the survey was “speed, flexibility, adaptability to change”. Interestingly this concern exists across companies of all sizes, for companies with revenues from $100M to $1B it was ranked number 3, just a hair behind Customer Loyalty and Retention. For companies >$1B in revenue, it became the number 2 concern after “sustained and steady top line growth” (you think we’re all driven by all street?)
  • During this time, applications have become increasingly structured by adding ‘tiers’However, the shift to client/server and n-tier did not necessarily introduce better structure and separation into applications than had already been achieved with structured programming developed in the mainframe era.Dependencies across tiers was not just on the need to use the same platform and technology.Dependency was also often introduced in the application logic – rules were distributed across tiers, often with the client logic and server inseparable This made reuse, and maintenance difficult.Reuse, and composition from existing composition was difficult to achieve.Partly this is attributable to RAD which focused on immediate results rather than lasting structure through proper analysis and design, and on the client side of the system.
  • Instead of monolith architectures which cover the whole project, we need to break the architecture down into several areas to reflect the different consumer and provider domainsApplication – The business process, and services requiredService architecture –The services, service buses (we will come to this later)This maintains the relationship between implementations and serviceComponent Architecture – The business objects and their implementationThese architectures can be viewed from either the consumer or provider perspectiveThe consumer of a service should not be interested in the implementation detail of the service – just the service provided.The implementation architecture could vary from provider to provider yet still deliver the same service.Similarly the provider should not be interested in the application that the service is consumed in.New unforeseen applications will reuse the same set of services
  • This was overcome by moving to object and component technology.This re-introduces better structure and separationIt also focuses on the use of proper interfaces to encapsulate functionalityHowever, though components promise long term speed and adaptability through reuse, they still do not necessarily deliver on the immediate results that business demands.Therefore, common short cuts in component analysis and design subsequently prevent reuse benefits being achieved.Additionally, technology dependence remains.COM only talks to COM, CORBA only talks to CORBA and so on.Again whilst some measure of interoperability is possible with bridges, it remains technically difficult, and is not often used.And so we come to XML Web Services (More on this later)These remove the technology dependence between consumer and providerThey provide well documented interfaces, enabling reuse without requiring intimate knowledge of how the service is implemented
  • This was overcome by moving to object and component technology.This re-introduces better structure and separationIt also focuses on the use of proper interfaces to encapsulate functionalityHowever, though components promise long term speed and adaptability through reuse, they still do not necessarily deliver on the immediate results that business demands.Therefore, common short cuts in component analysis and design subsequently prevent reuse benefits being achieved.Additionally, technology dependence remains.COM only talks to COM, CORBA only talks to CORBA and so on.Again whilst some measure of interoperability is possible with bridges, it remains technically difficult, and is not often used.And so we come to XML Web Services (More on this later)These remove the technology dependence between consumer and providerThey provide well documented interfaces, enabling reuse without requiring intimate knowledge of how the service is implemented
  • This was overcome by moving to object and component technology.This re-introduces better structure and separationIt also focuses on the use of proper interfaces to encapsulate functionalityHowever, though components promise long term speed and adaptability through reuse, they still do not necessarily deliver on the immediate results that business demands.Therefore, common short cuts in component analysis and design subsequently prevent reuse benefits being achieved.Additionally, technology dependence remains.COM only talks to COM, CORBA only talks to CORBA and so on.Again whilst some measure of interoperability is possible with bridges, it remains technically difficult, and is not often used.And so we come to XML Web Services (More on this later)These remove the technology dependence between consumer and providerThey provide well documented interfaces, enabling reuse without requiring intimate knowledge of how the service is implemented
  • This was overcome by moving to object and component technology.This re-introduces better structure and separationIt also focuses on the use of proper interfaces to encapsulate functionalityHowever, though components promise long term speed and adaptability through reuse, they still do not necessarily deliver on the immediate results that business demands.Therefore, common short cuts in component analysis and design subsequently prevent reuse benefits being achieved.Additionally, technology dependence remains.COM only talks to COM, CORBA only talks to CORBA and so on.Again whilst some measure of interoperability is possible with bridges, it remains technically difficult, and is not often used.And so we come to XML Web Services (More on this later)These remove the technology dependence between consumer and providerThey provide well documented interfaces, enabling reuse without requiring intimate knowledge of how the service is implemented
  • We believe it is therefore appropriate that we combine both SOA and CBD into what CBDI call Component Based Service Engineering – CBSEComponents deliver a set of benefits to certain audiences (e.g. the Service provider who must build and maintain the implementation)Services deliver another set, perhaps of greater benefit to a different audience – such as the service consumer, who is not interested in the implementation architecture per seCombining them both is essential to delivering the true agility and productivity benefits claimed of SOA and CBD
  • Componentes vs Servicos

    1. 1. Componentes vs. Serviços Marcelo Sávio Senior IT Architect IBM 1
    2. 2. O problema • A mudança: Uma constante no mundo dos negócios; Fusões, aquisições, regulamentações de mercado, globalização, outsourcing, novas tecnologias, etc.; No longo prazo, quase todos os aspectos de um negócio são suscetíveis a mudanças. 2
    3. 3. IBM Global CEO Study 2008 O conhecimento coletivo dos CEOs apontou para os principais desafios da “Empresa do Futuro” Sumário do resultado das 1.130 entrevistas: As organizações são bombardeadas por mudanças, e muitas delas estão lutando para sobreviver; Os CEOs vêem os clientes cada vez mais exigentes não como ameaças, mas como uma oportunidade para se diferenciarem; Quase todos os CEOs estão adaptando seus modelos de negócio. E dois terços estão implementando grandes inovações; Os CEOs estão mudando agressivamente para projetos globais de negócio, alterando profundamente as capacidades e criando parcerias mais amplas. 1 2 3 4 5 Ávida por Mais Globalmente Desbravadora Genuína, mudanças inovadora integrada por natureza não que a apenas imaginação generosa dos clientes 3
    4. 4. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Depto. 4
    5. 5. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Mudança: Entrada de pedido de cliente via Web 5
    6. 6. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Mudança: Serviço compartilhado – ex. marketing, faturamento, jurídico 6
    7. 7. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Mudança: Fornecedor passa a cuidar do estoque 7
    8. 8. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Serviço Terceirizado Mudança: Entrega através de serviço de correio 8
    9. 9. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Serviço Terceirizado Mudança: recall terceirizado 9
    10. 10. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Serviço Terceirizado Mudança: Otimização de processo interno 10
    11. 11. Os desafios dos profissionais de TI Como ser mais ágil Como suportar no desenvolvimento modelos de negócios de novos produtos? em constante mutação? Como diminuir os custos de desenvolvimento e manutenção? 11
    12. 12. As perspectiva técnica da mudança • Para os desenvolvedores, mudanças têm sido consideradas como um mal a ser evitado, ao invés de uma oportunidade a ser explorada; • Por outro lado, a capacidade de lidar com mudanças significativas no design e no comportamento de um sistema ao longo do seu ciclo de vida é o principal diferenciador da engenharia de software das outras engenharias; • Flexibilidade É o termo geral que descreve a capacidade de um sistema de se adaptar às mudanças: Flexibilidade no momento do design: Absorção de mudanças no software (não apenas no código) minimizando os custos (tempo e esforço); Flexibilidade no momento do runtime: Absorção de mudanças nos requisitos sem mudanças no código. • Diversas abordagens de desenvolvimento e arquiteturas de sistemas surgiram ao longo dos anos para endereçar as constantes necessidades de mudanças. 12
    13. 13. Evolução das aplicações Sistemas Sistemas Sistemas Sistemas em Monolíticos Estruturados Cliente/Servidor três camadas Apresentação Apresentação Apresentação Apresentação Lógica de Negócio Lógica de Negócio Lógica de Negócio Lógica de Negócio Dados Dados Dados Dados Pouca estruturação Estruturado, mas Distribuído Mais distribuído ou separação ainda fisicamente fisicamente, porém de fisicamente, porém de monolítico. uma forma menos uma forma não muito Dependência estruturada do que a bem estruturada e ainda tecnológica Dependência anterior e com com dependências tecnológica dependências lógicas lógicas entre as entre as camadas. camadas. Dependência Dependência tecnológica tecnológica Tempo 13
    14. 14. Evolução das aplicações • As metodologias de desenvolvimento de software mais pragmáticas (e modernas) acreditam no processo incremental, no qual a mudança é um aspecto inevitável e pode ocorrer em qualquer estágio de um sistema; • Os sistemas precisam estar em constante evolução e a separação entre o desenvolvimento e a manutenção de um sistema tornou-se cada vez menos significante; • Duas abordagens (recentes) para design de software surgiram com a capacidade de alavancar o reúso e suportar a evolução contínua dos sistemas: Componentes (Distribuídos) Serviços Apresentação Apresentação Lógica de Negócio Lógica de Negócio Dados Dados 14
    15. 15. Algumas idéias (clássicas) que levaram ao uso de componentes/serviços • Subrotinas 1949, Alan Turing “Checking a Large Routine” • Componentes de software 1967, Ivar Jacobson (então funcionário da Ericsson) propôs o uso de componentes de software no design da nova geração de switches telefônicos controlados por computador. • Disseminação do uso de componentes de software na indústria de TI 1968, Douglas McIlroy (Conferência da OTAN sobre Engenharia de Software) “Mass Produced Software Components” • Libraries 1971, Numerical Algorithms Group (NAG) Libraries para FORTRAN e ALGOL • Information Hiding 1972, David Parnas “On the Criteria to Be Used in Decomposing Systems Into Modules” • Separation of Concerns 1974, Edsger Dijkstra "On the role of scientific thought" • Design by Contract 1986, Bertrand Meyer “Technical Report TR-EI-12/CO” 15
    16. 16. Componentes vs. Serviços • Discussão típica da introdução de um novo paradigma; • A história das mudanças de paradigma na ciência e na tecnologia é repleta de situações semelhantes; • Alguns exemplos no mundo do desenvolvimento de sistemas: Componentes vs. Objetos; Objetos vs. Programação estruturada; Programação estruturada vs. Programação procedural; Programação de alto nível vs. Programação de baixo nível; etc. 16
    17. 17. Componentes vs. Serviços • Filosofia: A idéia do desenvolvimento baseado em componentes é a de “industrializar” o processo de desenvolvimento de software, através da “assemblagem” de componentes pré-fabricados; No modelo de serviços há uma total separação lógica entre uma necessidade e seu respectivo mecanismo de atendimento (baixo acoplamento); O conceito de serviço difere do de componente pelo fato de que um serviço não define nenhuma limitação estrutural, a não ser a sua interface. 17
    18. 18. Componentes vs. Serviços • Binding: Uma característica comum a ambos é que as partes de um sistema podem ser desenvolvidas separadamente e adicionadas ao sistema posteriormente; Ainda que os modelos orientado a componentes e serviços compartilhem características comuns, existem diferenças: Um software cujo desenvolvimento tenha sido orientado a componentes adota o early-binding dos componentes, ou seja, a unidade responsável pelas chamadas sabe exatamente quais componentes deverão ser contactados antes da execução; O desenvolvimento orientado a serviços adota uma abordagem mais flexível, na qual o binding acontece no momento de execução (late- binding), o que permite a mudança da fonte de aprovisionamento do serviço a cada momento de execução. 18
    19. 19. Componentes vs. Serviços • Granularidade e abstração: A granularidade é um conceito relativo. Refere-se à escala dos artefatos que precisam ser mudados, variando dos mais genéricos (coarse grained) aos bem específicos (fine grained); O paradigma da orientação a objetos não foi suficiente para lidar com as mudanças (too fine grained e não havia uma separação clara entre os aspectos computacionais e a composição dos objetos). Os componentes então foram propostos, de forma a encapsular os detalhes computacionais de um conjunto de objetos; Em relação aos componentes, os serviços possuem um grau de abstração ainda maior, no qual são representadas atividades do mundo real ou funções de negócio. Os serviços normalmente possuem uma granularidade relativamente genérica e suportam um único conceito ou processo de negócio. 19
    20. 20. Níveis de abstração Serviço Abstração Componente Classe 20
    21. 21. Componentes vs. Serviços • Mecanismo de distribuição: No modelo de componentes, a produção de software é orientada a produto, podendo inclusive ser entregue em algum formato de mídia; No modelo de serviços as funcionalidades de software são entregues como serviços, os quais, quando são requisitados, têm seus elementos identificados, seus termos e condições negociados, é executado e depois “descartado”. Esse modelo oferece uma maior flexibilidade para lidar com mudanças. 21
    22. 22. Componentes vs. Serviços • Arquitetura: Uma arquitetura de componentes é uma especificação de um conjunto de interfaces e regras de interação que governam a comunicação entre componentes. A maioria das arquiteturas de componentes possui um forte acoplamento entre seus elementos (ex. CORBA); Uma arquitetura orientada a serviços (SOA) permite projetar sistemas de software capazes de prover serviços para aplicações (ou outros serviços) através de interfaces publicadas e descobertas automaticamente. Os consumidores dos serviços são desacoplados dos provedores, normalmente intermediados por um broker; Tipicamente uma camada de serviços é montada sobre uma camada de componentes. 22
    23. 23. Tipos de arquitetura Consumidor Arquitetura de Aplicação Arquitetura de Serviços Provedor Arquitetura de Componentes 23
    24. 24. Desafios comuns Para alcançar flexibilidade através de componentes ou serviços é necessário transpor desafios (técnicos e não técnicos): • Confiança: No contexto de software significa que o componente ou serviço irá prover todas as obrigações funcionais e não-funcionais conforme “prometido” em sua descrição. Testar um componente ou serviço pela análise de seu código não é algo prático. Mudanças no código podem invalidar a especificação contratual de um componente ou serviço. Os componentes, mesmo de origem desconhecida, podem ser testados diversas vezes antes de serem usados. A seleção ocorre no momento de design de um sistema, o qual poderá, posteriormente, necessitar alguma adaptação (“glue code”); No desenvolvimento baseado em serviços, a descoberta e seleção de serviços ocorre no momento de execução, o que torna o “testar-antes-de-usar” praticamente impossível, já que a origem de um serviço, assim como suas condições de uso podem variar entre duas invocações consecutivas. Adicionalmente é necessário monitorar o SLA (Service Level Agreement), o que se torna mais complicado quando o serviço é composto por outros serviços. 24
    25. 25. Desafios comuns • Gerenciamento da composição: Um dos grandes avanços no desenvolvimento de software diz respeito à capacidade de criar sistemas através da composição de elementos pré-existentes. Isso, entretanto, gera preocupações com a gestão dessa composição: Fazer um sistema através da composição de um certo número de componentes é algo relativamente controlável, quando comparado com a composição dinâmica que acontece em uma arquitetura de serviços; À medida que os provedores de serviço os expõem em um sistema distribuído, mais se torna inviável gerenciar e compor serviços manualmente; Quanto mais aberto (não controlado) for o ambiente distribuído, mais complexas serão as questões relacionadas à semântica das transações, aos mecanismos de rollback e ao licenciamento e cobrança por uso. 25
    26. 26. Desafios comuns • Especificação: Uma limitação importante na construção de software flexível está na maneira com a qual os componentes são especificados. Uso de padrões proprietários e de especificações dependentes da implementação são os principais inibidores para o desenvolvimento orientado a componentes alcançar os objetivos mais amplos de reúso; O principal ponto de uma arquitetura SOA é a especificação dos serviços e não a sua implementação, o que provê uma maior transparência e minimiza os impactos da mudança nos sistemas. A capacidade de descoberta automática existente no modelo de desenvolvimento baseado em serviços é o avanço mais significativo quando o comparamos ao modelo de desenvolvimento baseado em componentes. 26
    27. 27. Desafios comuns • Eficiência da implementação: Praticamente todas as mudanças de paradigmas trouxeram questões relacionadas à eficiência de implementação e já está melhor resolvido no desenvolvimento de componentes; O conceito de late-binding, que é crucial em uma arquitetura SOA, geralmente provoca overhead, especialmente se a descoberta e a seleção de um serviço acontecem a cada vez que as funcionalidades são invocadas. 27
    28. 28. Componentes vs. Serviços 28
    29. 29. Componentes vs. Serviços 29
    30. 30. Componentes vs. Serviços 30
    31. 31. Componentes vs. Serviços Componentes Serviços Apresentação Apresentação Lógica de Negócio Lógica de Negócio Dados Dados Estruturado e com separação Estruturado e com separação Encapsulamento e uso de Interfaces Encapsulamento e uso de Interfaces Uso requer conhecimento da Serviços bem descritos permitem o uso dinâmico implementação, portanto ainda há e sem a necessidade de conhecimento da dependência tecnológica implementação, proporcionando independência de tecnologia Organizações externas podem usar as mesmas interfaces, permitindo interoperabilidade e aumentando a flexibilidade. 31
    32. 32. Conclusão • A evolução é uma capacidade crítica no ciclo de vida de um software, particularmente quando esse software atende a domínios de negócio mais voláteis. Essa capacidade pode ser suportada tanto pelo desenvolvimento orientado a componentes quanto a serviços; • Componentes e serviços, ainda que tenham muitas similaridades, possuem diferentes filosofias e níveis de abstrações, que fazem do desenvolvimento orientado a serviços uma melhor abordagem para lidar com as mudanças; • Mas nem todo software é apropriado a ser desenvolvido baseado em serviços, sendo essa abordagem mais recomendada nos casos em que a mudança de requisitos é mais freqüente e a tolerância à ineficiência de implementação é maior; • O uso de componentes é uma ótima maneira de se implementar serviços (ainda que um sistema orientado a componentes “ideal” possa não resultar em um sistema orientado a serviços “ideal”); • Serviços não substituem os componentes, mas os complementam. 32
    33. 33. “Resumão” Componentes sem SOA SOA sem Componentes Benefícios Potenciais Benefícios Potenciais • As soluções de software são desenvolvidas • Serviços são desenvolvidos rapidamente, a partir rapidamente, a partir dos componentes existentes; das aplicações e pacotes existentes; • Economia de escala alcançável através do reúso • Oportunidades de reúso e economia de escala; dos componentes disponíveis; • Caminho mais fácil para futuras reengenharias. • A escolha de diferentes componentes pode render Potenciais desvantagens uma flexibilidade pré-implementação. • Inflexibilidade por trás das interfaces de serviço; Potenciais desvantagens • Aplicações e pacotes existentes preservam suas • Componentes são permanentemente “assemblados” limitações legadas; nas aplicações. É mais fácil “plugar” que “desplugar” • Questões de escalabilidade e portabilidade da • Falta de flexibilidade pós-implementação implementação; • Reengenharia talvez nunca aconteça. Componentes e SOA O verdadeiro potencial dos componentes e serviços ocorre quando combinamos essas duas abordagens: • Componentes e serviços assemblados com baixo acoplamento e re-acoplamento dinâmico; • Interfaces de serviços coerentes e suportadas por aplicações flexíveis baseadas em componentes; • Abordagem baseada em serviço se aplica tanto dentro quanto fora das aplicações; • Melhor atendimento aos requisitos de negócio com soluções sob-demanda mais escaláveis. 33
    34. 34. Referências bibliográficas • ELFATATRY, Ahmed. Dealing with Change: Components versus Services. Communications of the ACM (50:8), 2007, pp. 35-39. • BUDGEN, D., BRERETON, P., TURNER, M. Codifying a service architectural style. In Proceedings of the 28th Annual International Computer Software and Applications Conference, Hong Kong, 2004. IEEE, 16–22. • BENNET, K., LAYZELL, P., BUDGEN, D., BRERETON, P., MACAULAY, L., MUNRO, M. Service-based software: The future for flexible software. In Proceedings of the 7th Asia-Pacific Software Engineering Conference, IEEE, Singapore, 2000. • ORMAN, Levent, Service Semantics, Structure, and Design. Johnson School Research Paper Series No. 06-07. Cornell University, 2008. Disponível em http://ssrn.com/abstract=1019041. Vistado em 7 dez 2008. • MYERS, Ware, "Ivar Jacobson: Shaping Software Development," IEEE Software, vol. 19, no. 3, pp. 93-95, May/June 2002, doi:10.1109/MS.2002.10016 • WILKES, Lawrence, SPROTT, David. Understanding Service Oriented Architecture. CBDI Forum, 2004. Disponível em http://msdn.microsoft.com/en-us/library/aa480021.aspx. Visitado em 7 nov 2009. • IBM Global Business Services. The Enterprise of the future. CEO Study 2008. Disponível em http://www.ibm.com/enterpriseofthefuture. Visitado em 7 nov 2009. 34
    35. 35. Obrigado pela atenção Perfil Linkedin: http://www.linkedin.com/in/msavio Perfil Plaxo: http://msavio.myplaxo.com/ Repositório de palestras: http://www.slideshare.net/msavio/slideshows Blog: http://betarrabios.blogspot.com/ Twitter: http://twitter.com/msavio Repositório de textos: http://www.scribd.com/msavio 35

    ×