Realización de inventario de las cargas de trabajo y la arquitectura actuales

Se recomienda crear una matriz de atributos de forma orgánica. Empieza a pequeña escala y realice iteraciones. Si es posible, limite inicialmente el ámbito de aplicaciones que se están considerando.

Este es el proceso global que se debe seguir:

1. Cree una matriz de aplicaciones en función de los atributos principales de esas aplicaciones. Si las aplicaciones forman parte del mismo conjunto de arquitecturas, puede evaluarlas como un grupo. A continuación, identifique una lista finita de valores para cada atributo.

2. Itere la matriz de aplicaciones, atributos y valores de atributos.

   A medida que realiza iteraciones, puede identificar nuevos atributos, combinar atributos o modificar los valores de un atributo. También puede ajustar la lista de aplicaciones o la forma en que las agrupa. Por ejemplo, podría definir inicialmente un atributo de latencia que tuviera un valor de alta latencia, latencia media o baja latencia. Después de una evaluación adicional, decide que los requisitos de latencia se definen mejor como en la misma ubicación frente a con tolerancia remota.

   Su matriz debe ser lo suficientemente descriptiva como para proporcionarle un soporte significativo para tomar decisiones arquitectónicas y de migración, pero también lo suficientemente pequeña como para encajar en su espacio de decisión cognitiva. Si el ámbito de su evaluación es la cartera de TI completa de su organización, considere la posibilidad de crear una matriz consolidada de nivel superior.

3. Defina el ámbito inicial de las aplicaciones que se van a evaluar.

   Finalmente, tendrá que evaluar todas las cargas de trabajo que planea migrar. Sin embargo, para las primeras iteraciones, debe priorizar un subjuego de cargas de trabajo que evaluar. Lo ideal es que los objetivos empresariales identifiquen aplicaciones específicas u objetivos precisos que puedan ayudarle a decidir qué aplicaciones priorizar.

4. Examine el juego completo de aplicaciones.

   Vuelva a evaluar los atributos existentes en el contexto del juego completo de aplicaciones que planea migrar. Si identifica información importante que requiera alguna consideración adicional, agréguela a la matriz. Por ejemplo, podría encontrar una dependencia de datos debido a la latencia o a los detalles de integración que no formaban parte del ámbito inicial. Como ejemplo adicional, podría identificar una tecnología heredada clave que necesitara un esfuerzo dedicado para la planificación de la retirada o la migración y que, por tanto, necesitara una evaluación más profunda.

Utilice los atributos de esta sección como punto de partida para evaluar las cargas de trabajo y la arquitectura de plataforma existentes.

En función de los objetivos de negocio y las aplicaciones que planea migrar, algunos atributos pueden ser más relevantes que otros. Le recomendamos que adapte la terminología a los términos preferidos dentro de su propia organización. Muchos de sus restricciones y objetivos de negocio existentes se reflejarán en estos atributos.

Evalúe la función estratégica:

• Por ejemplo, aplique una versión del modelo de contexto/núcleo de Geoffrey Moore a su cartera de TI. Etiquete las capacidades como esenciales y no esenciales. Aplique una segunda etiqueta para identificar las capacidades como diferenciadoras u operativas.

  • Si los objetivos de negocio hacen hincapié en la innovación, la arquitectura inicial debe centrarse en aplicaciones diferenciadoras que aún no son esenciales.

  • Si los objetivos de negocio hacen hincapié en la eficiencia operativa, la arquitectura debe centrarse en aplicaciones operativas esenciales.

Comprenda la hoja de ruta para aplicaciones de terceros:

• ¿Comprende la hoja de ruta del proveedor de cada tecnología de terceros en su pila actual, incluidas las redes, los recursos informáticos y el almacenamiento?

• ¿La vida de la aplicación de terceros ha llegado a su fin?

• ¿Puede una aplicación de terceros continuar con un cambio de versión?

• Sin profundizar en futuras arquitecturas, ¿ofrece Oracle Cloud Infrastructure una versión en la nube? ¿Ofrece el proveedor de terceros una versión en la nube en Oracle Cloud Marketplace?

Identifique las funciones únicas relacionadas con la tecnología, el despliegue y las operaciones en dimensiones no funcionales clave:

• Seguridad. Por ejemplo, ¿hay funciones de enmascaramiento de datos incorporadas?

• Conformidad. Por ejemplo, ¿hay soporte incorporado para los requisitos de la industria de tarjetas de pago (PCI)?

• Resiliencia. Por ejemplo:

  • ¿Se puede agrupar el nivel de aplicación?

  • ¿El almacenamiento es redundante de forma automática?

  • ¿Depende de la migración en directo para la continuidad del negocio?

• Gobernanza y operaciones. Por ejemplo, ¿hay una integración directa con herramientas externas de ciclo de vida de desarrollo de software (SDLC) o enlaces de supervisión?

