Herramienta de soporte a la construcci on de una ...

Universidad de los Andes

Facultad de Ingenierıa

Departamento de Ingenierıa de Sistemas y Computacion

Herramienta de soporte a laconstruccion de una arquitectura

de negocio

Asesor:Jorge Villalobos Salcedo

Estudiante:Federico Posada Santamarıa

Codigo 201616735

2019-20

Contenido

1 Resumen 3

2 Introduccion 3

3 Descripcion general 6

3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Identificacion del problema y de su importancia . . . . . . . . . . . . . . . . . 7

4 Diseno y especificaciones 7

4.1 Definicion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.2 Especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.3 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Desarrollo del diseno 10

5.1 Recoleccion de informacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 Alternativas de diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Implementacion 12

6.1 Descripcion de la implementacion . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.2 Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Validacion 62

7.1 Metodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.2 Validacion de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8 Conclusiones 64

8.1 Discusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

1

9 Referencias 65

10 Apendices 66

2

1 Resumen

Los proyectos de arquitectura empresarial permiten a las organizaciones comprender en de-talle su operacion, y de esta manera implementar cambios que permitan mejorarla. Producirlos entregables finales de estos proyectos requiere una extensa labor manual, lo que puedeconducir a errores de contenido y formato, ademas de dificultar su actualizacion en el tiempo.Frente a esto, se desarrollo una herramienta web que permite construir la arquitectura em-presarial por modelos, para luego generar un documento entregable y editable que contengala informacion introducida en la herramienta en formatos ordenados. La herramienta poseemanejo de sesiones, por lo que puede ser accedida remotamente por sus usuarios, y permiteun cruce entre elementos de los distintos artefactos (como puede suceder en el modelo oper-ativo) sencillo y rapido. Para validar el cumplimiento de los propositos de la herramienta,se construyo con ella la arquitectura empresarial de una empresa real, Envasar SAS, paraentregarle a la organizacion el documento entregable generado.

2 Introduccion

Motivacion

El desarrollo de la arquitectura empresarial de una empresa comienza por la recoleccion deinformacion por parte del arquitecto, la cual es luego empleada para modelar la organizacionen su estado actual a traves de distintos artefactos. Estos modelados permiten a la empresay al arquitecto identificar aspectos operativos y organizacionales a modificar, agregar oeliminar en pro del mejoramiento de la organizacion.

La elaboracion de los entregables de una arquitectura empresarial requiere una extensaintervencion humana. Posterior a la recoleccion de la informacion, los artefactos deben con-struirse de forma manual, lo que resulta en modelos posiblemente fragmentados y limitalas posibilidades de hacer analisis cruzados entre elementos. Tener una herramienta queguıe la insercion y el cruce de informacion, para luego generar automaticamente los entre-gables finales, resultarıa en una disminucion de errores y mayor facilidad para actualizar losdocumentos.

Enunciado del problema

Desarrollar una herramienta web que permita desarrollar los artefactos que componen laarquitectura empresarial de cualquier organizacion y automatice la generacion de un doc-umento entregable empleando la informacion introducida en los artefactos. Debe tenermanejo de sesiones, de manera que el trabajo sobre los artefactos pueda reanudarse endistintos equipos, y el documento final debe generarse y poderse descargar a solicitud delusuario.

3

Diseno e implementacion

Modulos de la herramienta: Los modulos incluidos, segun los componentes de unaarquitectura empresarial son:

• Modelo de negocio

– Portafolio de servicios

– Modelo ontologico

– Estructura de negocio y modelo de canales

• Modelo financiero

– Estados financieros

– Indicadores financieros

• Modelo estrategico

– Componente motivacional

– Estrategias de negocio

– Plan estrategico

– Acciones de transformacion

– Proyectos

• Mapa de capacidades

• Estructura organizacional

– Catalogo de cargos

– Organigrama

• Modelo de procesos

– Cadena de valor

– Catalogo de procesos

• Modelo de recursos

– Modelo de recursos

– Modelo de recursos de TI

– Catalogo de aplicaciones

– Catalogo de componentes

– Modelo operativo

• Modelo de informacion

– Indicadores operativos

– Indicadores estrategicos

4

– Indicadores externos

Generacion del documento: Cada modulo permite al usuario ingresar la informacion delos artefactos respectivos, la cual se almacena en una base de datos no relacional. Cuandoel usuario lo desee, se generara un documento de Microsoft Word que se alimentara de losdatos almacenados y se ordenaran en formatos predefinidos.

Tecnologıas empleadas:

• Framework: Meteor, de codigo abierto con Universal JavaScript.

• Base de datos: MongoDB.

• Librerıas relevantes:

– React

– docx

Resultados obtenidos

La totalidad de los modulos fueron implementados, incluyendo aquellos que involucraban lasubida de imagenes por parte del usuario. En concordancia con los objetivos, el desarrollode la arquitectura en la herramienta no esta condicionado por ningun tipo de negocio otamano de empresa, por lo que es posible modelar cualquier organizacion en terminos delos artefactos mencionados. El documento generado contiene tablas con un formato legibley organizado que estructuran cada seccion del documento. De manera que esto se validaracon un ejemplo real, se creo la arquitectura empresarial de una empresa pequena productorade envases plasticos, llamada Envasar SAS.

Estructura del documento

El documento esta estructurado como se describe a continuacion: La seccion 3 describeen detalle el problema que pretende resolver la herramienta. La seccion 4 describe lasespecificaciones y restricciones del proyecto. La seccion 5 describe los disenos empleadospara cada modulo. La seccion 6 describe la implementacion de todos los aspectos de laherrramienta. La seccion 7 detalla la validacion de los modulos y el documento que produce.Finalmente, la seccion 8 concluye el documento.

5

3 Descripcion general

3.1 Objetivos

