La lección de la semana: Arquitectura empresarial

La semana pasada me dediqué a aprender sobre arquitectura empresarial. ¿Qué es? Es una práctica que consiste en adoptar una visión holística a la hora de analizar, diseñar, planificar o implementar una estrategia empresarial[1].

Hay diferentes marcos que definen y dividen la arquitectura empresarial en diferentes subconjuntos o niveles. Yo me estoy guiando, de momento, por la definición y división que hace The Open Group que es el autor del TOGAF, uno de los marcos que he visto citar bastante en el material que he estado leyendo. Otros marcos estándar incluyen el de Zachman, EA3 y DoDAF, pero una cosa a la vez.

Según The Open Group, la arquitectura empresarial se compone de cuatro subconjuntos de arquitectura:

  1. La arquitectura de negocios: se refiere a la capa funcional de una empresa, la que describe qué hace una empresa y cómo lo hace.
  2. La arquitectura de datos: se refiere a los modelos que dictan qué datos recolecta la empresa, cómo los almacena, cómo están relacionados, etc.
  3. La arquitectura de aplicaciones: se refiera a los sistemas y sus interacciones, así como sus relaciones con los procesos centrales de la empresa.
  4. La arquitectura tecnológica: se refiere al hardware, software y redes que dan soporte a las aplicaciones.

¿Y cómo estoy haciendo yo uso de esta información?

Mi responsabilidad en el nuevo proyecto al que me han asignado consiste en el análisis y diseño (inicialmente) del componente tecnológico de la empresa. En vista de que a mí me gusta poner manos a la obra enseguida, mi primer intento resultó en un esquema que mezclaba diferentes elementos de las 4 áreas antes mencionadas en una. Esto lo supo porque al sentarme a revisar mi trabajo con un colega, su feedback se centró en la importancia de separar las partes en capas que sirvieran de herramienta de comunicación a diferentes partes.

Así fue como terminé leyendo al respecto y, aunque mi nivel de productividad ha disminuido, me siento segura de que cuando vuelva a poner manos a la obra tendré mucho más claro qué estoy haciendo y cómo hacerlo.

Por otro lado, he ido validando que, independientemente de cuál sea el proyecto en cuestión, tener una idea general de lo que es la arquitectura de la empresa y de los diferentes subconjuntos arquitectónicos que la componen es crucial para tomar decisiones acertadas para el negocio. En mi rol de analista esto es sumamente importante.

 



[1] Como aclara The Open Group, “empresa” en este caso se refiere a una organización o parte de una organización en la que confluyen múltiples sistemas y grupos funcionales en un objetivo común. De manera que, cuando hablamos de arquitectura empresarial nos referimos a la alineación de las diferentes capas, sistemas o grupos que sirven a un mismo  departamento o grupo de trabajo o empresa o grupo de empresas, para lograr un mismo objetivo (o varios).

Aprendiendo UML (Lenguaje Unificado de Modelado)

Imagen 1: UML o Lenguaje Unificado de Modelado

Una de las responsabilidades que tienen los analistas es el modelado de sistemas. Me he dedicado a aprenderlo al tiempo que lo pongo en práctica en la oficina. Se trata, básicamente, de documentar los procesos de una empresa o la manera cómo funciona un sistema. La idea de documentarlos es comprender un proceso, presentarlo a otros departamentos o miembros que se unen a un proyecto, identificar dónde se genera un problema, proponer mejoras o presentar una propuesta de proceso ideal.En vista de que aquí (en la empresa) hasta ahora no se documentaba nada, hay mucho espacio para aprender y jugar, al tiempo que se identifican problemas para los que se pueden proponer soluciones.Hasta ahora he tenido que modelar un par de procesos a fin de entender cómo se lleva a cabo y para identificar problemas. Para lograrlo, me he tenido que valer del Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language).

¿Y qué es el UML?

