Proceso: Gestión de Plataformas

Objetivo

El objetivo de este proceso es gestionar las solicitudes de plataformas, RFPs. Este tipo de solicitudes está destinado a la creación de las Plataformas tecnológicas necesarias para el despliegue de los diferentes aplicativos incluidos dentro del Catálogo de aplicaciones. 

Alcance RFP

Son solicitudes de servicios de transición para proyectos de ingeniería, trabajos de evolución, mejora y/o implantación de infraestructuras hardware y/o software, que llegarán al adjudicatario en forma de peticiones de plataforma (RFP).

Un petición de plataforma (RFP - Request For Platform) se desencadena para realizar una modificación sustancial de plataforma:

• Desplegar nuevas máquinas físicas o virtuales.
• Crear nuevas bases de datos.
• Reinstalar completamente sistemas operativos.

Cualquier otro cambio ejecutado sobre una plataforma se considerará cambio menor y se gestionará mediante peticiones de lanzamiento (PL).

Prerrequisito

Los mecanismos por los que se determina que es necesario crear una nueva RFP son:

• RFP de negocio: reunión de Kick-off. El procedimiento a seguir en estas reuniones es el siguiente.
• RFP de sistemas: reunión del comité de cambios (Change Advisory Board (CAB) de sistemas).

Las RFPs se gestionan en JIRA y es necesario que el proyecto plataforma esté dado de alta en la herramienta.

Si la plataforma no existe, es necesario como paso previo a crear la RFP en JIRA que se dé de alta en CMS la nueva plataforma. Esta acción la pueden realizar los responsables de Sistemas que tienen perfil STIC SISTEMAS.

Una vez dada de alta en CMS, se creará automáticamente en JIRA.

Procedimiento

Roles

Diagrama de flujo

Creación de la RFP

Como ya hemos comentado, las RFPs se crean en los proyectos de tipo plataforma.

Pueden solicitarse RFPs para plataformas de negocio (donde desplegarán aplicaciones) y para plataformas tecnológicas (de no negocio). Para el primer caso, la RFP podrá ser creada por el Responsabe del producto que va a desplegar en ella y por el proveedor del mismo. En el segundo caso, podrán ser creadas por el Responsable de la plataforma y por el proveedor de sistemas centralizados.

Al crear la RFP hay que indicar si la plataforma es de negocio o no. Si no lo es, indicar si es para una o varias aplicaciones. En caso de que sea para una únca aplicación habrá que indicarlo.

La RFP se crea en en estado ABIERTA. A tener en cuenta:

• Se asignará en al Responsable de producto si es que la plataforma es de negocio y sólo desplegará en ella esa aplicación.
• Se asignará al Responsable de la plataforma en el caso de que se indique que la plataforma no es de negocio.
• Se asignará al Responsable de la plataforma en el caso de ques e indiqe que la plataforma es de negocio pero afecta a varias aplicaciones.
• Se crean enlazadas dos páginas en la página de la plataforma correspondiente en el espacio de PLATAFORMAS
  • Una página se crea para incluir información acerca de la plataforma
  • La segunda página se crea con la plantilla del Documento de Entorno Tecnológico (DGT) donde se especifican todos los requisitos técnicos necesarios para la construcción o modificación de la plataforma.

En este estado, los creadores de la plataforma tienen permiso de edición en el DGT. Es importante que se recojan en él todos los posibles cambios o ajustes que se tengan como consecuencia de la reunión de Kickoff, con lo que la RFP no debería moverse de ese estado hasta que el DGT no fuera definitivo.

Una vez que el DGT es definitivo, accediendo a la acción "Comenzar", pasa al estado PDTE. APROBAR. En este estado se quitan los permisos de edición del PID.

El sentido de ese estado, es que se apruebe o no la ejecución de esa RFP por parte de los coordinadores de Diseño y Transición de SSID.

