Documento Arquitectura de Solución RAMA JUDICIAL. Helen Acosta Cod Jairo Casallas Cod Juan Vergara Cod.

Transcripción

1 Documento Arquitectura de Solución RAMA JUDICIAL Helen Acosta Cod Jairo Casallas Cod Juan Vergara Cod Bayron Yela Cod Noviembre de 2012 Pág. 1

2 Historia del Documento Fecha Versión Modificado por Observaciones 08/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 09/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 12/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 13/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 19/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 21/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 26/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela Documento Preliminar Identificación de necesidades del negocio e identificación del canvas Planteamiento de soluciones para manejo documental enfocado a relatorías Identificación de servicios y subzonas del blueprint Consolidación del portafolio de servicios Consolidación de blueprint refinado con conectores entre zonas Análisis de aplicaciones que suplen los componentes de la arquitectura de solución propuesta Pág. 2

3 27/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 30/10/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 01/11/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 09/11/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela 12/11/ Helen Acosta Jairo Casallas Juan Vergara Bayron Yela Documentación de experimentación Adición de nuevo servicio dentro del catálogo para agregar funcionalidad a la solución Documentación de criterios de selección de alternativa de solución Documentación de diagrama de instanciación, vistas funcional, lógica y física de la arquitectura de solución Documentación de fichas de proyectos y road map Pág. 3

4 Contenido 1 Descripción del Documento Propósito: Objetivos: Audiencia Interna Audiencia Externa Organización del documento Convenciones, terminología y definiciones Documentos Relevantes: Introducción Identificación de necesidades Análisis de propuestas Identificación del Canvas Blueprint refinado Identificación de servicios Técnicas de descubrimiento de servicios Portafolio de Servicios Servicios de soporte Servicios de tecnología: Servicios de Datos Especialización de zonas Especialización de conectores Indicadores Experimentación Derivación de aplicaciones Análisis de alternativas Análisis de negocio Análisis de tecnología Generación de Vistas Refinadas Pág. 4

5 13.1 Diagrama de instanciación Vista funcional Vista lógica Vista Física Road Map Arquitectura de solución Ficha infraestructura de soporte Ficha aplicación de soporte de archivos Ficha aplicación de Registro Documental Ficha aplicación de Gobierno Documental Road map de implementación Conclusiones Referencias Anexo 1: Detalle de análisis de identificación de necesidades del negocio Anexo 2: Canvas de negocio. Altas Cortes Rama Judicial Anexo 3: Blueprint Altas Cortes Rama Judicial Pág. 5

6 1 Descripción del Documento 1.1 Propósito: Desarrollar una Arquitectura de Solución alineada con los ejes estratégicos del plan sectorial de desarrollo del Consejo para la Rama Judicial, orientado a cumplir uno o más objetivos específicos persiguiendo la meta de garantizar un servicio de Justicia de calidad. 1.2 Objetivos: La definición de la arquitectura de solución para la Rama Judicial de Colombia tiene los siguientes objetivos principales: - Definir una arquitectura de solución a partir de las necesidades del negocio - Derivar una arquitectura de solución a partir de la arquitectura de referencia de la Rama Judicial - Documentar el procedimiento para la definición de la arquitectura de solución, desde la identificación de las necesidades del negocio hasta la derivación de aplicaciones como soluciones a esas necesidades 1.3 Audiencia Interna El planteamiento de una arquitectura de solución enfocada en el mejoramiento y cumplimiento de las metas de negocio para la Rama Judicial tiene como audiencia interna a la Sala Administrativa del consejo superior de la Judicatura y representantes de cada corte. 1.4 Audiencia Externa De acuerdo al análisis del negocio de la Rama Judicial, enfocado en la solución de un problema particular, la audiencia externa corresponde a los miembros de las altas cortes de cada jurisdicción, al igual que usuarios externos (público en general) interesados en la documentación de casos fallados. 1.5 Organización del documento En el presente documento se detalla el procedimiento ejecutado para el descubrimiento y definición de una solución específica enfocada a satisfacer una Pág. 6