El proyecto pretende desarrollar una herramienta que guıe la construccion de los modelos deuna arquitectura empresarial y automatice la generacion de los entregables. Por un lado, eldesarrollo de los ocho modelos emplea una interfaz web que provee, para cada artefacto, loscampos y formatos para introducir la informacion requerida de la organizacion. Aquellosartefactos que hacen cruces de informacion con otros modelos (modelo operativo, indicadoresoperativos, etc.) emplean la informacion introducida en ellos para completar los campos,reduciendo la posibilidad de cometer errores al introducir identificadores a mano. Por otraparte, la generacion automatica consume la informacion introducida en los modelos y losordena en formatos determinados en un documento editable de Microsoft Word, de maneraque se reduce el trabajo manual y posibles errores de digitacion.

3.2 Antecedentes

El trabajo previo sobre el tema de los entregables finales de una arquitectura empresarialcomprende dos aproximaciones: el analisis de los dos marcos de referencia (frameworks)de entregables y una propuesta de generacion semiautomatica de entregables a partir deplantillas generadas con un Domain Specific Language (DSL).

Goethals [1] separa los marcos de referencia en dos: frameworks clasicos y frameworksfederados. Segun el primer grupo, el manejo de una arquitectura empresarial comprendecinco actividades: (a) conceptualizar las visiones de la organizacion a obtener, (b) desar-rollar y mantener los modelos del estado actual de la empresa, (c) desarrollar y mantenerlos modelos del estado futuro, (d) planear la migracion e (e) implementar la arquitecturaempresarial. De acuerdo con Goethals, estos marcos de referencia no definen procesos es-pecıficos para el modelado y el mantenimiento de datos de los entregables. El segundo grupopropone mantener los datos de artefactos (aquellos que requieran actualizaciones frecuentes)en estructuras especializadas en el repositorio de la arquitectura, lo que requiere la creacionde interfaces para acceder a los datos y la definicion de roles que permitan establecer pro-cedimientos para el mantenimiento de la arquitectura en el tiempo.

Saenz et al.[2] definen una aproximacion a la generacion automatizada de entregablesde arquitectura empresarial. La secuencia que establecen empieza con dos DSL: el primero,Pollux, produce un conjunto de funciones que realizan consultas y analisis sobre los modelosque haya construido el arquitecto para generar los artefactos. El segundo, Castor, defineuna plantilla que esta compuesta de capıtulos, secciones y documentos que da forma aldocumento entregable. Posteriormente, ambos resultados se usan como la entrada de ungenerador de entregables de arquitectura empresarial (EADG), que usa las funciones paraobtener la informacion y construye el entregable siguiendo la plantilla definida, exportandoel documento en varios formatos segun las necesidades de la organizacion.

6

3.3 Identificacion del problema y de su importancia

Los modelos que un arquitecto pueda construir con la informacion de la organizacion, apesar de ser utiles para evaluar el estado de la empresa, no constituyen los productos finalesde un proyecto de arquitectura empresarial. Los entregables de estos proyectos, sin embargo,generalmente se construyen a mano (a partir de los modelos), por lo que son propensos aerrores en formato y contenido, requieren esfuerzo manual y su actualizacion en el tiempopuede tornarse poco eficaz o incorrecta.

La importancia de la arquitectura empresarial para una organizacion ha sido retomadaen numerosas publicaciones. Fischer et al. [3] descomponen su relevancia para el manejodel cambio en tres aspectos que cubre: (a) propagacion de estrategias y cambios a nivel desoftware e infraestructura, (b) soporte a transformaciones consistentes llevadas a cabo porinnovaciones tecnologicas y (c) desacoplamiento de arquitecturas orientadas al negocio yorientadas a tecnologıa. Sin embargo, senalan, resulta necesario un mantenimiento continuode los entregables y un diseno organizacional que permita la consistencia de los modelos enel tiempo para que resulte realmente efectiva para la organizacion. Abd Razak et al. [4]senalan que posterior al desarrollo de la arquitectura empresarial, la implementacion de estadepende, entre otros elementos, de la capacidad de los adoptantes de interpretar correcta-mente lo indicado por el arquitecto, lo que respalda la importancia de unos entregables bienconstruidos y facilmente mantenibles.

4 Diseno y especificaciones

4.1 Definicion del problema

Los entregables de proyectos de arquitectura empresarial generalmente se construyen amano, por lo que son propensos a errores en formato y contenido, requieren esfuerzo manualy su actualizacion en el tiempo puede tornarse poco eficaz o incorrecta. El desarrollo deuna herramienta que automatice la generacion de los entregables a partir de formatos queestandaricen el desarrollo de los modelos solucionarıa ambas problematicas.

4.2 Especificaciones

Requerimientos funcionales

• La herramienta debe permitir al usuario crear una cuenta.

• La herramienta debe permitir al usuario iniciar sesion.

• La herramienta debe permitir al usuario cambiar la contrasena.

• La herramienta debe permitir al usuario editar el portafolio de servicios.

• La herramienta debe permitir al usuario subir una imagen del modelo ontologico.

7

• La herramienta debe permitir al usuario editar el balance general.

• La herramienta debe permitir al usuario editar los flujos de caja.

• La herramienta debe permitir al usuario editar el estado de perdidas y ganancias.

• La herramienta debe permitir al usuario consultar los estados financieros.

• La herramienta debe permitir al usuario editar el componente motivacional.

• La herramienta debe permitir al usuario editar las estrategias de negocio.

• La herramienta debe permitir al usuario editar el plan estrategico.

• La herramienta debe permitir al usuario editar las acciones de transformacion.

• La herramienta debe permitir al usuario editar el catalogo de proyectos.

• La herramienta debe permitir al usuario editar el mapa de capacidades.

• La herramienta debe permitir al usuario agregar capacidades predefinidas al mapa decapacidades.

• La herramienta debe permitir al usuario editar el catalogo de cargos.

• La herramienta debe permitir al usuario subir una imagen del organigrama.

• La herramienta debe permitir al usuario editar la cadena de valor.

• La herramienta debe permitir al usuario editar el catalogo de procesos.

• La herramienta debe permitir al usuario editar el modelo de recursos.

• La herramienta debe permitir al usuario editar el modelo de recursos TI.

• La herramienta debe permitir al usuario editar el catalogo de componentes tecnologicos.