• Si no se aprueba la ejecución de la plataforma, el registro de la RFP se cierra directamente.
• Si se aprueba la ejecución de la plataforma, el registro de la RFP pasa al estado PDTE. REVISION para que el proveedor de sistemas centralizados (en adelante CTI), revise el DGT y registre su conformidad con esos requisitos para la ejecución de la RFP. Pueden darse tres casos:
  • Que el DGT no se acepte, con lo que la RFP volverá al tejado del proveedor en estado NO ACEPTADA. Se activarán los permisos de edición del DGT para que el proveedor haga los cambios solicitados y accediendo a "Completar información" la RFP volverá de uvo a PDTE. REVISION asignada a CTI.
  • Que CTI tenga dudas sobre algo que se indica en el DGT. En ese caso, la RFP pasará al estado PDTE. INFORMACION asignada al proveedor. Se reanudarán los permisos de edición del DGT para que se modifique lo que generaba dudas. Una vez hecho, accediendo a "Completar información" la RFP volverá de uvo a PDTE. REVISION asignada a CTI.
  • Que se acepte el DGT. Al revisar los requisitos, CTI clasifica la RFP en uno e estos tipos:
    • Petición de plataforma ágil: creación o modificación de plataforma con alcance reducido y cerrado, mediante mecanismos automáticos de despliegue de sus componentes.
    • Petición de plataforma simple: creación o modificación de plataforma con alcance reducido ycerrado, que afecta a una única capa tecnológica de la plataforma, con todas las tareas a realizar incluidas en el catálogo de servicio para peticiones de plataformas.
    • Petición de plataforma normal: creación o cambio de plataforma con un alcance cerrado, que puede afectar a varias capas de la plataforma, con todas las tareas a realizar incluidas en el catálogo de servicio para peticiones de plataformas.
    • Petición de plataforma compleja: creación o cambio de plataforma con un alcance abierto, donde las tareas a realizar no están incluidas en el catálogo de servicio para peticiones de plataformas.

Al aceptar el DGT la RFP pasará a estado EN PROGRESO asignada a quien se asignó en la creación.

A partir de este punto, el flujo cambia dependiendo del Tipo de RFP.

Tipo de RFP ÁGIL, NORMAL Y SIMPLE

En este caso, se crean automáticamente dos subtareas (RFP Hijas) por cada entorno que se haya solicitado y una más para la fase de Transferencia (paso de la plataforma a Operación).

Como lo habitual es solicitar como entornos PRE y PRO, vamos a ver el proceso detallado para ese caso.

Las cinco RFP Hijas que se crean son:

• Diseño y construción PRE: Asignada a CTI y en estado EN PROGRESO para que comiencen con la construcción del entorno de PRE.
• Validación PRE: Asignada a quien debe validar el entorno de PRE:
  • Responsable de producto para plataformas de negocio para una sola aplicación
  • Responsable de plataforma para plataformas de no negocio o de negocio que afecte a varias aplicaciones. En ambos casos, el Responsable de la plataforma podrá asignar la validación al Responsable de producto que estime conveniente.

Esta RFP Hija se crea en estado PROGRAMADA. Pasará al estado PDTE. VALIDAR cuando el proveedor resuelva la fase anterior. Resolver significa que el proveedor acabe su trabajo, no que la subtarea se cierre. Al resolver la fase de Diseño y Construcción PRE pasa al estado PDTE. VALIDAR para que el Responsable de la plataforma revise los incurridos y los valide.

• Diseño y construcción PRO: Asignada al Responsable de la plataforma en estado PROGRAMADA. Pasará al estado PDTE. COMENZAR RESOLUCION y se asignará a CTI cuando se cierre la hija RFP Hija de validación de PRE.

¿Por qué entonces está inicialmente asignada al Responsable de la plataforma? Porque tiene la opción de pasarla a PDTE. COMENZAR RESOLUCION antes de que se cierre la validación del entorno de PRE.

De ese estado pasará a EN PROGRESO y una vez que la resuleva el proveedor, se activará la correspondiente RFP Hija de Validación PRO, pasando la de Diseño y Construcción a PDTE. VALIDAR asignada al Responsable de la plataforma para que valide los costes.

• Validación PRO: Asignada a quien debe validar el entorno de PRE:
  • Responsable de producto para plataformas de negocio para una sola aplicación
  • Responsable de plataforma para plataformas de no negocio o de negocio que afecte a varias aplicaciones. En ambos casos, el Responsable de la plataforma podrá asignar la validación al Responsable de producto que estime conveniente.

Esta RFP Hija se crea en estado PROGRAMADA. Pasará al estado PDTE. VALIDAR cuando el proveedor resuelva la fase anterior.

