1. Componentes
vs.
Serviços
Marcelo Sávio
Senior IT Architect
IBM
1
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. 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. A necessidade de mudança nos processos de negócio
Ex: Processo de pedido de compra
Depto.
4
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. Tipos de arquitetura
Consumidor
Arquitetura
de Aplicação
Arquitetura
de Serviços
Provedor
Arquitetura de
Componentes
23
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. 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. 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. 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
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. 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. “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. 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. 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
Notas del editor
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