7 necesidad específica de las altas cortes de la Rama Judicial cuya meta de negocio principal corresponde a la provisión de un servicio de justicia de calidad. Inicialmente se documenta la forma en que se analizan diferentes aspectos, encaminados a la identificación de las necesidades del negocio y con ello proponer una arquitectura de solución que realmente contribuya a alcanzar una meta de negocio para la administración de la justicia en la Rama Judicial; una vez identificada la solución específica que se quiere trabajar se plantearán tres opciones de solución, las cuales no necesariamente tengan que ver con tecnología, de esta manera mediante un análisis de costo/beneficio poder determinar la solución más adecuada. Después de la selección de la opción de solución, se identifican las zonas del modelo de negocio que se ven afectadas por la solución propuesta y de esta forma determinar cuáles aspectos van a tener mayor relevancia y cuales se pueden dejar de lado en la arquitectura de solución propuesta, así, del canvas de negocio se especifican que aspectos se deben eliminar, en cuales se deben crecer, cuales se deben reducir y cuales se deben crear. Se toma el blueprint de la arquitectura de referencia de la Rama Judicial, para poder identificar cuales zonas se ven involucradas dentro de la arquitectura de solución propuesta, con ello se tendrá un mayor enfoque en la identificación de los servicios. Igualmente en esta etapa es posible identificar a nivel macro qué subzonas existen dentro de la arquitectura de solución. Posteriormente, utilizando diferentes técnicas para identificación de servicios se propondrán aquellos que son necesarios dentro de la arquitectura de solución. Es posible que un servicio sea identificado en el empleo de dos o mas técnicas de descubrimiento, lo que indicaría que es un servicio que definitivamente debe figurar en el catalogo de servicios del negocio. Como resultado de esta actividad se generará un portafolio de servicios detallado que será de gran utilidad al momento de la implementación de alguna solución. Dentro del refinamiento de los componentes de la arquitectura de solución se identifican de manera clara la ubicación de cada uno de los servicios propuestos. Después de realizar un refinamiento del blueprint y de haber identificado una serie de servicios para la arquitectura de solución, se diseñan las subzonas Pág. 7

8 identificadas utilizando un proceso top-down desde la zona de canales hasta la zona de servicios de información. Los conectores entre las diferentes zonas e incluso entre subzonas deben ceñirse a las especificaciones del documento de arquitectura de referencia, es por ello que se debe también documentar la forma en que una solución a implementar debe seguir estos lineamientos. Luego de todo el proceso de identificación de los diferentes artefactos involucrados en la arquitectura de solución, es necesario realizar experimentación de la arquitectura para poder identificar si realmente ésta genera un valor para el negocio. Se definen unos indicadores para poder medir posteriormente si efectivamente el objetivo propuesto con la arquitectura de solución es medible y alcanzable o si por el contrario la solución propuesta no va a generar valor y se debe abordar una nueva solución o enfoque en el trabajo propuesto. Una vez validada la solución por medio de la experimentación, es necesario plantear al menos dos opciones de solución y de acuerdo a una serie de criterios escoger la adecuada. De acuerdo a la opción escogida, se debe identificar las aplicaciones que van a dar soporte a la funcionalidad de los servicios identificados y documentarlas para tener claridad de la interacción de los diferentes componentes para la solución. En el proceso de refinamiento de la arquitectura de solución es posible que surjan nuevas ideas para acotar la solución o para añadirle mayor funcionalidad y valor para el negocio, por lo cual es válido redefinir o adicionar algunos componentes de la arquitectura de solución propuesta. De acuerdo a los indicadores propuestos para identificar la viabilidad de la arquitectura de solución se debe realizar una experimentación de la propuesta, para lo cual se tomará un caso de éxito conocido para determinar si los indicadores se pueden medir y si de acuerdo a la experiencia de otras implementaciones, las cifras a obtener en un futuro ayudarán a la meta de negocio buscada. Finalmente, de acuerdo a la arquitectura de solución se deben documentar las vistas de despliegue, funcional, lógica y física y las fichas técnicas de implementación de los diferentes proyectos que surgen para la completitud de la Pág. 8