• Eficacia. Por ejemplo:

  • ¿Hay plataformas de virtualización como VMware en su pila?

  • ¿Dispone de otro uso compartido de recursos informáticos, almacenamiento o base de datos? Si tiene servidores de base de datos compartidos que ejecutan varias aplicaciones, un valor de atributo sería un despliegue de base de datos compartida.

• Automatización. Por ejemplo:

  • ¿Cuál es el nivel de automatización del modelo de creación, despliegue y funcionamiento?

  • ¿Qué herramientas se utilizan?

Identifique las áreas funcionales compartidas, los datos compartidos y otros componentes comunes, y comprenda cómo soportan las aplicaciones la integración:

• ¿Soporta una aplicación varias líneas de negocio, roles de usuario o procesos de negocio?

• ¿Cuáles son los orígenes de datos compartidos? ¿Se comparte alguna infraestructura? Por ejemplo:

  • ¿Se ejecutan sus aplicaciones en un host compartido por motivos que no sean la eficiencia operativa o el empaquetado de bins?

  • ¿Cómo se comparten los componentes de red? Por ejemplo, si los segmentos de red influyen en la continuidad del negocio entre sitios, los detalles de red pueden ser un atributo relevante.

  • ¿Qué sistema utiliza para la gestión de identidad? Si su organización utiliza varios orígenes o sistemas de gestión de identidad, el sistema de identidad podría ser un atributo relevante.

• ¿Cómo se integran las funciones, los datos y los componentes compartidos entre sí? Por ejemplo:

  • Integración síncrona frente a integración asíncrona.

  • Volumen alto frente a volumen bajo.

  • ¿Cuál es el método de integración? Por ejemplo, enlaces entrantes y enlaces salientes, componentes de middleware.

Evalúe otras características de diseño o arquitectura no funcionales. Tenga en cuenta las áreas en las que las opciones de despliegue y arquitectura entregan los componentes en lugar de las funciones técnicas o de plataforma.

• Volumen y simultaneidad de cambio de datos. Por ejemplo:

  • Los datos nuevos de red frente a las actualizaciones de datos existentes pueden ser relevantes si un sistema realiza principalmente una operación o la otra. Por ejemplo, un lago de datos puede tener un gran volumen de datos nuevos que se agregan, mientras que una caché de ubicaciones de GPS actuales puede tener un gran volumen de datos que se actualizan.

  • Simultaneidad de aplicaciones y número de clientes.

  • En función de sus aplicaciones, debe tener en cuenta los datos transaccionales, los datos de referencia y los datos analíticos.

• Escalado. Por ejemplo:

  • ¿Su arquitectura actual se escala y reduce verticalmente en función de un ciclo de demanda recurrente o de picos inesperados en la demanda?

  • ¿Cuál es el mecanismo de escalado?

• Confidencialidad de los datos o problemas de conformidad especiales. Por ejemplo:

  • ¿Incluyen las cargas de trabajo datos sujetos a las normativas de PCI o de la ley de portabilidad y responsabilidad de seguros de salud (HIPAA)?

  • ¿Los datos que se almacenan o procesan están sujetos a requisitos de residencia de datos como el Reglamento General de Protección de Datos (RGPD)?

• Prácticas operativas resilientes. Por ejemplo:

  • ¿Algunas cargas de trabajo realizan un failover a otra ubicación en respuesta a incidentes específicos mientras que otras simplemente entran en un estado "caído"? Algunos niveles de aplicación o base de datos utilizan clusters de failover. Algunas aplicaciones que carecen de failover automatizado pueden tener una automatización de reconstrucción completa. Para otras aplicaciones, el proceso de recuperación puede ser completamente manual.

  • Identifique un número limitado de patrones relativos a los modos de fallo específicos de las aplicaciones.

• Costos operativos. Los niveles de costo pueden ser cifras aproximadas en lugar de exactas. Áreas de ejemplo que se deben tener en cuenta:

  • ¿Es necesario algún dispositivo exclusivo?

  • ¿Cuál es el costo de la mano de obra? La mano de obra se suele asignar, por lo que puede ser difícil capturar números exactos, pero considere estimaciones para una matriz de agregación o de resumen.

  • ¿Incluye su pila de tecnología soporte o licencias de terceros premium? Si es así, ¿son portátiles las licencias de terceros o el soporte?

  • ¿Existen eficiencias compartidas que sea importante destacar? Por ejemplo, considere la tecnología de virtualización, como VMware o las aplicaciones basadas en contenedores que comparten servidores.

Podría identificar atributos adicionales que tener en cuenta. Recomendamos que gestione el ámbito del análisis para que no se sienta abrumado.

A medida que realiza iteraciones, ajuste la matriz de aplicaciones, atributos y valores de atributos actuales en función de sus conocimientos del panorama tecnológico existente, sus objetivos de negocio y sus planes de adopción de la nube, incluida la asignación de la arquitectura actual a la arquitectura planificada.

Defina los atributos de la arquitectura y las cargas de trabajo en la nube planificadas.