• La herramienta debe permitir al usuario editar el catalogo de aplicaciones.

• La herramienta debe permitir al usuario editar el modelo operativo.

• La herramienta debe permitir al usuario editar los indicadores operativos.

• La herramienta debe permitir al usuario editar los indicadores estrategicos.

• La herramienta debe permitir al usuario editar los indicadores externos.

• La herramienta debe permitir al usuario generar un archivo .docx con la arquitecturaempresarial.

• La herramienta debe permitir al usuario descargar el archivo. docx con la arquitecturaempresarial.

• La herramienta debe permitir al usuario borrar el archivo .docx con la arquitecturaempresarial.

8

Requerimientos no funcionales

• La herramienta debe ser accesible desde cualquier dispositivo dentro de la red en laque este el host que la despliegue.

• El documento con la arquitectura empresarial debe poder generarse a demanda delusuario.

• Un usuario debe poder ver y editar solo la informacion de su propia arquitecturaempresarial.

• La arquitectura empresarial de un usuario debe ser persistente.

Soluciones aproximadas

Debido a la naturaleza del proyecto y el problema que intenta resolver, una solucion incom-pleta al problema pertenecerıa a dos posibles grupos:

• Ausencia de modulos: Una herramienta incompleta podrıa carecer de los modulosnecesarios (descritos en la seccion 2 del documento) para crear todos los artefactos quecomponen la arquitectura empresarial. Dado que, en terminos del documento entre-gable, algunos artefactos consisten unicamente en la carga de una imagen del modelo,la herramienta podrıa prescindir de modulos para estos artefactos y ser consideradasuficiente.

• Especializacion: Una de las condiciones establecidas es que la herramienta funcionepara cualquier tipo de empresa; una solucion inexacta aceptable podrıa aproximarseal problema cambiando el diseno de los modulos para que solo se pudieran modelarciertos tipos de organizaciones. Ejemplos de lo anterior podrıan incluir la delimitacionde contenido que se puede incluir en los modelos. Sin embargo, estas limitacionesdeberıan verse compensadas con beneficios en otros aspectos en el modelado, comopueden ser menor tiempo para desarrollar la arquitectura o mayor automatizacion delproceso.

4.3 Restricciones

Dadas las necesidades actuales de la propuesta, se considera que solo existen restriccionesen los siguientes terminos:

• Economicos: La herramienta exige una maquina que, siempre que la herramienta searequerida, este encendida y conectada a la red. Ademas, esta maquina debe contar consuficiente espacio de almacenamiento para almacenar los datos de las arquitecturas,las imagenes necesarias y los documentos generados.

• Mantenimiento: La herramienta no incluye pruebas automaticas sobre su fun-cionamiento, interfaces o estado del host, por lo que su funcionamiento prolongado

9

a lo largo del tiempo requiere un esfuerzo manual (en terminos del manejo de alma-cenamiento, correccion de posibles errores no detectados durante el desarrollo, entreotros).

5 Desarrollo del diseno

5.1 Recoleccion de informacion

En primeras instancias, la informacion empleada fue la descrita en la seccion 3.2 del doc-umento, que dio la contextualizacion necesaria para entender el problema y su relevancia.Posteriormente, con el fin de empezar el proceso de diseno, se emplearon otros recursos queestablecieran los elementos esenciales de una arquitectura empresarial.

Villalobos [5] describe a alto nivel cada uno de los siete modelos principales, haciendoenfasis en el mapa de capacidades. En [6], Villalobos detalla el modelo de negocio y proveelas pautas para cada uno de los artefactos que lo componen. Para el resto de modelos,Villalobos et. al [7] describen en gran detalle cada uno de ellos a traves de metamodelos(que establecen la informacion mınima que deben contener). A partir de la informacionrecolectada, se disenaron, para cada modulo, los artefactos a incluir en la herramienta.

5.2 Alternativas de diseno

Tecnologıas

Full-Stack Framework

Meteor fue la opcion escogida debido a las siguientes razones: todo el desarrollo se haceen un solo lenguaje (JavaScript), permite un desarrollo mas rapido al manejar aplicacionesen tiempo real por defecto, ofrece numerosos paquetes ideales para la herramienta que per-miten ahorrar tiempo (para manejo de cuentas, generacion del documento, embellecimientode la interfaz, etc.), y la curva de aprendizaje es amigable con los desarrolladores pocoexperimentados con un framework de desarrollo web.

Otras opciones que fueron consideradas se listan a continuacion:

• Express.js: A pesar de compartir ventajas con Meteor, brinda total libertad paraestructurar al proyecto y escoger como implementar las tareas, lo que puede generardemoras en el desarrollo al no contar con una manera comunmente recomendada dehacer ciertas cosas, especialmente con desarrolladores poco experimentados.

• Ruby on Rails: Su curva de aprendizaje es mas alta comparada con la de Meteor,lo que podrıa haber imposibilitado el avance planeado del proyecto.

10

Front End Framework

Se escogio la librerıa React dado su minimalismo y la facilidad de uso con Meteor.De nuevo, dado que el proyecto fue realizado por desarrolladores con poca experiencia endesarrollo web, se priorizo una curva de aprendizaje baja, y el desarrollo con React esintuitivo y veloz. Ademas, el desarrollo por componentes de React permite una separacionmejor de los elementos de la interfaz y conduce a un desarrollo mas modular.

Otras opciones que fueron consideradas se listan a continuacion:

• Blaze: A pesar de sus similitudes con React, los tutoriales de la comunidad cubrenmas implementaciones de tareas esenciales para la herramienta en Meteor-React, porlo que se podrıa haber encontrado con potenciales complicaciones en el desarrollo.

• Angular: Su curva de aprendizaje es mas alta comparada con la de React, tanto enconceptos iniciales como en tareas mas avanzadas, ademas que sus tiempos de cargason mayores a los de React, lo que demorarıa las pruebas durante el desarrollo.

Paradigma de diseno