9 solución con un road map que permita evidenciar las diferentes líneas de tiempo para la culminación y puesta en marcha de la solución propuesta. 1.6 Convenciones, terminología y definiciones Road map: planificación del desarrollo de un software con los objetivos a corto y largo plazo, y posiblemente incluyendo unos plazos aproximados de consecución de cada uno de estos objetivos. Se suele organizar en hitos o "milestones", que son fechas en las que supuestamente estará finalizado un paquete de nuevas funcionalidades [1]. Blueprint: Reproducción en papel de un dibujo técnico, un plano cartográfico o un diseño de ingeniería. Por lo general, el término blueprint se usa para referirse a cualquier plano detallado [1]. Dentro de la arquitectura de solución el blueprint permite identificar las diferentes zonas que dan sentido a los componentes necesarios para el despliegue de la solución. Canvas: modelo de negocio que describe de manera lógica la forma en que las organizaciones crean, entregan y capturan valor. [2] 1.7 Documentos Relevantes: - Documento de definición de Arquitectura de referencia Altas Cortes - Documento de experimentación Arquitectura de Solución Pág. 9

10 2 Introducción De acuerdo a los objetivos propuestos para el desarrollo de arquitecturas de solución, es importante documentar el proceso de descubrimiento de necesidades del negocio para llegar a una propuesta de arquitectura de solución, la cual está basada en la arquitectura de referencia de la Rama Judicial. Esta arquitectura de solución se convierte en un punto de partida para la implementación de diferentes arquitecturas de software encaminadas a abordar varios objetivos específicos del plan de sectorial de desarrollo de la Rama Judicial y de su plan estratégico tecnológico. Pág. 10

11 3 Identificación de necesidades Previo a cualquier análisis para la definición e implementación de una arquitectura de solución, es necesario identificar cómo se encuentra el negocio hoy en día y cuáles son sus principales necesidades. De acuerdo a lo que se identifica después de este análisis se pueden proponer una arquitectura de solución adecuada para satisfacer una o varias de las necesidades más relevantes para el negocio, en este caso para los planes de la Rama Judicial enfocados en prestar un servicio de Justicia de calidad alineando el negocio con TI. Para la identificación de las necesidades del negocio se tuvieron en cuenta los siguientes aspectos: - Propuesta de valor - Análisis Costo / Beneficio - Evaluación de la Infraestructura - Evaluación de la Interacción con el cliente Detallando sobre ellos aspectos generales referentes a la alineación de TI con el negocio e identificando las principales oportunidades y amenazas relevantes para el negocio. Resultado de este análisis (Anexo 1. Detalle de análisis de identificación de necesidades del negocio) se obtuvo un resultado en donde se evidencia que la solución debe enfocarse en mejorar el índice referente a relacionamiento con el cliente y las propuestas de valor, empleando TI para contribuir a procesos más efectivos. Pág. 11

12 Canales Socios de negocio Actividades Clave Relacionamiento con clientes Propuestas de valor Gráfico 1. Resultados identificación de necesidades del negocio De acuerdo a los resultados del análisis se identificó una oportunidad de mejora, persiguiendo el objetivo de generar procesos más efectivos y contar con la disponibilidad de la información más oportunamente. La solución propuesta es la de un Gestor Documental para las relatorías que permita generar beneficios dentro de los procesos de la Rama Judicial. La solución contempla la creación de una Carpeta Virtual con Metadata de los Documentos que conforman los Procesos Orales y no Orales (Procesos- Civiles, Penales, Laborales, Disciplinarios-, Tutelas, Tratados, Providencias, Sentencias) y Documentos Anexos al Proceso (Pruebas Documentales, Videos, Grabaciones, Imágenes). Igualmente para soportar la decisión de la arquitectura de solución propuesta se identifican los puntos relevantes del Plan Sectorial de desarrollo de la Rama Judicial y del plan estratégico tecnológico para la rama judicial, encontrando alineación con los ejes estratégicos, las prioridades del plan y los aspectos transversales de los mismos, tal como se indica en el siguiente gráfico. Pág. 12

