¿UNA NUEVA AREA T.I.? – ARQUITECTURA DE TECNOLOGICA – ITSM DEVOPS

En esta ocasión se pretende modelar y usar algunos elementos de arquitectura empresarial para la metodología o mejor toda una cultura de trabajo que está muy de moda y es DEVOPS. Lo que se busca aquí es, sin ser el mayor experto en esta metodología que por excelencia es muy usada aún para desarrollo de software, crear un esquema macro general para esta área, como si fuera un área más del negocio y la haciendo un poco más de énfasis en la arquitectura tecnológica global. Siendo consciente que no soy el mayor experto en DEVOPS haré estas consideraciones para tratar de cumplir con el objetivo de este artículo.

CONSIDERACIONES

  1. 1. Trataré a DEVOPS como si fuera un área normal de la compañía para efectos de visualización para incluirla en un área de gestión de servicios de desarrollo de software tradicional. Existe la consciencia que no lo es.
  2. 2. No se tendrá en cuenta, lo que significa la cultura de trabajo de esta metodología, y no se plasmará. El objetivo es hacer un acercamiento a una arquitectura si se quiere, de solución donde muestro algunos elementos de la capa de negocio y la capa de tecnología.
  3. 3. Habrán otros elementos que seguramente harán falta. La idea es que retroalimenten si así lo consideran; no tanto en el artículo pero si en sus lugares de trabajo si es posible.
  4. 4. El deseo es compartir el conocimiento y la experiencia como arquitecto de negocio a personas que no saben o no conocen DEVOPS; También quiero aprender de todos sus aportes.
  5. 5. Se partirá de la premisa que la compañía ya cuenta con un nivel de madurez aceptable en gestión de servicios de T.I. en su área de desarrollo de software tradicional.

Como toda gran transformación empresarial, apoyada en tecnología de información, requiere de una serie pasos los cuales a continuación serán descritos brevemente.

DEVOPS PARA GESTIÓN DE SERVICIOS T.I.

  1. 1. Capturar necesidades, preocupaciones, motivadores de la compañía de los interesados: Cualquier transformación empresarial debe tener en cuenta esta fase. Qué motiva el cambio? Qué riesgos generales existen de hacerlo? De no hacerlo? Entre otros.
  2. 2. Implementar prueba de Concepto. En esta fase, ya más cercana a la metodología, pretende mostrar con algunos elementos básicos empresariales de organización procesos, tecnología, talento humano entre otros, está preparada para el cambio organizacional. En este caso la transformación del área de Gestión de servicios de tecnología de información tradicional, hacia un área ya con la mejora de incluir DEVOPS como evolución en el servicio.
  3. 3. Configurar un área de tecnología de Información “piloto” como proyecto para la compañía. Esto permitirá ya incluir ya elementos de una nueva cultura para el departamento de T.I.
  4. 4. Iniciar o poner en marcha la prueba de Concepto. Aquí lo que se pretender es recoger las lecciones aprendidas de la prueba de concepto y el proyecto “piloto” del área de tecnología de información.
  5. 5. Despliegue del modelo. Es el conjunto de cómo trabaja el área con todos sus valores, procesos, funciones, aplicaciones, interacciones con otras áreas de la compañía y mejora continua.

MODELO ENTREGA DE SERVICIO DEVOPS

El esquema a continuación sólo para efectos de visualización podría ser el resultado de ejecutar los pasos anteriores y seria el resultado del despliegue:

Es un esquema simple, donde está aislado DEVOPS del resto de la compañía. Aquí muestro los actores a nivel estratégico que hacen el funcionamiento del área; tácticamente están los procesos macro propios de la metodología y los actores del área que hacen posible que la metodología funciones. Tales actores como los desarrolladores, managers, y los operadores de la aplicación creada.

Ahora bien, ¿Qué se necesita a nivel de Infraestructura para que el área de DEVOPS funcione adecuadamente? A continuación lo vemos:

Solo he extendido el modelo de entrega de servicio de DEVOPS usando interfaces de negocio y tecnológicos para que sea ejecutado correctamente.