A traves de la librerıa Materialize, la interfaz grafica de la herramienta esta basada enMaterial Design , el paradigma definido por Google. Se empleo esta opcion de disenodebido a dos motivos: en primer lugar, implementar la librerıa en el proyecto es un procesosencillo, y los cambios en la interfaz se aplican automaticamente, lo que permitio concentrarlos esfuerzos en el desarrollo y la funcionalidad de cada componente. En segundo lugar,la otra alternativa comunmente usada, Flat Design, no se considero adecuada para lospropositos del proyecto. A traves de la herramienta, de acuerdo a los propositos definidos,el usuario debe ser capaz de completar los modelos de la arquitectura empresarial de formarapida y estructurada. Dada la gran simplicidad y minimalismo grafico, el uso de una interfazcon Flat Design puede tornarse menos intuitiva que una hecha segun Material Design, loque podrıa entorpecer el desarrollo de los modulos.

Patron de diseno

La herramienta esta planeada para ser implementada con un patron cliente-servidor. Sepretende brindar a los usuarios la disponibilidad de tener la informacion de sus arquitecturasen la red, en lugar de estar limitadas a un solo equipo local, y la posibilidad de actualizary generar el documento entregable en cualquier momento.

Dados los objetivos de la herramienta, desarrollar la aplicacion web de manera localtambien habrıa sido viable, con las limitaciones que esto supondrıa.

11

6 Implementacion

6.1 Descripcion de la implementacion

A continuacion, se describen las etapas en las que se dividio el proyecto, junto con el detallelos elementos implementados en cada una.

Conceptualizacion

Durante la primera semana del proyecto, se establecio el proposito de la herramienta y seidentificaron los requerimientos funcionales a alto nivel. Estos fueron descritos en terminosde los siete modelos de una arquitectura empresarial (se listan en la seccion 2 del documento),junto con la nocion del flujo de trabajo al que se querıa llegar al usar la herramienta. Luego,se asignaron roles de trabajo para la siguiente etapa: mientras uno de los miembros desar-rollarıa el diseno de cada modulo, describiendo la funcionalidad y la informacion requeridaen cada uno, el otro realizarıa el despliegue de una aplicacion web y se encargarıa del manejode cuentas de usuario.

Diseno de los modulos

En esta etapa, se realizo un bosquejo inicial que describiera un funcionamiento aproximadoal esperado para cada modulo y los datos que deberıan ser ingresados para cada elementode los modelos. Para ello, se empleo la herramienta Proto.io, con la cual se establecieron loscomponentes graficos para cada pantalla de la herramienta. A continuacion, se muestranlos disenos producidos en esta etapa.



En el diseno, cada servicio tiene un identificador, un nombre, un objeto de negocio yun tipo de cliente (los tipos de clientes se definen en el editor de estructura de negocio).

Ilustracion 1: Diseno de un solo servicio en el portafolio

Las operaciones de cada servicio se crean al introducir el nombre. Cada servicio tieneuna lista desplegable de sus operaciones.

12

Ilustracion 2: Diseno de lista de operaciones del servicio

Para crear otro servicio, se introduce el nombre del servicio. Este ultimo es creado conuna lista para anadir sus operaciones.

Ilustracion 3: Diseno de varios servicios en el portafolio


El diseno del modulo consiste en un boton que permite subir la imagen del modelo.

Ilustracion 4: Modulo del modelo ontologico sin una imagen subida

Subida la imagen, esta se muestra al ingresar al modulo.

13

Ilustracion 5: Modulo del modelo ontologico con una imagen subida

– Estructura de negocio y modelo de canales

Este modulo esta desarrollado alrededor del trabajo previo de Sanchez, que consiste enun editor web para la estructura de negocio en la arquitectura. Este editor fue acopladoa la herramienta, para que a partir de lo modelado en este, se guardara la informacionen la base de datos de la herramienta.

Ilustracion 6: Diseno de la vista basica del editor

En el editor, cada componente puede ser un tipo de cliente, de forma que en el portafoliode servicios se haga el cruce con este.

14

Ilustracion 7: Diseno de edicion de un componente

El editor permite asignar el tipo de canal para cada uno de los que se hayan agregadoen la estructura.

Ilustracion 8: Diseno de edicion de un canal

Cada canal tiene una lista de actividades (que componen el modelo de canales) yoperaciones (asociadas a un servicio del portafolio de servicios).

15

Ilustracion 9: Diseno de la lista de actividades de un canal

Ilustracion 10: Diseno de la lista de operaciones de un canal

A partir de la estructura que el usuario modele en el editor, se obtendran dos visual-izaciones: el cruce de operaciones y canales, y el modelo de canales.

16

Ilustracion 11: Diseno del cruce de operaciones y canales

Ilustracion 12: Diseno del modelo de canales

• Modelo financiero En el diseno, este modelo serıa generado automaticamente al subiruna hoja de calculo (con un formato especıfico generada por la herramienta) con losdatos de la empresa. Sin embargo, dado que el desarrollo de este modelo inicio en lasultimas semanas, las complicaciones encontradas para el procesamiento de un archivo asıimpidieron seguir el diseno y se tomo otra aproximacion, la cual sera descrita en la etapade desarrollo de los modulos.


En el diseno, los estados financieros (balance general, estado de perdidas y ganan-cias, y flujos de caja) son generados a partir del archivo subido y se mostrarıan en laherramienta como tablas. En la Ilustracion se muestra un ejemplo de la interfaz.

17

Ilustracion 13: Diseno ejemplo de uno de los estados financieros


Los indicadores son calculados con las cifras de los estados financieros, ademas depermitir el seguimiento de sus valores en el tiempo.

Ilustracion 14: Diseno de los indicadores financieros



El diseno consiste en un formulario que permite ingresar la informacion de cada ele-mento.

18

Ilustracion 15: Diseno del componente motivacional


Con el fin de separar los elementos, se dividio este modelo en tres partes, en concor-dancia con Villlalobos et. al [7], tal como muestra la Ilustracion 16.

Ilustracion 16: Diseno de los fines del plan estrategico

19

Ilustracion 17: Diseno de los medios del plan estrategico