13 Gráfico 2. Gestor documental. Alineación con el negocio Prioridad del plan: Modernización de trámites, procedimientos y plantas: corresponde a la adquisición de infraestructura física, tecnológica, nuevos estándares y procedimientos como apoyo a la gestión de la Rama Judicial. Ejes estratégicos: Tecnologías de la información para alcanzar la modernización y la eficiencia de la justicia: Consiste en el desarrollo de innovaciones y capacidad tecnológica para el mejoramiento en el trámite procesal con la incorporación de la firma digital, y la notificación electrónica entre otros, buscando eficiencia, efectividad y la superación de cuellos de botella. Gestión documental: Implica el planteamiento de procedimientos para la gestión de documentos físicos que faciliten el acceso y control de la información documental. Pág. 13

14 Gestión del archivo judicial: Consiste en la gestión documental y de los archivos del modelo escrito y del modelo oral. Aspectos transversales Gestión documental: Implica el planteamiento de procedimientos para la gestión de documentos físicos que faciliten el acceso y control de la información documental. Pág. 14

15 4 Análisis de propuestas Una vez identificada la solución que se quiere proponer correspondiente a la gestión documental, se deben verificar varias opciones para enfrentar una solución para el problema propuesta y mediante un análisis de costo beneficio poder determinar cuál será la opción escogida para la arquitectura de solución. Las propuestas para abarcar el problema de gestión documental son las siguientes: - Repositorio de Texto - Repositorio de Archivos en Carpetas - Gestor Documental - Carpeta Virtual El análisis costo beneficio se puede ver en el siguiente esquema: De acuerdo a ello, la solución propuesta es la del Gestor Documental Carpeta Virtual. Pág. 15

16 5 Identificación del Canvas De acuerdo a la arquitectura de solución propuesta se debe identificar cuáles de los aspectos contenidos dentro del Canvas de negocio se ven afectados, ya sea para enfocarse en ellos o para dejarlos de lado porque no se ven afectados por la solución. Adicional a ello también pueden surgir aspectos nuevos que se deban crear para proporcionar valor al negocio. Para ello se tomo como base el canvas de negocio del documento de arquitectura de referencia (Anexo 2. Canvas de negocio. Altas Cortes Rama Judicial) y se detallaron los bloques afectados por la solución de acuerdo a la siguiente nomenclatura: Aspectos que se deben eliminar de acuerdo a la arquitectura de solución Aspectos que se deben extender de acuerdo a la arquitectura de solución Aspectos que se deben disminuir de acuerdo a la arquitectura de solución Aspectos nuevos que se deben crear de acuerdo a la arquitectura de solución De acuerdo a estos criterios los siguientes fueron los resultados para los bloques del Canvas de negocio original: Pág. 16

17 Pág. 17

18 6 Blueprint refinado De acuerdo a las zonas del blueprint de la arquitectura base (o de referencia) para las altas cortes de la Rama Judicial (Anexo 3. Blueprint Altas Cortes Rama Judicial), es necesario identificar las zonas que se ven afectadas por la arquitectura de solución propuesta. Igualmente dentro de las zonas que hagan parte de la arquitectura de solución se detallan unas subzonas identificadas de acurdo a la funcionalidad propuesta por el gestor documental para relatorías. Dentro del blueprint de referencia se deben excluir la zona de BAM, servicios Externos y Datos compartidos, ya que lo que se considera debe incluirse dentro de las arquitecturas de software no contendrá ningún componente que afecte estas zonas. De acuerdo a ello, las zonas que se ven afectadas son: - Zona de canales - Zona de Procesos - Zona de servicios de soporte - Zona de servicios de tecnología - Zona de servicios de Datos Gráfico 3. Blueprint refinado Arquitectura de solución Altas cortes Rama Judicial Pág. 18

