Qual definição de sistema que você usa? Um frontend + backend? Como o termo sistema é muito genérico, depende da cultura da empresa, é comum que vários conceitos importantes - que deveriam ser isolados - ficarem no mesmo sistema. (exemplo) É interessante considerar - no caso de SOA - um sistema como uma camada de apresentação, e serviços/componentes como um backend compartilhado por vários sistemas (esses serviços são orquestrados por serviços orientados ao possesso ou por uma camada de aplicação).
Detalhando melhor:
Contexto
As empresas são grandes coleções de processos de negócio. Por isso, basicamente, estou falando de serviços para automação de processos de negócio com ferramentas BPMS, serviços básicos para encapsular as regras/dados do negócio e encapsular sistemas legado.
Para um projeto de desenvolvimento de sistema com qualidade não é necessária essa estratégia SOA. Não existe SOA para um sistema apenas. SOA resolve problemas corporativos visando flexibilidade.
Definição de serviço
Um serviço encapsula um ou mais backends. Na definição de backend, podemos ter subsistemas, componentes, sistemas ou outros serviços.
Existem muitas definições de backend no contexto de SOA, mas o importante é que ele representa uma instancia do negócio digitalmente (regras de negócio ou atividade do processo de negócio automatizado), portanto não podem ficar inconsistentes, seria melhor que fossem únicos e independentes.
Componentes de negócio com seus problemas e serviços
E comum tratarmos o backend de serviços básicos (ou algo parecido com serviços corporativos na definição de Erl) como componente de negócio.
O objetivo do componente de negócio é proteger as regras de negócio, evitando, sobretudo, a duplicidade - ou seja, primando para que, quando da modificação de alguma regra, seja possível obter um único ponto de alteração -, os componentes de negócio (subsistemas) são normalmente identificados decompondo-se o domínio, e disponibilizados como um recurso corporativo.
Na prática, a implementação de tal ponto singular, não é simples e muitos casos inviável. Dois motivos básicos para essa conclusão:
Primeiro, seria necessário uma harmonização dos conceitos da empresa. Exemplo, todos os sistemas deveriam entender o conceito de negócio ?produto? da mesma forma, mas em função do legado e da falta de análise, temos em um ambiente corporativo com várias semânticas para o mesmo conceito, no caso de ?produto?, poderia significar coisas diferentes em sistemas/serviços diferentes. Harmonizar e unificar esses conceitos e em muitos casos inviável.
Segundo, existe duplicação de conceitos em sistemas diferentes, replicando muito as regras de negócio. A duplicação de regras é muito comum, em função: do legado; da forma de desenvolvimento sem considerar o processo de negócio (que traz uma visão interdeparmental); integração baseada em bases de dados corporativos; e outras questões… (Conceitos importantes com relacionamento forte (agregação ou composição) separados em sistemas diferentes, também é um problema para evitar replicação de código).
Os serviços básicos (componentes de negócio ou não) como suas inevitáveis duplicações de conceitos/regras e inconsistências, normalmente são encapsuladas/controladas em serviços compostos e em serviços orientados a processo de negócio.
Conclusão
Mesmo com todas as dificuldades os componentes de negócio isolados e pouco acoplados deveriam ser uma meta/um norte para arquitetura. Por isso a importância de técnicas decomposição do domínio e decomposição do processo de negócio para identificação de serviços em sistemas como a estratégia SOA.
Trabalho em uma empresa que tem hoje 200 sistemas em desenvolvimento (automatizando partes diferentes de uma grande processo de negocio, exemplo “vender seguro”, compartilhando com isso muitos serviços que possuem muitas regras), o efeito acumulativo de conceitos e regras duplicadas, são refletidos em pouca flexibilidade para o negócio, ou seja, dificuldade para assimilar mudanças. SOA ajuda efetivamente controlar essas questões.
Na prática é muito difícil que uma equipe comprometida com os resultados do projeto tenha tempo ou interesse de usar essa estratégia SOA, que não traz muitos benefícios imediatos para o projeto (talvez reuso), apenas traz benéficos significativos se pensarmos corporativamente e no efeito acumulativos da abordagem. Por isso governanca é importante para SOA.