Ilustracion 18: Diseno de los indicadores de logro del plan estrategico


En el diseno, las estrategias tienen una categorıa y una ID asociada, segun la categorıaque se escoja. Existen cuatro categorıas para las estrategias: Global, Por canal, Porrecurso y Por servicio. Similar a los servicios del portafolio, la estrategia se crea alingresar el nombre.

Ilustracion 19: Diseno de las estrategias de negocio


20

Segun el diseno, las acciones de transformacion contienen suficiente informacion parajustificar su creacion separada de los proyectos. Solo se diseno el formato para cadaaccion, sin especificar la lista a usar.

Ilustracion 20: Diseno de las acciones de transformacion

– Catalogo de proyectos

Los proyectos del mapa de ruta contienen una lista de acciones de transformacion, quese crean por separado. Solo se diseno el formato para cada proyecto, sin especificarcomo se listan.

Ilustracion 21: Diseno de los proyectos del mapa de ruta


21

El mapa de capacidades fue pensado para dos propositos: crear paquetes, subpaquetes ycapacidades; y seleccionar, de un catalogo predefinido, subpaquetes y capacidades paraagregarlos al mapa. El diseno para la creacion y el despliegue se muestran en las Ilustra-ciones 22 a 24.

Ilustracion 22: Diseno de la creacion de paquetes

Ilustracion 23: Diseno de la creacion de subpaquetes

22

Ilustracion 24: Diseno de la creacion de capacidades



El diseno establece, debido a las listas de funciones y cargos dependientes, que el formatodebe ser el que se muestra en la Ilustracion 25, mientras que la Ilustracion 26 detallala interfaz para editar un cargo.

Ilustracion 25: Diseno del catalogo de cargos

23

Ilustracion 26: Diseno de la edicion de un cargo

– Organigrama

El organigrama se disena de forma que se genere automaticamente segun el catalogode cargos, dado que en este se definen las dependencias entre cargos.

Ilustracion 27: Diseno del organigrama en la herramienta


– Cadena de valor

El diseno de la cadena de valor define dos partes: el ingreso de las actividades primariasy de soporte, y la carga de la imagen con el diagrama. Las ilustraciones 28 y 29 muestranel diseno de la primera.

24

Ilustracion 28: Diseno de las actividades de soporte

Ademas, las actividades primarias, dado que son procesos de la empresa, son agregadasal catalogo de procesos (descrito en el siguiente ıtem del Modelo de procesos) para sercompletadas en dicho modulo.

Ilustracion 29: Diseno de las actividades primarias

Las Ilustraciones 30 y 31 muestran la carga de la imagen del diagrama. El disenoplantea que la imagen deberıa ser escaneada en busca de las actividades definidas enla parte anterior.

25

Ilustracion 30: Diagrama de la cadena de valor sin una imagen cargada

Ilustracion 31: Diagrama de la cadena de valor con una imagen cargada



Similar al diseno de otros modelos, cada recurso se crea al ingresar el nombre, y contieneuna lista desplegable de los servicios que presta.

26

Ilustracion 32: Diseno del modelo de recursos

– Modelo de recursos TI

El diseno de este modelo es una extension del anterior, al agregar la lista de componentesque soporta (la cual consume los datos del catalogo de componentes).

Ilustracion 33: Diseno del modelo de recursos TI

– Catalogo de componentes tecnologicos

El diseno consiste enla creacion de los componentes al ingresar el nombre.

Ilustracion 34: Diseno del catalogo de componentes tecnologicos


El diseno del catalogo es similar al catalogo de cargos, debido a la lista de capacidadesy componentes tecnologicos.

27

Ilustracion 35: Diseno del catalogo de aplicaciones


El diseno define que cada ıtem del modelo empieza al agregarse una capacidad, cadauna de ellas con dos listas desplegables con los cargos que la implementan y los recursosque necesita.

Ilustracion 36: Diseno del modelo operativo


En el diseno se tienen tres listas en una pantalla que recogen los indicadores de los trestipos.

28

Ilustracion 37: Diseno de la lista de indicadores

– Creador de etiquetas

Para permitir al usuario el uso de etiquetas personalizadas en los indicadores, se disenael creador de etiquetas como lo indica la Ilustracion 38.

Ilustracion 38: Diseno del creador de etiquetas

– Indicadores operativos

29

El diseno indica que la informacion de un indicador operativo se edita en una pantalla,con las listas de cargos y procesos asociados.

Ilustracion 39: Diseno del catalogo de indicadores operativos

– Indicadores estrategicos

El diseno indica que la informacion de un indicador estrategico se edita en una pantalla.El indicador puede estar asociado a: Canal, Servicio, Recurso o ninguno (Global), loque cambiara los identificadores de la lista correspondiente.

Ilustracion 40: Diseno del catalogo de indicadores estrategicos

30

– Indicadores externos

El diseno indica que la informacion de un indicador externo se edita en una pantalla.Las categorıas a las cuales puede pertenecer un indicador son: Competidores, Mercadoy Entorno.

Ilustracion 41: Diseno del catalogo de indicadores externos

Desarrollo de los modulos

Finalizada la etapa de diseno, los roles para la etapa de desarrollo se establecieron ası: unode los miembros se encargarıa del modulo de estructura de negocio y modelo de canales, elcual requiere el acoplamiento del editor de la estructura del modelo de negocio, y el otrose encargarıa del desarrollo de los demas modelos. A continuacion se muestra cada uno delos modelos desarrollados, de los cuales se resaltaran las diferencias con el diseno planteado.En el diseno, se contaba con el trabajo previo de un editor para la estructura de negocio.Sin embargo, no fue posible incluirlo en la herramienta a tiempo, por lo que se desarrollaronutilidades en la herramienta que permiten cubrir los modulos respectivos.



El desarrollo final es bastante similar al diseno. Se requiere completar toda la infor-macion del servicio para crearlo, y los campos estan encima de la lista, en lugar de alfinal.

31

Ilustracion 42: Portafolio de servicios desarrollado


La implementacion es consistente con el diseno.