19 7 Identificación de servicios Una vez identificadas las zonas que se ven afectadas por la arquitectura de solución propuesta se deben emplear diferentes técnicas de descubrimiento de servicios para poder consolidar un portafolio de los servicios ofrecidos en cada una de las zonas involucradas. 7.1 Técnicas de descubrimiento de servicios Las técnicas y resultados obtenidos se mencionan a continuación: - Horizontal Service Discovery And Analysis (Analysis Upward): Resultado de este análisis se identifican servicios de auditoría de procesos, estadísticas, seguimiento y mejoramiento de procesos, gestión de artefactos documentales. - Horizontal Service Discovery And Analysis (Service-Oriented Bottom- Up Discovery Process): donde se identifican los servicios que actualmente se ofrecen relacionados con manejo documental y que pueden ser reutilizados dentro de la arquitectura de solución propuesta. - Vertical service discovery and analysis (analysis inward): donde se identifican los servicios que van a ser de utilidad al negocio tales como Gestor de contenido multimedia, reproductor de audio y video y carpeta virtual - Front-To-Back Service Discovery Process: donde se identifican los servicios asociados a las funcionalidades que requiere el usuario al emplear la solución propuesta. - Back-To-Front Service Discovery Process: donde se identifican los servicios desde una perspectiva conceptual acerca de los artefactos necesarios para la funcionalidad del gestor documental para relatorías de las altas cortes de la Rama Judicial, una perspectiva lógica, identificando la forma en cómo la solución entregar la información a los usuarios y una perspectiva física identificando los artefactos de hardware y software para prestar la funcionalidad de gestión documental. Pág. 19

20 - Contextual Expansion Process And Modeling: se identifican servicios que pueden ser compartidos para dar soporte a otras soluciones que enriquezcan el aporte a las metas de negocio - Contextual Contraction Process And Modeling: Se identifican servicios que pueden ser retirados afectando la funcionalidad y el alcance de la solución. - Security Concerns For The Service Ecosystem: Se identifican los aspectos que deben ser transversales a la aplicación para proporcionar seguridad a la solución, tales como administración de identidad, confidencialidad, privacidad, no repudio, autorización, autenticación e integridad 7.2 Portafolio de Servicios Luego del análisis de descubrimiento de servicios bajo diferentes técnicas se consolidaron los resultados obtenidos y se obtuvo el siguiente portafolio de servicios en cada una de las zonas: Servicios de soporte Cargador de archivos Cargador de audio Cargador de video Cargador documentos texto Cargador de imágenes Convertidor de archivos Convertidor de audio Convertidor de imágenes Convertidor de video Convertidor de texto Visor de archivos Visor de imágenes Visor de texto Reproductor de audio Pág. 20

21 Visor de video Compresor de archivos Compresor de imágenes Compresor de texto Compresor de audio Compresor de video Autorizador Servicios de tecnología: Retención documental Eventos documentales Auditoria Estadísticas Mejoramiento Carpeta Virtual Restaurador de Documentos Digitalizador de documentos Capturador Metadata Administrador de backups Manejador de Casos Servicios de Datos Destructor certificado Recuperador Recuperador texto Recuperador imágenes Recuperador video Recuperador audio Pág. 21

