Nosotros todavía no tenemos un criterio único.
Ahora mismo registramos interfaces de forma descentralizada y eso genera duplicidades.
Estamos pensando en definir reglas de nomenclatura y acordar qué interfaces merece la pena mantener para que no se convierta en un esfuerzo insostenible.
Me encantaría ver qué buenas prácticas usáis en otras empresas.

Gracias - Muy buena pregunta

Nosotros empezamos con un prefijo de DF (Data Flow) para interno y otro para DX (Data Exchange) cuando enviamos a otra compañía. Y hemos includio en el nombre de la interface el nombre de la applicación que envia y luego la applicación que recibe la data.

Espero que esto sea una ayuda inicial - y que otros compartan sus experiencias.

 

en mi caso, estamos usando la api de integración, de forma que las interfaces que una aplicación consume estén lo más actualizadas

Buenos días Carmen,

Algunas best practices que tenemos al tratar las integraciones.

Nomenclatura: 

Tenemos la norma siguiente para nombrar una integración y poder identificar rápidamente de que se trata.

“ApplicationProvider_DataObject_ApplicationConsumer”. Por ejemplo: “SAP LeanIX_Applications_ServiceNow”.

De esta manera se identifica las aplicaciones involucradas y el contenido.

Efectivamente, al leerlo en un diagrama, se complicará, pero se puede utilizar otros campos para mostrar en los diagramas, no tiene que ser el “Nombre del objeto”, nosotros utilizamos el “Data object” o el “Alias” para tener mas flexibilidad y que se pueda leer fácilmente.
 

Volumen: 

Efectivamente, es un reto, se necesita manejar las expectativas. No se puede tener todo de un golpe. Nosotros, hemos empezado con las integraciones de las aplicaciones que estan dentro del perimetro de nuestros programas de transformaciones, y poco a poco, intentamos ampliar el perimetro.
Consistencia: 

Hacemos uso del quality seal, con atributos y relaciones obligatorios. Os recomiendo utilizar las subscripciones y tener la aplicación “application provider” y “application consumer” como una relación obligatoria. El responsable de la aplicación de destino recibirá una notificación en este caso y vera la integración asociada a su aplicación también. 

Saludos,

Simon Sztabholz

Simon,
Gracias por compartir tu experiencia.

Me sorprende que incluyas el nombre del “Data Object” en el nombre de la interface - a veces tenemos interfaces que comunican mas de un “data object”…...En LeanIX puedes relacionar mas de un “data object” a la misma interface ..

Oigo entonces que todo depende que tan granular estas modelando los data objects (por ejemplo, tienes una “hierarchy” de data objects (parent/child)?)

Gracias a todos por contribuir a esta conversación.
Moise

Hola Moise,

Los datos objects para nosotros representa solamente la capa conceptual (lo que llamamos nosotros el Common Information Model de nuestra compania), no entramos en el detalle de la capa lógica y física de los objetos de datos. Puede ser que haya mas du objeto de dato conceptual, y entonces lo incluimos en el nombre, pero si efectivamente tenemos jerarquía entre los objetos y no utilizamos LeanIX como “System of Record” para las capas inferiores.

Simon

Simon,
Gracias por explicar - Cada compañia es distinta en sus objetivos con LeanIX.
 

Si te entiendo correctamente, estan usando el LeanIX para modelar el 
Common Information Model de su compania?

Hola ​@hell surfer , 

¿Podrías compartir más detalle sobre esta api de integración? No la conozco, pero si hay alguna forma de automatizar el esfuerzo de creación y manteniemiento de las interfaces, creo que merece la pena intentarlo.

Gracias por tu aportación!