Ilustracion 43: Modulo del modelo ontologico

– Estructura de negocio

Se permite subir una imagen que sera incluida en el documento entregable.

32

Ilustracion 44: Modulo de la estructura de negocio

– Modelo de canales

La herramienta permite agregar los canales, y asociarlos con operaciones del portafoliode servicios y actividades que el arquitecto agregue.

Ilustracion 45: Modulo del modelo de canales

– Tipos de clientes

Segun lo que el arquitecto haya definido en su estructura de negocio, la herramienta lepermite enlistar los tipos de clientes que seran empleados en el portafolio de servicios.

33

Ilustracion 46: Modulo de los tipos de clientes

• Modelo financiero En la implementacion, se desarrollaron los formatos de los estados fi-nancieros en la herramienta web, en lugar de usar un archivo y procesarlo. Los indicadoresfinancieros se calculan automaticamente con los valores ingresados.


La Ilustracion muestra el balance general, cuyo formato es similar para los demas; sesuman las cantidades parciales a lo largo del formato y se muestran las sumas relevantespara facilitar la lectura.

Ilustracion 47: Balance general en la herramienta


34

Se fijan 3 indicadores financieros que son calculados con los valores de los estadosfinancieros. Ademas, de acuerdo a su valor, se genera una explicacion verbal del sig-nificado.

Ilustracion 48: Indicadores financieros



La implementacion es consistente con el diseno planteado.

Ilustracion 49: Diseno del componente motivacional


Se empleo el diseno presentado en la implementacion.

35

Ilustracion 50: Fines del plan estrategico

Ilustracion 51: Medios del plan estrategico

36

Ilustracion 52: Indicadores de logro del plan estrategico


En la implementacion, se debe ingresar toda la informacion de la estrategia para crearla,y los campos para ello estan en la parte superior de la lista.

Ilustracion 53: Estrategias de negocio


En la implementacion se decidio colocar la lista al lado de la accion de transformacionactual.

Ilustracion 54: Acciones de transformacion del mapa de ruta

37

– Catalogo de proyectos

Similar a las acciones de transformacion, se tiene la lista de proyectos en la parte lateraldel proyecto actual.

Ilustracion 55: Proyectos del mapa de ruta


Se cambio el diseno del mapa de capacidades en la implementacion, teniendo listas sepa-radas para paquetes, subpaquetes y capacidades. Estas listas pueden ser filtradas usandolas listas desplegables que aparecen en la parte superior; escogiendo un ıtem de la listaaparecen solo los subpaquetes o capacidades que pertenezcan a dicho ıtem. Este filtropermite la adicion de nuevos elementos con mayor claridad de que esta presente en elmapa.

Ilustracion 56: Mapa de capacidades

38

Respecto a las capacidades y subpaquetes predefinidos, se tienen dos listas que permitenseleccionar el destino del ıtem.

Ilustracion 57: Catalogo de subpaquetes y capacidades predefinidas



El diseno establecido se ejecuta en la implementacion.

Ilustracion 58: Diseno del catalogo de cargos

39

– Organigrama

En la implementacion, no fue posible seguir el diseno del organigrama generado au-tomaticamente, por lo que se cambio por la subida de una imagen con el organigrama.

Ilustracion 59: Diseno del organigrama en la herramienta


– Cadena de valor

En la implementacion se siguio el diseno establecido tanto en las actividades de soportecomo en las primarias. Sin embargo, se opto por omitir la carga de la imagen con lacadena, dado que esta sera creada con el documento entregable.

Ilustracion 60: Actividades de soporte

40

Ilustracion 61: Actividades primarias

– Catalogo de procesos

Respecto al diseno planteado, se reemplazo la lista separada del proceso actual por unalista lateral al proceso actual.

Ilustracion 62: Catalogo de procesos



En la implementacion, se debe completar la informacion del recurso para crearlo, y loscampos se ubican en la parte superior. La lista desplegable se ubica en la parte lateral.

41

Ilustracion 63: Modelo de recursos

– Modelo de recursos TI

Similar al modelo de recursos, las listas desplegables se ubican en la parte lateral.

Ilustracion 64: Modelo de recursos TI

– Catalogo de componentes tecnologicos

La implementacion sigue el diseno establecido.

42

Ilustracion 65: Catalogo de componentes tecnologicos


El diseno establecido se mantiene en la implementacion.

Ilustracion 66: Catalogo de aplicaciones


En la implementacion se colocan las listas desplegables en la parte lateral.

43

Ilustracion 67: Diseno del modelo operativo


En la implementacion se elimina la pantalla con tres listas de indicadores, y se decideubicarlas por separado en tres modulos distintos. Para los tres tipos de indicadores, setiene la lista en la parte lateral, como se muestra en las Ilustraciones.

– Creador de etiquetas

La creacion de etiquetas es implementada tal como esta en el diseno.

Ilustracion 68: Creador de etiquetas

– Catalogo de indicadores operativos

44

Ilustracion 69: Indicadores operativos

– Catalogo de indicadores estrategicos

Ilustracion 70: Indicadores estrategicos

– Catalogo de indicadores externos

45

Ilustracion 71: Indicadores externos

Construccion del documento entregable

Una vez implementados todos los modulos, la siguiente etapa cubrio el paso de la infor-macion en la base de datos a un documento entregable con la arquitectura empresarial. Deldocumento se esperaban las siguientes caracterısticas mınimas:

• Estructuracion por capıtulos.

• Tabla de contenido para navegacion en el documento.

• Organizacion de la informacion en formatos.

A continuacion, se muestra un ejemplo del resultado obtenido para cada capıtulo (excep-tuando aquellos que consisten en mostrar la imagen subida, como el modelo ontologico y elorganigrama):

• Portafolio de servicios:

46

Ilustracion 72: Portafolio de servicios en el documento

• Modelo de canales:

47

Ilustracion 73: Modelo de canales en el documento

• Cruce de canales y operaciones:

Ilustracion 74: Cruce de canales y operaciones en el documento

48

• Balance general:

Ilustracion 75: Balance general en el documento