22 8 Especialización de zonas En vista que ya se cuenta con el blueprint refinado, es necesario identificar de acuerdo a la funcionalidad de los servicios definidos, las subzonas del blueprint y la interacción entre subzonas de una misma zona así como entre subzonas de diferentes zonas. Inicialmente se identifican las subzonas del canvas, así: - Zona de canales: donde se debe incluir aplicaciones que sirvan de Front para los diferentes usuarios, las cuales deben consumir los servicios del proceso de gestión documental. Las subzonas corresponden a un Portal para los usuarios externos que pueden consultar las relatorías de las altas cortes e Intranet para los usuarios internos a la organización, permitiendo la consulta y cargue de información. - Zona de Procesos: donde se enmarca el proceso de gestión documental que debe incluir todas las variantes para los diferentes tipos documentales y las políticas de proceso para cada uno de ellos. - Zona de servicios de soporte: donde se incluyen las funcionalidades técnicas que permite la administración de los artefactos documentales (soporte de archivos) y la seguridad para el acceso a la información que suministrará la solución (Seguridad). - Zona de servicios de tecnología: Donde se tienen los servicios de negocio enfocados al registro documental para la administración de documentos y la zona de gobierno documental que contiene las políticas de retención documental, tipos de documentos y vigencias para conservación y destrucción de los mismos. - Zona de servicios de Datos: donde se tiene la administración de los datos correspondientes a relatorías de las altas cortes y su almacenamiento y administración de contenido en diferentes formatos. Posteriormente se esquematiza la relación entre subzonas: Pág. 22

23 Grafico 4: Especialización de zonas del Blueprint y relaciones Pág. 23

24 9 Especialización de conectores De acuerdo a los servicios identificados y las conexiones entre las diferentes zonas del blueprint es necesario especificar cuáles son los consumidores de los servicios y de qué forma se deben comunicar las diferentes zonas. Inicialmente se ubican los servicios del portafolio de servicios en las zonas del blueprint y las dependencias que tienen, de la siguiente forma: Grafico 5: comunicación entre zonas interdependencia de servicios Pág. 24

25 Posteriormente, teniendo en cuenta la comunicación entre las diferentes subzonas, es necesario especificar mediante el modelo trivadis, cuál será la forma en que las diferentes zonas se pueden comunicar. Resultado de ello, se obtienen todos los trivadis como se especifican a continuación: Trivadis Zonas Intranet y Soporte de Archivos Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Message Dispatcher SOAP Adapter SOAP XML Intranet SOAP Adapter SOAP XML Soporte De archivos Pág. 25

26 Trivadis Zonas Intranet y seguridad Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher JNDI Adapter LDAP LDAP Intranet JNDI Adapter LDAP LDAP Seguridad Pág. 26

27 Trivadis Zonas Intranet y Registro documental Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher SOAP Message Adapter Dispatcher SOAP XML Intranet SOAP Adapter SOAP XML Registro Documental Pág. 27

28 Trivadis Zonas Intranet y Gobierno documental Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher SOAP Adapter SOAP XML Intranet SOAP Adapter SOAP XML Gobierno Documental Pág. 28

29 Trivadis Zonas Portal y Registro Documental Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher SOAP Adapter SOAP XML Portal SOAP Adapter SOAP XML Registro Documental Pág. 29

30 Trivadis Zonas Proceso Documental y Registro documental Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher SOAP Adapter SOAP XML Proceso Documental SOAP Adapter SOAP XML Registro Documental Pág. 30

31 Trivadis Zonas Registro Documental y Soporte de Archivos Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher HTTP Adapter HTTP XML Registro Documental HTTP Adapter HTTP XML Soporte Archivos Pág. 31

32 Trivadis Zonas Registro Documental y Gobierno Documental Aplicación Dominio de Integración Procesos Mediación Recolección Distribución Transporte Comunicaci ón Zonas Blue Message Dispatcher EJB Adapter IIOP Registro Documental EJB Adapter IIOP Gobierno Documental Pág. 32

33 Trivadis Zonas Registro documental y Administración de datos Aplicación Dominio de Integración Procesos Mediación Recolección Distribución ESB SOAP ADAPTER Transporte Comunicaci ón SOAP XML Zonas Blue Tecnología Registro documental ODBC SQL Datos Admon Datos Pág. 33