El SaaS Stack, es el producto ya software ya desarrollado, entregado, soportado y monitoreado por una mesa de servicio. En Lenguaje de Arquitectura empresarial de TOGAF, este podría ser el SBB (Solution Building Block). Sus Bloques de Arquitectura (ABB’s, Architecture Building blocks), son los servicios que tiene la aplicación específica dependiendo para que fue creada. Por ejemplo si fuera un ERP (Enterprise Resource Planning), los servicios que presta la aplicación podrían ser financiero, administrativo, compras, productos; Estos son los ABB’s.

Noten que todos los actores a nivel estratégico a través de una mesa de servicio podrían acceder al soporte. También por su puesto para el uso que fue creado la aplicación específica.

En un nuevo esquema quiero mostrar los componentes de arquitectura tecnológica (algunos) que podrían ser bien relevantes para el área de DEVOPS.

Ahora, la IaaS –Infrastructure as a Service, refiero la pila de servicios que se pueden desplegar en un datacenter. Entonces tenemos servicios de Virtualización, de administración y localización de recursos, almacenamiento, redes de comunicaciones entre otros, blades, racks entre otros. En lenguaje de Arquitectura como TOGAF, el SBB, seria todo el conjunto de infraestructura. Los ABB’s vendrían siendo los componentes que son requeridos para que la solución en este caso de datacenter funcione. En el ejemplo los ABB’s serían el pool de recursos, la virtualización y los recursos físicos. Los BB (Building Blocks) Son componentes más básicos en una arquitectura. Por ejemplo en el caso de Datacenter, los Bloques de arquitectura física del esquema anterior, serán las comunicaciones, racks, blades y seguramente muchos otros más.

Finalmente para lo último, pretendo mostrar el Paas Stack, Platform as a Service Stack. Quise dejarla para lo último porque tiene unos bloques de arquitectura que se hace necesario una explicación adicional y que sin esto sería tecnológicamente y funcionalmente difícil de llevar a cabo la entrega y el nuevo departamento o área de “Information Technology as a Service” Basado en DEVOPS. A continuación el siguiente esquema:

Voy a explicar este gran SBB (Solution Building Block) de la misma forma en Architecture Building Blocks y Building blocks en la medida de los posible.

  • 1. Control Desk Services (ABB): Contiene todo la información y los elementos de configuración del software creado como activos de entrega de servicio de software. CMDB y Software App Assets son algunos de los Building Blocks de este servicio.
  • 2. R -T – M – D Services (ABB): Contiene el software de plataforma que permitirá el control mediante monitoreo, transacciones, recursos, diagnostico ante eventos de la aplicación. Cada uno de estos son los Building Blocks de este bloque de arquitectura
  • 3. Software Applications Knowledge Services (ABB): Fundamental para cualquier desarrollo de software los Bloques que la component son la plataforma de base de datos de bugs y la base de conocimiento para la resolución de problemas e incidencias de la aplicación creada.
  • 4. Workload Automation Services (ABB): Sera el software de plataforma que permitirá la orquestación de servicios de las aplicaciones y los motores de procesos propios, reglas de negocio, modelos canónicos entre otros; el BPMS sería en gran Building block en este caso.
  • 5. Analytics Services (ABB): este software de plataforma que es indispensable en el mundo de hoy, es el que le permitirá al área, no solo llevar las métricas de la aplicación en tiempo real con los dashboards sino plataforma de software que correlacione, que automatice las tareas propias de la analítica. Entonces los building block podrían ser: Analytics Software, Dashboard’s Software, Automation Software, Correlations Software.

Es importante que nuevamente aclarar que la infraestructura como servicio y la plataforma como servicio es para todo el software como servicio creado específico para las necesidades del cliente y del negocio, cumpliendo las metas señaladas en un plan estratégico.

Para terminar este modelo de arquitectura fue pensado más para empresas que desarrollen software en modo outsourcing directo o en modo BPO específico como aliado tecnológico de una compañía que su fortaleza no sea T.I.

¿Qué les parece este modelo de arquitectura tecnológica ITaaS?

Si desea saber cómo ejecutar la estrategia de empresa a través de la herramienta de arquitectura empresarial implementar contácteme aquí.