• Estado de ingresos y egresos:

Ilustracion 76: Estado de ingresos y egresos en el documento

49

• Flujo de caja:

Ilustracion 77: Flujo de caja en el documento

• Indicadores financieros:

Ilustracion 78: Indicadores financieros en el documento

• Componente motivacional:

50

Ilustracion 79: Componente motivacional en el documento

• Estrategias de negocio:

Ilustracion 80: Estrategias de negocio en el documento

• Objetivos:

Ilustracion 81: Objetivos en el documento

• Estrategias:

51

Ilustracion 82: Estrategias en el documento

• Metas:

Ilustracion 83: Metas en el documento

• Tacticas:

Ilustracion 84: Tacticas en el documento

• Indicadores de logro:

Ilustracion 85: Indicadores de logro en el documento

• Acciones de transformacion:

52

Ilustracion 86: Accion de transformacion en el documento

• Proyectos:

Ilustracion 87: Proyecto en el documento

• Mapa de capacidades:

53

Ilustracion 88: Muestra del mapa de capacidades en el documento

• Catalogo de cargos:

54

Ilustracion 89: Cargo en el documento

• Cadena de valor:

55

Ilustracion 90: Cadena de valor en el documento

• Catalogo de procesos:

56

Ilustracion 91: Proceso en el documento

• Modelo de recursos:

57

Ilustracion 92: Modelo de recursos en el documento

• Modelo de recursos TI:

Ilustracion 93: Recurso de TI en el documento

• Catalogo de componentes tecnologicos:

58

Ilustracion 94: Componentes tecnologicos en el documento

• Catalogo de aplicaciones:

Ilustracion 95: Aplicacion en el documento

• Modelo operativo:

59

Ilustracion 96: Muestra del modelo operativo en el documento

• Indicadores operativos:

60

Ilustracion 97: Indicador operativo en el documento

• Indicadores estrategicos:

Ilustracion 98: Indicador estrategico en el documento

• Indicadores externos:

Ilustracion 99: Indicador externo en el documento

6.2 Resultados esperados

El resultado final de la herramienta cumple con los objetivos descritos en la seccion 3.1, yresuelve el problema descrito en la seccion 4.1. La totalidad de los modelos que componenuna arquitectura empresarial estan cubiertos.

61

Herramientas empleadas

• Meteor

Se empleo Meteor como opcion de Full-Stack Framework dado solo usa JavaScript, laspruebas durante el desarrollo son rapidas dado que maneja aplicaciones en tiempo real, yel desarrollo de las tareas planeadas para el proyecto esta respaldado por diversos ejemplosy tutoriales que, dada la poca experiencia de los desarrolladores, son indispensables parael cumplimiento de los plazos.

• Docx

Esta librerıa permite generar documentos .docx empleando JavaScript. La documentacionde la librerıa permite su uso efectivo y, en el contexto del proyecto, provee una utilidadcompatible y que es esencial para el proyecto.

Formas de implementacion

Arquitectura cliente-servidor

Se empleo este estilo de arquitectura dadas las necesidades de los usuarios esperados delproyecto. Tener la informacion de la arquitectura en un lugar accesible por la red, y poderactualizar y generar el documento entregable a su pedido son caracterısticas esenciales parael arquitecto empresarial.

Estructura de la base de datos

La base de datos esta compuesta por 39 colecciones, de las cuales una es para el manejode usuarios y tres son para manejar las imagenes de la arquitectura. Es decir, la base dedatos cuenta con 35 colecciones para almacenar la informacion de las arquitecturas de losusuarios. El numero de colecciones tan elevado permite tener una separacion clara de dondeestan los datos, y permite una facil construccion del documento entregable.

7 Validacion

7.1 Metodos

Debido a la naturaleza del proyecto, la validacion consistio en la construccion de la ar-quitectura empresarial de una empresa real (Envasar SAS), la generacion del documentoentregable respectivo y la evaluacion del mismo por parte de la empresa. A continuacion sedescriben las etapas en las que se desarrollo el proceso de validacion.

Recoleccion de informacion

Por medio de correo electronico, la gerencia de la empresa proveyo 15 documentos que,en combinacion con una visita a la empresa, dieron la informacion necesaria para obtener:

62

• Estados financieros

• Cargos

• Recursos

• Procedimientos

• Indicadores

Ademas de estos elementos explıcitos, con la informacion dada se derivo la informacionrestante necesaria para completar la arquitectura de la empresa.

Preparacion de datos