34 10 Indicadores La arquitectura de solución propuesta debe estar enfocada en los intereses del negocio, es por eso que es necesario definir cuáles serán los indicadores que definirán si efectivamente la solución, una vez se encuentre implementada, va a ayudar a conseguir las metas de negocio que se buscan, es decir, se requieren indicadores que midan el éxito o fracaso de la solución. De acuerdo a la investigación de casos similares en el ámbito judicial, los indicadores propuestos para realizar estas mediciones son los siguientes: - Consultas relatorías portal al año - Tiempo de carga documental - Satisfacción en disponibilidad de la información - Efectividad en búsqueda de casos similares Para los dos primeros se tienen cifras actuales y contra ellas se compararía la efectividad de la solución. Para los dos últimos, los cuales son indicadores sobre los cuales no se tiene una medición actual, es necesario por medio de encuestas a los diferentes usuarios, establecer el grado de cumplimiento antes y después de la implementación de la solución. Pág. 34

35 11 Experimentación Para fundamentar la solución propuesta y validar si la elección fue adecuada es necesario realizar la experimentación de la misma. La experimentación puede realizarse a través de servicios mock o la simulación de un proceso que sea medible y comparable con la situación actual o la deseada. La experimentación también se puede realizar a través de Proxy o modelos de comportamiento similar a la arquitectura propuesta, donde se demuestre la viabilidad y diferentes casos de éxito de la implementación de diversos componentes para la solución de un problema especifico. La experimentación para la arquitectura de solución propuesta se realizó a través de un proxy de una implementación para gestión documental e inteligencia de asociación de casos para el ministerio de Justicia de North Rhine-Westphalia. Los detalles de la experimentación se encuentran en el documento de Experimentación Arquitectura de solución. Pág. 35

36 12 Derivación de aplicaciones Los servicios identificados para la arquitectura de solución deben ser mapeados a aplicaciones concretas que presten la funcionalidad requerida. Para ello es necesario plantear diferentes aplicaciones que se enmarquen en opciones reales y tangibles de una arquitectura propuesta utilizando herramientas existentes con total adopción de las mismas o con un nivel de adaptación considerable o con desarrollos a la medida. Teniendo en cuenta que existen soluciones en el mercado para la gestión de este tipo de procesos se plantean dos opciones parta poder mapear los servicios propuestos en la arquitectura de solución a aplicaciones concretas. Para el caso de gestión documental se plantean las siguientes alternativas: Alternativa 1: Adaptación de herramientas de IBM (Enterprise Content management) y Oracle (Base de datos) Para esta alternativa las siguientes serías las funcionalidades a adaptar: - DataWareHousing InfoSphereWareHouse - Bodegaje de datos - IBM Forms (Formularios flexibles y escalables para automatización de procesos) - IBM Wesphere Portal (Aplicaciones Basadas en roles) - BPM (Gestión de procesos de negocio) - IBM Tivoli Entity Manager (Automatiza los controles internos que regulan los controles de accesos a los usuarios) - IBM Security For Enterprise Single Sign On (Automatiza el inicio de sesión y acceso a las aplicaciones) - Directorio Activo Microsoft (LDAP) Pág. 36

37 Pág. 37

38 Gráfico 6: mapeo de servicios contra aplicaciones Alternativa 1 Pág. 38

39 Alternativa 2: Utilización de Portal de IBM, Desarrollo a la medida (Gestor documental) Parta esta alternativa, las siguientes serían las implicaciones: Desarrollo a la medida: Gestor Documental Altas Cortes - Digitalización - Captura de documentos - Gestión avanzada de casos - Gestión de contenido - Análisis de contenido - Gobierno de ciclo de vida de la información Portal IBM Base de datos Oracle 11g Directorio Activo Microsoft Pág. 39

40 Gráfico 7: mapeo de servicios contra aplicaciones Alternativa 2 Pág. 40