Es un lenguaje que unifica los elementos de diferentes sistemas de modelado con el objetivo de estandarizar el proceso en las industrias de diseño y modelado de software, así como en los sectores científicos y de negocios.

El objetivo, al ser un lenguaje, es ayudar a comunicar, describir y clarificar de manera efectiva (gráfica) las características de un proyecto, proceso, sistema, etc.

Aunque la mayor parte de la información que consigo en Internet hace referencia al uso de UML en el diseño de sistemas, es decir, como una etapa previa al desarrollo de un sistema, resulta que también se puede utilizar para representar procesos o sistemas ya existentes, como es el caso de nuestra empresa.

Imagen 2: Diagramas disponibles en ArgoUML

Hay muchos programas para modelar usando UML. Mi mentor utiliza Enterprise Architect de Sparx Systems. En teoría yo debería usar la misma herramienta para evitar conflictos por incompatibilidad, pero decidí utilizar una de software libre para que cuando quiera practicar casa no tenga que preocuparme por no tener licencia. La primera que intenté usar fue Violet UML editor, pero me pareció muy básica (irónicamente, porque yo soy principiante). Así que decidí irme por otra: ArgoUML, bastante más completa, con siete tipos de diagramas disponibles (imagen 2).Esta entrada de blog ofrece una amplia variedad de herramientas UML gratuitas de software libre.

Otra opción gratuita y práctica es usar alguna de las aplicaciones disponibles en el mercado de apps de Google Chrome (imagen 3).

Diagramas UML

Resulta que, según lo que se desee modelar, existen diferentes tipos de diagramas.

La idea de los diferentes tipos de diagramas es representar un problema desde perspectivas diferentes. Es como cuando se diseña una casa: hay un plano para el sistema de tuberías que utilizarán los plomeros, otro para el sistema eléctrico que utilizarán los electricistas, otro para la distribución del espacio, etc.

Imagen 3: Herramientas UML para Google Chrome

De la misma manera, un sistema o proceso se puede representar desde diferentes puntos de vista: diagrama de clases (como guía para el programador), diagramas de casos de uso (para identificar las acciones que el usuario realiza con el sistema), diagrama de estados (para entender en qué estado está un objeto en determinado momento), diagrama de secuencias (para identificar las interacciones que hay entre objetos), diagrama de actividades (para representar las actividades que se dan dentro de un caso de uso). De estos, algunos diagramas son estáticos y otros dinámicos, según se estén representando características de la estructura del sistema (estático) o comportamientos del sistema (dinámico).Este es mi primer diagrama (por cuestiones de confidencialidad he borrado el texto). La curva de aprendizaje como Analista sigue cuesta arriba. Ya les seguiré contando.

Diagrama de estados elaborado en ArgoUML

Analista de Negocios. ¿Que qué?

Entre los muchos cambios que se están sucediendo en mi vida, algunos son la causa de los cambios mismos que se están dando en la empresa en la que trabajo. Para darles una idea, cuando comencé, entre Tallin y Londres, éramos un grupo de unas 30 personas y ahora vamos por ochenta.

Este crecimiento es el resultado de los objetivos que persigue la empresa que han obligado a ampliar el personal en las áreas que ya existían, pero también a contratar nuevos perfiles para ejercer roles que antes no había. Entre estos el mío: el de analista.

Con el objetivo de llegar gloriosos al punto B desde el punto A, se decidió que era necesario tener un rol en la empresa dedicado a “traducir” lo que los ejecutivos buscan para que los desarrolladores y demás trabajadores lo implementen eficazmente. Ese es el rol de nosotros los analistas.

¿Analista de qué? Precisamente a esa pregunta busco responder. A medida que me apaño para cumplir con mis responsabilidades, voy documentándome para hacerlo bien hecho. Para ello me paso horas de horas leyendo sobre el tema e identificando habilidades a adquirir y herramientas a manejar que me faciliten el asunto.

Las habilidades del analista son antiguas, más no la profesión. <Esta imagen es cortesía de cliff1066tm /Flickr.com>

