Consideremos um problema de integração ad-hoc entre duas empresas sobre um canal seguro. A empresa B precisa disponibilizar informações sobre estoques de seus produtos criados em uma aplicação ASP.NET MVC. A empresa A precisa consumir estas informações sincronamente (RPC) em uma aplicação Java EE. Os desenvolvedores nas empresas A e B conhecem suas tecnologias de desenvolvimento e o protocolo HTTP.

Um arquiteto de integração é exposto a três soluções possíveis de RPC:

1. Criar uma API sobre SOAP/HTTPS, expor os serviços da empresa em WSDL e criar objetos de dados complexos em XSD.

2.Expor a API  sobre protocolo HTTPS através dos métodos GET/POST em um mecanismo REST.

3. Criar uma comunicação CORBA sobre GIOP/IIOP a partir do uso de COM+ ou WCF em .NET e consumir o objeto remoto através de um EJB (RMI/IIOP).

A lei da parcimônia nos diz para escolher a solução 2 neste contexto, dada que é a mais simples e irá resolver o problema sem a adição de mais complexidade à solução.

Se houver algum outra variável no problema, a solução é reavaliada naturalmente. Assumi no exemplo que nenhum outra questão se faz presente para tornar a explicação mais didática.A lei da parcimônia é antiga e foi formulada por Willian of Ockham ainda no século 14. Ele descreveu o princípio que é conhecido como lâmina de Occam, que diz  que a explicação para qualquer problema deve assumir apenas as premissas estritamente necessárias à explicação do fenômeno e eliminar todas as que não causariam qualquer diferença aparente nas predições da hipótese ou teoria. Em outras palavras, este princípio recomenda assim que se escolha a teoria explicativa que implique o menor número de premissas assumidas e o menor número de entidades na solução. Na arquitetura e desenho de software, este princípio nos diz que a solução mais simples para resolver um problema deve ser escolhida, quando temos diversas soluções para resolver uma determinada questão.

São contra-exemplos deste princípio:

• As famigeradas arquiteturas lasanhas do J2EE 1.3 e 1.4 com quase 10 camadas entre a tela  o banco de dados.
• Objetos de transferência TO/VO iguais aos objetos de domínio (POJO/POCO).
• Bancos de dados normalizados além da necessidade do problema.
• Padrões de desenho artificiais.
• Métodos/Funções com centenas de linhas de código.

Um bom exemplo da simplicidade aplicada é o método EssUP de Ivar Jacobson. Uma lâmina no contexto da essência arquitetural de um projeto é apresentada aqui para os interessados.

“We are to admit no more causes of natural things than such as are both true and sufficient to explain their appearances. Therefore, to the same natural effects we must, so far as possible, assign the same causes.”, Isaac Newton