41 12.1 Análisis de alternativas Es necesario fijar criterios de selección para las alternativas propuestas y escoger una de ellas para poder documentar la arquitectura a niel de las diferentes vistas refinadas y proponer un roadmap para la implementación de la misma. Para la selección de la alternativa se tienen en cuenta aspectos de negocio y tecnológicos que mediante un puntaje ayudaran con la valoración y escogencia de la mejor alternativa Análisis de negocio Los criterios y resultados del análisis de negocio se muestran a continuación Análisis de tecnología Los criterios y resultados del análisis de tecnología se muestran a continuación. Pág. 41

42 Pág. 42

43 Pág. 43

44 Pág. 44

45 De la consolidación de los resultados se obtienen las siguientes cifras: Igualmente se realiza la cuenta de las fortalezas y debilidades encontradas para la toma de la decisión final. Pág. 45

46 De acuerdo a los criterios de selección planteados, la alternativa que tiene mayor viabilidad para su implementación corresponde a la del Gestor documental (alternativa 2). Pág. 46

47 13 Generación de Vistas Refinadas Para la alternativa seleccionada se deben documentar las diferentes vistas de la arquitectura con el propósito de tener una base de implementación. En estas vistas, las cuales están fundamentadas en las vistas de la arquitectura de referencia, se encuentran seleccionados componentes específicos tomados del footprint de la arquitectura de negocio. A continuación se muestran las respectivas vistas refinadas para la arquitectura de solución Diagrama de instanciación Basado en la arquitectura de referencia el siguiente corresponde al diagrama de instanciación para la arquitectura de solución. Pág. 47

48 13.2 Vista funcional Basada en la arquitectura de referencia la siguiente corresponde a la vista funcional para la arquitectura de solución. Pág. 48

49 13.3 Vista lógica Basada en la arquitectura de referencia la siguiente corresponde a la vista lógica para la arquitectura de solución. Pág. 49

50 13.4 Vista Física Basada en la arquitectura de referencia la siguiente corresponde a la vista física para la arquitectura de solución. Pág. 50

51 14 Road Map Arquitectura de solución Es importante para el negocio la definición de los aspectos relevantes para la implementación de la solución propuesta. Ello incluye, la funcionalidad para el negocio, el nivel tecnológico requerido, el modo de consecución de las aplicaciones, el presupuesto requerido, el recurso humano necesario, los riesgos y tiempos de implementación de cada uno de los proyectos derivados de la arquitectura de solución, con ello se puede contar con una línea estimada en el tiempo para poder visualizar los resultados de la solución propuesta. A continuación se muestran las fichas de cada uno de los proyectos propuestos y finalmente el roadmap de implementación Ficha infraestructura de soporte La implementación de la infraestructura que soportará la solución es la base para comenzar los demás proyectos. Esta infraestructura a futuro, puede ser utilizada para soportar otros proyectos tecnológicos. Pág. 51

52 14.2 Ficha aplicación de soporte de archivos Desarrollo a la medida para soportar la funcionalidad de la solución Pág. 52

53 14.3 Ficha aplicación de Registro Documental Desarrollo a la medida de aplicación de gestión documental bajo las especificaciones del negocio Pág. 53

54 14.4 Ficha aplicación de Gobierno Documental Desarrollo a la medida de aplicación de gobierno documental bajo las especificaciones del negocio Pág. 54

55 14.5 Road map de implementación La línea de tiempo para la implementación se fijó teniendo en cuenta el alcance de la solución para gestión documental de relatorías de las altas cortes de la Rama Judicial. La infraestructura y aplicación de soporte de archivos que se establezcan sirven para la implementación y soporte de otros proyectos de tecnología de la Rama Judicial y las funcionalidades de Gobierno documental y Registro Documental podrán adaptarse con desarrollos nuevos para la implementación de nuevas funcionalidades de negocio que la Rama Judicial requiera. Pág. 55