Me consigo con que la profesión es, formalmente, algo bastante reciente. Las habilidades en sí han existido siempre, e incluso me parece que identifico algunas en mi anterior profesión como profesora de español. No obstante, el reconocimiento de la posición en sí es algo que apenas ha ido tomando forma. Curiosamente, parece que sin querer queriendo siempre termino involucrándome en perfiles profesionales que no están 100% definidos en el mercado mundial. Lo bueno es que esto me pone ante un panorama desafiante y motivante.

Ahora, a la pregunta que busco responder: ¿Qué es un Analista?

Primero, se me complica definirlo en español, porque no he escuchado nunca a nadie decir “Analista de Negocios”, que es mi título en inglés (Business Analyst), aunque sí me consigo bastante con Analista de Sistemas (Systems Analyst). Me complico porque no deberían ser lo mismo, pero a veces coinciden. De hecho, existe un híbrido que es el Analista de Sistemas y Negocios (Business Systems Analyst).

La cuestión con los Analistas es que sus habilidades se hallan entre profesionales cuyo título no es necesariamente “Analista de Negocios”, sino entre diferentes profesionales, según la ocasión. Algunos ejemplos: gerente de productos, ingeniero de sistemas, ingeniero de requerimientos, arquitecto de sistemas, desarrollador, etc. El rol dedicado exclusivamente al análisis es algo que depende de las necesidades de cada empresa o, incluso, del reconocimiento de la necesidad del rol.

La primera definición oficial, que aparece en la BABOK (Guía para el Cuerpo de Conocimientos del Análisis de Negocios o  BABOK Guide, por sus siglas en inglés), señala que el análisis de negocios es:

un set de tareas y técnicas empleadas como enlace entre las diferentes partes interesadas para entender la estructura, políticas y operaciones de una organización y que busca proponer soluciones que permitan alcanzar las metas de la organización.

Es lo que señalan todos los profesionales a los que, hasta ahora, me he referido: se acepta más como un set de tareas y técnicas más que como una profesión. Pocos tienen la suerte (aparentemente es positivo) de tener el título de analista.

Ya lo tengo claro. Yo soy analista de negocios. <Esta imagen es cortesía de jscreationzs /FreeDigitalPhotos.net>

Y yo, ¿soy analista de sistemas, analista de negocios o las dos cosas?

Nadie lo sabe. Mucho menos yo, aunque estoy más cerca de saberlo que no. Sin embargo, suponiendo que el nombre encaja con la descripción (que no siempre es el caso), diferenciarlos es fácil:

El analista de sistemas se encarga de identificar problemas y espacio para mejoras en los sistemas de la empresa, en el software. Tiene la habilidad de leer e interpretar código. En algunas ocasiones es también capaz de programar y se entiende tranquilamente con los desarrolladores. Personalmente veo la posición como un punto al que llega un ingeniero de software en algún momento de su carrera. Similar al arquitecto.

El analista de negocios, por otro lado, tiene acceso a todas las áreas del negocio e identifica problemas y espacio para mejoras en estas y su relación con los sistemas (o no), traduce lenguaje técnico a los ejecutivos y viceversa, aunque no llega a tener el mismo nivel de conocimiento técnico que el analista de sistemas. Programar, por ejemplo, no es una habilidad de alguien con este perfil. El analista de negocios también se encarga de documentar procesos y modelos de negocios actuales o por ser en una organización.

Volviendo a la pregunta de qué soy yo, me parece que mi título y responsabilidades encajan perfectamente y soy una analista de negocios en formación, puesto que no tengo conocimientos profundos del área de software y estoy aprendiendo a entenderme con los desarrolladores (no basta con tener uno en casa, los hay de todo tipo) y también hago malabares para entenderme con los ejecutivos. Pero al menos el camino que empiezo a recorrer y las responsabilidades que tengo tienen toda la pinta de ser los de analista de negocios.

Así que por hoy, resuelta una cuestión.