Dado que la informacion descrita en la etapa anterior fue recogida en forma de manualesy documentos, fue necesario llevar estos datos a un formato util. En primer lugar, seordenaron en 14 archivos .csv, que corresponden a las 14 colecciones de la base de datosque no involucraban cruces con otros modelos (como pudiera ser el modelo operativo).Posteriormente, se escribio un programa sencillo en Java que produjera archivos de textocon las sentencias necesarias (con el formato db.[coleccion].insert(datos) para introducirlosmanualmente en la base de datos. No se introdujeron directamente dado que con estemetodo, se prevenıan errores al procesarlos en la herramienta.

Una vez ingresados los datos en la herramienta, se hicieron los cruces entre modelosusando los modulos de la herramienta. Esto permitio probar el correcto funcionamiento dela misma y evaluar la experiencia de usuario al manejarla.

Entrega del documento entregable

Luego de haber construido la arquitectura dentro de la herramienta, se genero el docu-mento entregable. Dado que Envasar SAS no contaba con informacion del plan estrategicoo del mapa de ruta, se eliminaron manualmente los capıtulos respectivos. Otro cambiomanual fue el cambio en el tamano de imagenes de procesos y del organigrama, dado queno resultaron adecuados en la generacion. Finalizada la edicion se enviaron los dos archivos(el primero, sin editar, y el segundo con los cambios) a la gerencia de la empresa.

7.2 Validacion de resultados

La empresa expreso su aprobacion (respuesta en los apendices) sobre el resultado, indicandocompletitud y claridad en el documento. Sin embargo, resalto sobre el documento sin editarque algunas de las imagenes no tenıan el tamano adecuado, lo que concuerda con la falta deprocesamiento de imagenes en la generacion del documento.

A pesar de la observacion dada, la herramienta culmino el alcance de los objetivos conexito; es capaz de modelar una empresa sin restricciones sobre su tamano o negocio, y eldocumento entregable reduce en gran medida el trabajo manual que supondrıa construirlodesde cero.

63

8 Conclusiones

8.1 Discusion

Segun la validacion de resultados y el analisis de los mismos hecho en el documento, esposible afirmar que la herramienta desarrollada cumple satisfactoriamente con lo planeado:permite modelar la arquitectura empresarial de cualquier empresa en su totalidad paraposteriormente, generar automaticamente un documento entregable para reducir el trabajomanual y la posibilidad de errores en digitacion o formato. Las decisiones de diseno, in-cluyendo las tecnologıas empleadas, permitieron el desarrollo de los modulos en el plazo detiempo establecido. Se desarrollaron los 23 modulos disenados, por lo que aquello planeadoque no se realizo fueron aspectos de forma.

Debido a las condiciones iniciales en las que se planteo el proyecto, con desarrolladoressin experiencia en aplicaciones web, el desarrollo de la herramienta se vio limitado a cumplircon el objetivo, por lo que los logros en diseno de interfaz e innovacion en los requerimien-tos no fueron los mejores posibles. En etapas tempranas de conceptualizacion, el uso deherramientas de reconocimiento de texto y de grafico de datos habıa sido considerado, sinembargo, para cumplir los plazos de tiempo se emplearon soluciones mas simples.

Se encontraron dificultades con el manejo de las imagenes que el usuario sube, paramantenerlas en la maquina de la herramienta, mostrarlas, y luego incluirlas en el documentoentregable. Debido a la falta de tutoriales oficiales de los desarrolladores de la librerıaempleada, el escaso contenido que trataba el desarrollo con ella fue estudiado intensivamenteen busca de entender su uso correcto, que fue finalmente logrado despues de varias horas deintento. Sin embargo, el manejo en el documento no fue el mas adecuado; las dimensionesde las imagenes no cambian respecto al tamano de la imagen subida, por lo que se requiereuna edicion manual del documento en la mayorıa de casos.

8.2 Trabajo futuro

De acuerdo con los propositos del proyecto desarrollado, el trabajo futuro puede ser clasifi-cado en dos categorıas: extensiones de la herramienta y nuevas aproximaciones al problemadescrito.

Extensiones de la herramienta

Manejo de versiones

La herramienta, tal como fue disenada, permite una construccion metodica de la arquitec-tura empresarial por medio de formatos. Sin embargo, no permite tener un historial deversiones que permita monitorear las actualizaciones en el tiempo, aspecto que podrıa servital para organizaciones que esten en constante cambio o que esten atravesando periodos detransformacion extendidos. La herramienta deberıa permitir ver las diferencias por modulo

64

entre versiones para aportar el valor esperado.

Visualizaciones

El documento entregable generado por la herramienta emplea los identificadores para hacercruces entre los distintos modelos, sin embargo, no agrega ningun recurso grafico que pudiesecomplementar los formatos para facilitar la lectura. Entre las visualizaciones que podrıandesarrollarse se encuentran:

• Grafico de lıneas con el valor de los indicadores financieros en el tiempo

• Lınea de tiempo con los elementos del plan estrategico (empleando las fechas de las metase indicadores de logro)

• Mapa de ruta con las acciones de transformacion (coloreadas segun el proyecto al quepertenecen)

Estas visualizaciones deberıan calcularse con los cambios en los artefactos respectivos, eincluirse en un capıtulo aparte en el documento o dentro del capıtulo del modelo pertinente.

Nuevas aproximaciones al problema

Durante la etapa de conceptualizacion, desarrollada en la seccion 6.1 del documento, seconsidero la posiblidad de desarrollar una automatizacion parcial del desarrollo de la ar-quitectura a partir de un patron de modelo de negocio. Villalobos [6] define un patroncomo una estructura de negocio que es comun a muchas empresas, y define 18 patronescon sus estructuras respectivas. Una futura aproximacion al problema, iniciarıa la creacionde la arquitectura con la seleccion de un patron y, segun el seleccionado, se generarıa au-tomaticamente un conjunto de elementos esperados para algunos de los artefactos de laarquitectura. Estos elementos incluirıan actividades, capacidades, cargos, recursos, etc. queserıan genericos para el patron de negocio y que pudieran describir parcialmente la empresaespecıfica o que guiase el desarrollo para el arquitecto. La obtencion de estos elementosesperados para cada patron requerirıa un estudio previo que estableciera aquellos aspectosuniversales de cada patron.

9 Referencias

1. F. Goethals. An Overview of Enterprise Architecture Framework Deliverables. SSRNElectronic Journal. 2005.

2. J. Saenz, S. Cardenas, Steve, M. Sanchez, J. Villalobos. Semi-Automated Model-BasedGeneration of Enterprise Architecture Deliverables. 2017.

3. R. Fischer, S. Aier, R. Winter. A Federated Approach to Enterprise ArchitectureModel Maintenance. EMISAJ. 2007.

65

4. R. Abd Razak, Z. Dahalin, H. Ibrahim, I. Yusop, M. Kasiran. Investigation on theimportance of enterprise architecture in addressing business issues. 2011.

5. J. Villalobos. El Mapa de Capacidades de Negocio. Lecturas para Arquitectos deNegocio. 2019

6. J. Villalobos. El Modelo de Negocio. Lecturas para Arquitectos de Negocio. 2019

7. J. Villalobos, O. Gonzalez, M. Romero, M. Sanchez. Notas de Clase ArquitecturaEmpresarial. 2019

10 Apendices

• Pagina web de Envasar SAS: www.envasarsas.com

Ilustracion 100: Respuesta de la gerencia de Envasar SAS

66

Herramienta de soporte a la construcci on de una ...

Documents

Transcript of Herramienta de soporte a la construcci on de una ...