En este apartado se describirán los conceptos básicos con los que el usuario puede trabajar en Anjana Data. No obstante, puede encontrar un Glosario al final de este manual con las principales definiciones.
Dominio de Datos, Unidad Organizativa o Unidad de Negocio
Es el mecanismo mediante el cual se establece la custodia del dato dentro del Glosario de Negocio o Catálogo de Datos, permitiendo representar la realidad de la organización en cuanto a los dominios funcionales de datos o semánticas.
Es importante no confundir la jerarquía organizativa o el organigrama de una organización con los dominios de datos. La estructura jerárquica de las organizaciones cambia constantemente y, por el contrario, los dominios de datos deberían ser bastante estáticos.
Los activos de datos se clasifican en las diferentes Unidades Organizativas (o dominios de datos) que se han identificado en la organización. De esta forma, los usuarios que desempeñan un rol en una unidad organizativa son responsables de los activos de datos que pertenecen a su unidad/dominio.
Metamodelo de Anjana
El conjunto de entidades y relaciones que se van a poder gobernar desde la Plataforma de Anjana Data es lo que se conoce como Metamodelo. Ese metamodelo es totalmente configurable, es decir, la organización tiene que realizar el ejercicio de definir una estrategia de gobierno en el que, entre otras cosas, define qué entidades quiere gobernar y qué tipos de relaciones quiere establecer entre los diferentes tipos de entidades para ofrecer la visión end2end de los datos.
Entidad
Es la representación de cualquier elemento de datos dentro del mapa semántico de la organización. Dependiendo de la naturaleza de las entidades, se clasifican en entidades del Glosario de Negocio (en el caso de que estén más relacionadas con el Negocio) o entidades del Catálogo de Datos (más relacionadas con TI).
En Anjana Data es posible crear tantos tipos de entidades como se desee definir.
Algunos ejemplos de entidades pueden ser términos de negocio, métricas, dimensiones, informes, procesos de negocio o reglas de calidad de datos.
Además, también es posible definir entidades que representan activos físicos como datasets, procesos o esquemas de BD.
Algunas de estas entidades son nativas de Anjana y sobre ellas la aplicación lleva a cabo cierta lógica especificada más adelante:
-
Dataset y dataset_fields
-
DSA
-
Proceso e instancia de proceso
-
Solución
Relación
Es el mecanismo que proporciona Anjana Data para establecer un enlace entre entidades que de algún modo se encuentran conectadas, ya sea por asociación, involucramiento, pertenencia, etc. Por ejemplo, relaciones entre términos de negocio que permiten calcular una métrica o las reglas de calidad de datos que aplican a un determinado informe.
Mediante las relaciones es posible establecer el ciclo de vida end2end de los datos, es decir, es posible gobernar el linaje técnico (cómo fluyen los datos por los diferentes sistemas de TI y qué transformaciones sufren), cómo se utilizan los datos con fines analíticos, la semántica asociada a los datos, dónde se aplican puntos de calidad para verificar la conformidad de los datos, o incluso qué usuarios están consumiendo ciertos datos.
Las relaciones permiten vincular entidades del Glosario de Negocio entre sí, pero también relacionar entidades del Glosario de Negocio con entidades del Catálogo de Datos para localizar, por ejemplo, dónde se almacena un determinado término de negocio.
Igual que ocurre con las entidades, en Anjana es posible configurar tantos tipos de relaciones como se necesite, que convivirán con el conjunto de relaciones nativas (o internas) de la aplicación. Estas relaciones nativas asocian entidades nativas entre sí y no son dadas de alta desde el wizard de creación de objetos si no por medio de funcionalidades propias de estas entidades. Estas relaciones son:
-
STRUCTURE: Relación entre un dataset y sus dataset_fields
-
DSA_CONTENT: Relación entre un DSA y las entidades que contiene
-
INSTANCE_PROCESS: Relación entre un proceso y sus instancias
-
INSTANCE_DATASET_IN: Relación entre una instancia y sus datasets de entrada
-
INSTANCE_DATASET_OUT: Relación entre una instancia y sus datasets de salida
-
SOLUTION_RELATED_INSTANCE: Relación entre solución y sus instancias relacionadas
-
SOLUTION_OWNED_INSTANCE: Relación entre solución y sus instancias propias
Objetos del Metamodelo del Catálogo de Datos
A pesar de la flexibilidad del metamodelo de Anjana Data y la posibilidad, por tanto, de crear tantas entidades como se desee representar, el metamodelo del Catálogo de Datos se basa en los siguientes objetos principales: datasets (y sus dataset_fields), DSAs, procesos (y sus instancias) y soluciones junto con sus relaciones, metadatos y linaje.
Dataset
Se trata de cualquier activo físico que contenga o represente datos, tanto estructurados como no estructurados, persistidos o no persistidos. Puede ser un fichero, una tabla, un documento, de cualquier tipo y formato.
Es el principal objeto a gobernar dentro del Catálogo de Datos. Lo que diferencia el Catálogo de cualquier Diccionario de datos es que puede ser enriquecido con metadatos técnicos y funcionales.
Dataset_field
En caso de que el dataset sea estructurado, éste se compone de un conjunto de dataset_fields. Cada dataset_field es un campo o columna del dataset que contiene su propio metadato.
DSA (Data Sharing Agreements)
Es un activo lógico que puede incluir una o varias entidades para facilitar la agrupación de activos físicos de datos en un nivel más cercano al consumo de la información.
Es el mecanismo mediante el cual se facilita el acceso a los datos gobernados y permite compartir datos entre proveedores y consumidores por medio de la firma de un contrato por el cual el usuario se compromete a cumplir unas condiciones de uso de los datos.
Es enriquecido con metadatos de negocio.
Proceso
Se corresponde con grupos de funciones definidas para extraer datos desde las fuentes, moverlos, transportarlos, transformarlos, explotarlos y/o generar nuevos datos (ETLs, scripts de transformación, ejecuciones de controles de calidad, generación de reportes…).
Instancia de Proceso
Un proceso puede tener una o más instancias en función de los diferentes escenarios de ejecución en base a posibles configuraciones que pueda tomar, con el fin de ejecutar los módulos de software desarrollados en distintas situaciones o plataformas.
Una instancia es una ejecución específica de un proceso con una parametrización y un conjunto de datasets de entrada y de salida. Permite la definición de las piezas de un framework sin necesidad de dar de alta un proceso para cada una de ellas. Una vez definida, cada ejecución es auditable.
Solución
La solución representa el “contrato de datos” que autoriza el movimiento de datos a través de los procesos. De esta forma, se garantiza que existen autorizaciones para el movimiento de datos entre sistemas o aplicaciones. Por tanto, es un activo lógico que engloba varias instancias de procesos junto con sus datasets relacionados para tener una visión end-2-end de las ejecuciones.
Una solución tiene un responsable de su administración y mantenimiento que garantiza su ejecución.
Los metadatos de la solución pueden ser enriquecidos con metadatos de negocio.
La diferencia entre las soluciones y los DSA es que las soluciones posibilitan el consumo por parte de los procesos de TI y las aplicaciones mientras que los DSAs gobiernan el consumo por parte de los usuarios consumidores.
Ciclo de vida de los objetos
Los objetos nativos de Anjana Data tienen su propio ciclo de vida, de forma que los objetos gobernados van pasando por diferentes estados que permiten realizar desde un gobierno pasivo tradicional a un gobierno activo con gestión de impactos.
A continuación se presenta el ciclo de vida por el que pasan los objetos en Anjana.
Ciclo de vida de las Entidades nativas de Anjana
Las entidades nativas de Anjana tienen un ciclo de vida diferente al de las entidades que no son nativas. En este apartado se presentan los estados por los que puede pasar una entidad nativa:
-
Importado: Las entidades creadas usando la Extracción Automática de Metadatos quedan en estado Importado.
-
Borrador: Si se modifica una entidad Importada para rellenar sus datos, pasa a estado Borrador.
Si se crea por medio de Subida de Excel o de creación Manual (ya sea usando la API o el propio portal), se crea una entidad nativa en estado Borrador.
Si se modifica una entidad Aprobada, se crea una nueva versión con estado Borrador.
Si se modifica una entidad Rechazada, ésta pasa a estado Borrador.
-
Pendiente: Una vez se envía la entidad a validar, pasa a estado Pendiente.
-
Aprobado: Si todos los validadores aprueban una entidad, ésta pasa a estado Aprobado. Si se vuelve a editar, se genera una entidad con dichos cambios en estado Borrador.
Una entidad con estado Desactivado puede volver a estar Aprobada tras la activación de la misma.
-
Rechazado: Si algún validador rechaza la validación de una entidad, pasa a estado Rechazado. Si se vuelve a editar para corregir los motivos del rechazo, vuelve al estado Borrador.
-
Deprecado: Si se realizan modificaciones significativas en una entidad nativa (lo suficiente para que se produzca un versionado de la misma), una vez sea aprobada la nueva versión de la entidad, la versión anterior pasa automáticamente a estado Deprecado.
-
Las reglas que deciden qué cambios generan una nueva versión son totalmente configurables, como se verá más adelante.
-
Además, es posible deprecar una entidad con el objetivo de indicar que, pasado un tiempo, expirará.
-
Expirado: Una vez se cumpla la fecha de expiración que se haya marcado en una entidad nativa, ésta pasa automáticamente a estado Expirado.
Versionado
El versionado de los activos tiene dos objetivos fundamentales:
-
Disponer de un mecanismo de control de impactos desde el punto de vista de la interoperabilidad, calidad, seguridad, protección de datos, etc.
-
Disponer de un histórico de versiones con los cambios más significativos.
La organización establece qué cambios en las plantillas de metadatos de las entidades nativas de Anjana deben generar una nueva versión del mismo.
Es posible configurar cualquiera de los siguientes casos:
-
Que se genere una nueva versión de un objeto cuando se produzca cualquier cambio en atributos significativos de la plantilla de un objeto.
-
Que versione un DSA cuando cambien las entidades a las que da acceso.
-
Que versione una instancia cuando se cambian los dataset input o output de la instancia.
-
Que versione una solución cuando cambien sus instancias relacionadas.
-
-
Que se produzca versionado cuando un atributo adquiere un valor concreto.
-
Que se genere una nueva versión del dataset cuando cambia un determinado atributo de un dataset field o se añade o elimina un dataset field.
-
Que se edite una entidad deprecada o expirada para la que no hay versión más actual aprobada.
Deprecación
La deprecación de las entidades nativas de Anjana desencadena una serie de cambios en los objetos y el lanzamiento de avisos a usuarios relacionados con ellos.
-
DATASET:
-
Sus dataset_fields serán deprecados
-
Los DSAs en los que está incluido NO serán deprecados
-
Las instancias a las que esté asociado NO serán deprecadas
-
Se enviará un aviso a los owners del dataset
-
Se enviará un aviso a los adheridos al DSA y a sus owners
-
Se enviará un aviso a los owners de las instancias relacionadas
-
-
DSA:
-
Se enviará un aviso a los owners de DSA
-
Se enviará un aviso a los owners de las entidades que contiene el DSA
-
Se enviará un aviso a los adheridos al DSA
-
-
PROCESO:
-
Las instancias asociadas al proceso serán deprecadas
-
Se enviará un aviso a los owners de proceso
-
-
INSTANCIA DE PROCESO:
-
El proceso relacionado con una instancia NO se deprecará
-
La solución propia NO se deprecará
-
Las soluciones relacionadas NO se deprecarán
-
Se enviará un aviso a los owners del proceso
-
Se enviará un aviso a los owners de las soluciones relacionadas
-
Se enviará un aviso a los owners de las soluciones propias (que son los owners de la instancia)
-
Se enviará un aviso a los owners de los dataset que la instancia escribe (DATASET_OUTPUT)
-
Se enviará un aviso a los usuarios adheridos de los dataset que la instancia escribe (DATASET_OUTPUT)
-
-
SOLUCIÓN:
-
Las instancias propias NO se deprecarán
-
Las instancias relacionadas NO se deprecarán
-
Se enviará un aviso a los owners de solución
-
Expiración
La expiración de las entidades nativas de Anjana desencadena una serie de cambios en los objetos y el lanzamiento de avisos a usuarios relacionados con ellos.
-
DATASET:
-
Si está gobernado, se procederá a eliminar sus permisos de acceso que se hayan incluido con DSAs
-
Sus dataset_fields serán expirados
-
Los DSAs en los que esté incluido NO serán expirados
-
Las instancias a las que esté asociado NO serán expiradas
-
Se enviará un aviso a los owners del dataset
-
Se enviará un aviso a los adheridos al DSA que contenga el dataset y a sus owners
-
Se enviará un aviso a los owners de las instancias relacionadas
-
Se enviará un aviso a los owners de las entidades relacionadas con el dataset y de los DSAs que contengan al dataset
-
-
DSA:
-
Si contiene entidades gobernadas se procederá a eliminar el grupo y todos los permisos que tuviera
-
Se enviará un aviso a los owners de DSA
-
Se enviará un aviso a los owners de las entidades que contiene el DSA
-
Se enviará un aviso a los adheridos al DSA
-
Se enviará un aviso a los owners de las entidades relacionadas con el DSA
-
-
PROCESO:
-
Las instancias asociadas al proceso serán expiradas
-
Se enviará un aviso a los owners de proceso
-
Se enviará un aviso a los owners de las entidades relacionadas con el proceso
-
-
INSTANCIA DE PROCESO:
-
El proceso relacionado con una instancia NO se expira
-
La solución propia NO se expira
-
La solución relacionada NO se expira
-
Se enviará un aviso a los owners del proceso
-
Se enviará un aviso a los owners de las soluciones relacionadas
-
Se enviará un aviso a los owners de las soluciones propias (que son los owners de la instancia)
-
Se enviará un aviso a los owners de los dataset que la instancia escribe (DATASET_OUTPUT)
-
Se enviará un aviso a los usuarios adheridos de los dataset que la instancia escribe (DATASET_OUTPUT)
-
Se enviará un aviso a los owners de las entidades relacionadas con la instancia
-
-
SOLUCIÓN:
-
Las instancias propias NO se expiran
-
Las instancias relacionadas NO se expiran
-
Se enviará un aviso a los owners de solución
-
Se enviará un aviso a los owners de las entidades relacionadas con la solución
-
Ciclo de vida de las Entidades no nativas de Anjana
Las entidades no nativas de Anjana pasan por los siguientes estados en su ciclo de vida:
-
Importado: Las entidades creadas usando la Extracción Automática de Metadatos quedan en estado Importado.
-
Borrador: Si se modifica una entidad Importada para rellenar sus datos, pasa a estado Borrador.
Si se crea por medio de Subida de Excel o de creación Manual (ya sea usando la API o el propio portal), se crea una entidad no nativa en estado Borrador.
Si se modifica una entidad Aprobada, se crea una nueva versión con estado Borrador.
Si se modifica una entidad Rechazada, ésta pasa a estado Borrador.
-
Pendiente: Una vez se envía la entidad a validar, pasa a estado Pendiente.
-
Aprobado: Si todos los validadores aprueban una entidad, ésta pasa a estado Aprobado. Si se vuelve a editar, se genera una entidad con dichos cambios en estado Borrador.
Una entidad con estado Desactivado puede volver a estar Aprobada tras la activación de la misma.
-
Rechazado: Si algún validador rechaza la validación de una entidad, pasa a estado Rechazado. Si se vuelve a editar para corregir los motivos del rechazo, vuelve al estado Borrador.
-
Desactivado: Si la entidad no nativa deja de tener sentido es posible desactivarla, pasando de estado Aprobado a estado Desactivado.
Ciclo de vida de las Relaciones
Las relaciones pasan por los siguientes estados en su ciclo de vida:
-
Importado: Las relaciones creadas usando la Extracción Automática de Metadatos quedan en estado Importado.
-
Borrador: Si se modifica una relación Importada para rellenar sus datos, pasa a estado Borrador.
Si se crea por medio de Subida de Excel o de creación Manual (ya sea usando la API o el propio portal), se crea una relación en estado Borrador.
Si se modifica una entidad Aprobada, se crea una nueva versión con estado Borrador.
Si se modifica una entidad Rechazada, ésta pasa a estado Borrador.
-
Pendiente: Una vez se envía la relación a validar, pasa a estado Pendiente.
-
Aprobado: Si todos los validadores aprueban una relación, ésta pasa a estado Aprobado. Si se vuelve a editar, se crea una relación con dichos cambios en estado Borrador.
Una relación Desactivada puede volver a estar Aprobada tras la activación de la misma.
-
Rechazado: Si algún validador rechaza la validación de una relación, pasa a estado Rechazado. Si se vuelve a editar para corregir los motivos del rechazo, vuelve al estado Borrador.
-
Desactivado: Si la relación deja de tener sentido es posible desactivarla, pasando de estado Aprobado a estado Desactivado.
Workflows
¿Qué son?
Los workflows representan la secuencia de pasos que se deben seguir para que una acción comenzada en Anjana por un usuario pueda ser validada por otros usuarios, estableciendo un entorno de trabajo colaborativo basado en roles.
Los workflows permiten materializar los procedimientos del modelo de gobierno de la organización y asegurar que todos los roles intervinientes en los procesos ejercen su responsabilidad, son informados y/o consultados.
Estas son algunas de sus características:
-
Los workflows son configurables y cada uno de ellos tiene un diagrama de estados propio
-
Cuando un usuario envía una solicitud en Anjana, automáticamente se genera el workflow correspondiente al rol del usuario y la petición realizada si no hay reglas configuradas que lo eviten
-
En cada workflow un usuario de cada rol asignado debe validar la solicitud para que pase a aprobada. En caso de que un usuario rechace la validación, el workflow quedará automáticamente cancelado
-
Cada estado del workflow implica la revisión y validación de la petición por uno o más usuarios dependiendo de sus roles y del tipo de petición. Esta revisión se materializa con la aprobación o el rechazo del validador al workflow
-
Las validaciones siempre irán acompañadas de un comentario del usuario indicando el motivo de su respuesta
-
Es posible que se lancen workflows en Anjana con más pasos de los que finalmente se validarán. Los intervinientes en el flujo de aprobación pueden variar en función de:
-
El rol del usuario que lanza el flujo de validación
-
El usuario que lanza la validación
-
El tipo de acción bajo validación
-
El tipo de objeto bajo validación
-
El subtipo de objeto bajo validación
-
Atributos de la plantilla del objeto bajo validación
-
La decisión del validador
-
La unidad organizativa del objeto
-
La versión del objeto
-
Identificadores de los objetos
-
Nombre de los objetos
-
-
Todas las acciones llevadas a cabo en los workflows serán auditadas pudiendo identificar a los distintos validadores, fechas, comentarios y respuestas.
Gracias a la utilización de los workflows en Anjana, se pueden automatizar procedimientos de Gobierno de una forma ágil y sencilla garantizando el seguimiento completo y la trazabilidad de cada petición.
Workflows a configurar
Los workflows utilizados en Anjana son configurables por tipo de objeto (tipo de entidad o tipo de relación), acción (creación, modificación, adherencia…) y por rol que envía la solicitud.
Para poder implementar la lógica completa de Anjana, es necesario definir los siguientes workflows:
-
Workflows de creación de cualquier ENTIDAD y RELACIÓN definidas
-
Workflows de deprecación manual de DATASET, DSA, PROCESO, INSTANCIA DE PROCESO Y SOLUCIÓN (entidades nativas de Anjana)
-
Workflows de adherencia al DSA
-
Workflows de modificación (con o sin versionado) de cualquier ENTIDAD y RELACIÓN definidas
-
Workflows de cambio de unidad organizativa de cualquier ENTIDAD definida
-
Workflows de activación y desactivación de cualquier ENTIDAD y RELACIÓN definidas
Tipos de workflows
Los pasos de validación de los que consta el workflow se identifican en el momento en que éste comienza a ejecutarse y marcan el orden de aceptación de un elemento por distintos roles.
Un workflow secuencial es un workflow en el que no hay bifurcaciones y el orden de las validaciones es siempre el mismo. Es por ello por lo que, en el momento en que este tipo de workflow arranca, se conoce de antemano qué roles serán partícipes de la validación. A continuación, se muestra un ejemplo de una secuencia lineal del funcionamiento jerárquico de aceptación en la herramienta Anjana Data.
En caso de que el workflow incluya condiciones a evaluar en base al objeto a validar, éste no es secuencial. Cuando un workflow de este tipo arranca se conocen todos los roles implicados pero se irá descubriendo con el avance del workflow los roles que tendrán que validar y cuáles no.
Para los casos en los que múltiples usuarios tienen que validar un paso de un workflow porque su rol depende una unidad de negocio concreta y no son transversales a la organización, en el paso se ejecutarán las validaciones en paralelo de manera que el paso se dará por finalizado cuando todos los usuarios hayan validado.
Puede encontrar más información acerca de la configuración de los workflows en la Guía de configuración funcional y en la Guía de configuración de workflows.
Contratos
Un contrato es un acuerdo escrito entre productores y consumidores de datos que facilitan la compartición, uso y consumo regulado de estos.
Especifican los términos de licencia, incorporan las condiciones de uso de los datos y los requerimientos adicionales establecidos por ambas partes (p.e: condiciones de calidad, disponibilidad, etc).
Los DSAs donde se incluyen los contratos incluyen una fecha de expiración para la gestión del ciclo de vida junto con las versiones y los impactos.
Antes de adherirse a un DSA, es obligatorio que el usuario consumidor se descargue el contrato, lo lea y lo firme.
Transferencia de derechos, responsabilidades y usos del dato
El establecimiento de contratos legales para los DSAs y Soluciones permite a los propietarios de los datos transferir tanto derechos como responsabilidades sobre la información bajo una cobertura legal, al mismo tiempo que se facilita el intercambio, uso y consumo de datos.
Uso de los contratos
Un contrato aplica tanto a DSAs como a Soluciones y representa un acuerdo legal de uso de los datos.
Cada contrato tiene dos grupos de contrapartes (proveedores y consumidores), un responsable y una figura legal que valida el contrato, si así se define en el modelo de gobierno del dato.
En el contrato se incluyen los términos de uso a aplicar y una fecha de validez del contrato para la firma de las contrapartes. Esta información permanece inmutable durante la vida del contrato bajo las condiciones firmadas y, si se desea modificar, se requerirá la aceptación de todas y cada de las contrapartes.
Características de los contratos de DSAs
En la creación de un DSA, los propietarios de las entidades contenidas (estructuras de datos como datasets, informes, KPIs, reglas de calidad…) ‘ceden’ la responsabilidad de las mismas al responsable del DSA.
Con la adherencia de un usuario a un DSA, el usuario acepta el cumplimiento del contrato bajo los términos de licencia especificados en la creación del DSA. El responsable del DSA es el encargado de que las condiciones del contrato se cumplan por todas las partes.
Es posible agrupar varias estructuras de datos en un mismo DSA para la solicitud de acceso a través de una única petición de adherencia bajo un mismo acuerdo legal.
Además, una entidad puede estar incluida en distintos DSAs amparados por contratos legales diferentes (por distintos casos de uso, diferentes términos de licencia, distinta fecha de validez…)
Gobierno de los datos
El gobierno pasivo de los datos es un enfoque en la gestión y supervisión de los datos que se caracteriza por la observación, registro y auditoría de la información sin interferir activamente en el flujo de los datos ni en las operaciones diarias de los usuarios.
El gobierno activo, en contraposición, busca implementar políticas, reglas y controles que intervienen de manera directa e inmediata en el uso, acceso y manipulación de los datos dentro de una organización. De esta forma, se declaran las tareas de gestión de datos en la plataforma de gobierno y, una vez que se dispongan de las aprobaciones correspondientes, se ejecutan en las plataformas de datos o en los sistemas de gestión de identidades.
Anjana Data ofrece diferentes funcionalidades nativas para el gobierno de las estructuras gracias a los plugins, que son los conectores que permiten comunicar con los sistemas de datos.
Gobierno pasivo
Extracción de metadatos
Esta funcionalidad permite extraer metadatos de las estructuras localizadas en los sistemas de datos para incorporarlos al Catálogo de Datos o al Glosario de Negocio generando los objetos correspondientes.
Puede encontrar más información acerca de cómo extraer metadato en el apartado Wizard de creación > Metadato automático de esta Guía de usuario.
Auditoría externa
La auditoría externa es el resultado de la monitorización de los logs de auditoría que devuelven las plataformas de datos y que permite visualizar, por ejemplo, accesos no gobernados o cambios en las estructuras de datos que no se han declarado previamente en la herramienta.
Esta auditoría no la proporciona Anjana, sólo posibilita su explotación.
Puede encontrar más información en los apartados Dataset > Auditoría, Instancia de proceso > Auditoría, Menú de funcionalidades > Auditoría y Perfil de usuario > Auditoría de esta Guía de usuario.
Reutilización de DSAs
A pesar de que Anjana puede gestionar los grupos de los gestores de identidades, como se puede ver en el apartado Gestión de estructuras de datos, es posible que en el entorno con el que Anjana interactúa ya existan previamente grupos creados.
En ese caso, y para permitir que Anjana gestione los permisos de forma automática gracias a las adherencias, se pueden “reutilizar” DSAs incluyendo en el atributo physicalName de su plantilla el nombre del grupo que ya existe. Con eso, cuando el DSA se apruebe en Anjana no se creará la estructura correspondiente pero será usada cuando los usuarios soliciten adherencia y se les conceda.
Cabe destacar que grupos ya existentes utilizados de este modo por Anjana entran en el ciclo de vida natural de grupos gobernados por DSAs, lo que incluye su borrado una vez se expira el DSA que lo utiliza.
Gobierno activo
Gestión de estructuras de datos
Esta funcionalidad permite realizar automatismos en las estructuras de datos recuperando su metadato de Anjana.
De esta forma, por ejemplo, cuando se crea en la aplicación un nuevo dataset localizado en un SQLServer y finaliza el flujo de validación con aprobaciones, el plugin de Anjana puede crear la estructura correspondiente automáticamente.
O bien, al crear un DSA que incluya un dataset y un informe marcados como gobernados en su plantilla y se apruebe en el flujo de validación, el plugin de Anjana puede crear el grupo correspondiente en el gestor de identidades. De esta forma, Anjana crea el grupo en Azure AD al que se da permiso a los datos del dataset y del informe de Azure Storage, por ejemplo.
Cabe destacar que, por la operativa de Anjana, si se desea modificar el grupo correspondiente al DSA es necesario versionar el DSA para que se cree un grupo nuevo y se den permisos. Es decir, si en un DSA ya existente se añaden estructuras de datos o bien cambia alguna de las incluidas y pasa a gobernado sin haberlo sido antes, es necesario que se cree una nueva versión del DSA y, con ella, se cree el grupo nuevo con los nuevos permisos de acceso a datos. El grupo creado se llamará igual que el valor informado del atributo “name” de DSA concatenando “_V” y la versión del mismo.
Muestra de datos
Se trata de una funcionalidad muy útil de cara a la compartición de datos. Si el responsable de un dataset gobernado habilita en la plantilla de éste el check para permitir el muestreo de datos y la tripleta así lo contempla, los usuarios de Anjana podrán visualizar una muestra de los datos del dataset en la que los campos marcados como PI aparecerán ofuscados.
Puede encontrar más información acerca de esta funcionalidad en el apartado Dataset > Datos de muestra de esta Guía de usuario.
Gestión de permisos de acceso a datos
Esta funcionalidad habilita la compartición de datos gestionando permisos de acceso a datos directamente en la fuente, sin virtualización, copia o movimiento de datos.
En Anjana la gestión de permisos se efectúa por medio del carrito de la compra desde donde el usuario solicita acceso a estructuras de datos o DSAs.
Cuando la solicitud de adherencia es aprobada, es posible, por tanto, incluir al usuario solicitante en el grupo correspondiente al DSA al que se ha adherido para que, de esa forma, “herede” los permisos que el grupo tiene. Siguiendo con el ejemplo introducido en el apartado de Gestión de estructuras para la creación de un DSA en Azure AD, se introduciría al usuario en ese mismo grupo para que pase a tener permisos de acceso a los datos de los datasets de Azure Storage.
Es necesario para poder llevar a cabo gobierno activo de las estructuras que éstas tengan configuradas, en sus plantillas, los atributos infraestructura, tecnología, zona, path e is_governed.
Puede encontrar más información en el apartado Menú de funcionalidades > Carrito de la compra de esta Guía de usuario.
Otras integraciones
También es posible integrar Anjana con los servicios de ingesta de datos, plataformas de datos, sistemas de gestión de identidades y servicios de consumo de datos a través de los plugins.
Roles y permisos
La definición de los roles de los usuarios y sus capacidades en la organización son configurables en Anjana Data para que cada organización establezca el modelo de gobierno según sus necesidades.
Los roles que se definan deben coincidir con los definidos dentro del Gobierno del Dato de la organización.
Esos roles pueden ser:
-
Verticales: las personas que desempeñan el rol lo ejercen solamente sobre un dominio concreto de datos (unidad organizativa). Para el resto de dominios, otras personas desempeñarán el mismo rol que ellos teniendo las mismas responsabilidades pero sobre otro conjunto de activos de datos
-
Cross o transversales: las personas que desempeñan el rol lo harán teniendo siempre los mismos permisos sobre los activos de todos los dominios de datos de la organización.
Cada uno de los roles definidos deberá disponer de un paquete de permisos. Los permisos pueden aplicarse por tipo de objeto (métricas, dataset, términos, DSAs…), por tipo de acción (creación, modificación, búsquedas…) y por módulos específicos (auditoría, linaje, histórico…).
En caso de que el usuario de Anjana no tenga un rol específico asignado de los configurados en la plataforma, es posible otorgar al usuario los permisos correspondientes a un rol por defecto configurado que se asignará a todo aquel que entre al Portal de Datos.