El crecimiento cloud necesita límites claros.

Las cuentas, los entornos y los permisos administrativos deben corresponderse con la organización real. Una separación por áreas de negocio no siempre coincide con una separación por aplicaciones o por responsabilidad de operación. Por eso analizamos junto con usted quién solicita los recursos, quién los atiende y a quién deben imputarse los gastos. Los entornos existentes también se tienen en cuenta. La visión objetivo describe a continuación los límites previstos y sus motivos, de manera que los cambios posteriores no se decidan solo a partir de nombres surgidos por azar o de competencias históricas.

El desarrollo, las pruebas y la producción reciben la separación necesaria en cada caso. Además, se define cómo se utilizan los servicios compartidos y qué excepciones pueden permitirse. La implementación no pretende impedir cualquier particularidad, sino permitir gestionarla de forma comprensible. Una vía de excepción regulada indica quién decide y quién es responsable. Así, la arquitectura sigue siendo explicable incluso cuando determinadas aplicaciones tienen requisitos especiales o cuando una carga de trabajo existente solo puede incorporarse a la estructura común de forma gradual.

Una directriz documentada todavía no modifica ningún recurso. Por eso, para las pautas acordadas se comprueba cuáles pueden representarse técnicamente y cuáles siguen necesitando una decisión organizativa. Esto incluye los roles, los accesos de red, el registro y el etiquetado de costes. La configuración debe permitir reconocer qué reglas son vinculantes y dónde se requieren aprobaciones. Al mismo tiempo se describe la vía para los cambios, de modo que una adaptación posterior no tenga que producirse fuera de la base común.

La configuración versionada permite comprobar los cambios y documentar de forma trazable el estado previsto. Dentro del alcance acordado, a partir de ella se construye un proceso de aprovisionamiento repetible. Esta se pone a prueba con un entorno concreto, incluidas las comprobaciones y los accesos necesarios. Su equipo recibe la configuración junto con los procedimientos para su uso. De este modo, una plataforma configurada una sola vez se convierte en una base que sirve de referencia a otros proyectos y cuyo mantenimiento no depende únicamente de las personas que participaron en el proyecto inicial.

Una aplicación real demuestra si la landing zone es viable en la práctica. Su equipo debe recibir los recursos previstos, poder acceder a los sistemas necesarios y realizar su trabajo con los permisos asignados. Esta primera prueba pone de manifiesto la información que falta y los obstáculos innecesarios. Al hacerlo, distinguimos junto con usted entre un requisito necesario y un proceso que conviene simplificar. Las observaciones se reflejan en la configuración y en la documentación antes de incorporar a más equipos.

El traspaso incluye la responsabilidad del mantenimiento de la plataforma, la incorporación de nuevos proyectos y la aprobación de cambios. También se documentan los puntos abiertos junto con sus consecuencias. Una landing zone no constituye una confirmación definitiva de seguridad o cumplimiento normativo para cada aplicación que se opere posteriormente sobre ella. Su configuración y su uso deben seguir considerándose por separado. La base creada respalda estas tareas al proporcionar procedimientos comunes y hacer visible la responsabilidad sobre las ampliaciones y las desviaciones.