• Transferencia: Esta RFP Hija se crea en estado PROGRAMADA y asignada a CTI. Pasa a EN PROGRESO cuando se cierra la RFP Hija de Validación de PRO. Cuando se resuelve por parte del proveedor (la plataforma pasa a Operación), pasa a estado PDTE. VALIDAR asignada al Responsable de la plataforma para que revise los costes.

Cambios de alcance

Los cambios de alcance recogen una realidad que se da en la construcció de plataformas debido a cambios de requisistos técnicos y/o funcionales.

Su impacto depende del momento del ciclo de vida en el que se solicitan.

Los cambios de alcance siempre se solicitan sobre la RFP padre y hay que clasificar el motivo por el que se hacen

• Funcional. SW Base
• Funcional. Comunicaciones
• Funcional. Recursos. Nuevos esquemas BBDD
• Funcional. Recursos. Nuevos servicios en contenedores
• Funcional. Recursos. Necesidad de kafka centralizado (creación de topics)
• Seguridad. SW Base
• Seguridad. Comunicaciones
• Sistemas. SW Base

Siempre que haya un cambio de alcance, se incrementará un contador que los refleje.

Rechazos en las RFPs Hijas

Validación de las RFPs de sistemas

Existe la posibilidad de que el Diseño y Construcción en las RFpsde plataformas que no son de negocio, deba validarlas negocio, con lo que el Responsable de la plataforma que será inicialmente el asignado de esos hitos, podrá asignársela al Responsable de producto que considere.

Tipo de RFP COMPLEJA

En este caso, se crea una RFP Hija de Diseño y otra de Construcción por cada uno de los entornos, además de la de Transferencia.

Para esta tipolo gía no se contemplan los cambios de alcance.

Todas las hijas se crean en estado PDTE. ESTIMAR asignadas a CTI. Siempre deben estimarse de manera secuencial, de manera que una no podrá estimarse hasta que no se haya cerrado la anterior.

Una vez que CTI hace la estimación, la RFP Hija pasa a estado ESTMADA para que el Responsable de la plataforma apruebe o no la misma. en el caso de que la apruebe, la RFP Hija pasa a estado PDTE. COMENZAR RESOLUCION para de ahí pasar a EN PROGRESO y una vez que el proveedor resuelva:

• Si la RFP Hija es de Diseño o de Transferencia, pasa a estado PDTE. REVISION y el comportamiento es el mismo que las RFPs Hijas de Diseño y Construcción para las RFPs que no son complejas. Esta revisión la hace el Responsable de la plataforma.
  • Si la acepta, la RFP Hija se cierra.
  • Si no la acepta, pasará a estado NO ACEPTADA aignada de nuevo a CTI. El Responsable de la plataforma detrminará si el rechazo es imputable o no a CTI

• Si la RFP Hija es de Construcción. pasa a estado PDTE. REVISION TECNICA. Esta revisión la hace el informador de la plataforma.
  • Si la acepta, la RFP Hija se cierra.
  • Si no la acepta, pasará a estado NO ACEPTADA aignada de nuevo a CTI. El Responsable de la plataforma detrminará si el rechazo es imputable o no a CTI

Finalización de la RFP padre

Una vez se han completado todas las RFP Hijas, con una acción automática, la RFP finaliza (estado Cerrada, resolución Resuelta).

Cancelación de una RFP

La RFP puede ser Cancelada por el Responsable de la plataforma en cualquier momento.

Si la RFP está en estados previos a EN PROGRESO, es decir, aún no se han creado las RFP Hijas, se podrá cancelar sin ninguna acción adicional.

Si la RFP está  EN PROGRESO, habrá que ir cancelando cada una de las RFP Hijas, pasando estas por los estados:

PDTE. CANCELACION

El proveedor sistemas debe registrar las HBS y Liquidar.

PDTE. REVISIÓN CANCELACIÓN

El Responsable de la plataforma deberá aceptar la liquidación y si no está conforme vuelve a PDTE. CANCELACIÓN para que el proveedor sistemas corrija los incurridos.

Al cancelarse todas, la RFP también se cancelará.

Paralización de una RFP

En el caso de las RFPs agiles, simples y normales Los Coordinadores de Diseño y Transición de SSID pueden decidir paralizar una RFP, lo que implica que se paralicen todas sus hijas. En el caso de reanudación, se volverán a reanudar las hijas que estban paralizadas.

En el caso de las RFPs complejas, los Coordinadores de Diseño y Transición de SSID podrán paralizar una RFP hija y eso hará que se paralice directam