Bom dia.
O meu nome é Filipe Santos e sou Enterprise Architect na Galp.
Estamos neste momento a modelar as nossas Interfaces em LeanIX e estamos num dilema onde, possivelmente, alguns de vocês também estão ou já estiveram.
Em termos de interfaces “técnicas” - o subtype existente API e mais alguns que criámos, por exemplo, para eventos -, temos como principal objectivo mapeá-las para criar um custom portal que servirá como “O” catálogo de serviços reutilizáveis. Nestas fact sheets serão mapeados os serviços expostos na camada de integração.
O nosso dilema prende-se com onde devemos parar. Devemos mapear apenas os serviços expostos na camada de integração? Ou devemos ir um passo mais além e mapear também os serviços backend dos quais cada serviço de integração depende?
Seria utilizada a relação “requires” para identificar que um serviço de integração depende de um ou mais serviços backend. Com isto, conseguiríamos ter uma visão mais rápida e clara do impacto que alterar o serviço A ou B do backend system X ou Y teria no nosso landspace.
Se por um lado ganhamos uma visão que hoje em dia não temos sem dispensar várias horas de várias equipas; por outro estamos a trazer complexidade técnica para dentro do LeanIX e, potencialmente, a cair no antipattern para o qual a própria LeanIX alerta na documentação:
“Don't try to reflect the full technical complexity of the Interface, but focus on the business question that you are trying to answer. SAP LeanIX Diagrams, etc., are built with a business perspective in mind, focusing on the logical layer rather than on a technical-physical layer.”, em https://help.sap.com/docs/leanix/ea/interface-modeling-guidelines
Já se depararam com este dilema? Qual a vossa opinião e que caminho seguiram/seguiriam?
