Especificación de diseño de arquitectura de carga de trabajo
Una especificación de diseño de arquitectura de carga de trabajo es una especificación detallada que describe las opciones de diseño y va acompañada de diagramas. Las opciones de diseño deben cumplir los requisitos funcionales y no funcionales e incluir disposiciones para las operaciones rutinarias, ad hoc y de emergencia.
Para obtener información sobre los diagramas, vea Diagramas de diseño de arquitectura.
El diseño de la arquitectura de carga de trabajo, normalmente expansivo, comienza con el diseño de aplicaciones y avanza a la selección del servicio en la nube. Estas fases se informan mutuamente entre sí. El diseño combinado de la aplicación y la infraestructura deben cumplir todos los requisitos.
Lograr una solución que cumpla todos los requisitos es un esfuerzo colaborativo entre las partes interesadas, desarrolladores, evaluadores, equipos de operaciones y propietarios de productos. El proceso de diseño debe implicar refinar los requisitos con claridad y negociación. El proceso es iterativo y a menudo requiere varias revisiones.
Se recomienda alinear el diseño con la guía fundamental de Azure Well-Architected Framework, que incluye principios de diseño y guías de recomendaciones, y reconocer los inconvenientes.
En última instancia, el equipo de desarrollo de cargas de trabajo implementa la especificación de diseño de arquitectura de carga de trabajo, por lo que debe ser clara e inequívoca. La especificación debe estar disponible y almacenarse fácilmente con la documentación de la carga de trabajo.
Especificación funcional
La especificación funcional de una carga de trabajo detalla qué y por qué del sistema o la característica en desarrollo, pero no la implementación. Este documento debe explicar los problemas actuales que existen y cómo esta característica o sistema va a mejorar esa experiencia. Este documento captura la mayoría de los requisitos empresariales.
Un arquitecto puede ayudar a dar forma a este documento, pero principalmente es una función de la propiedad del producto. Un arquitecto debe ayudar a diseñar los datos capturados en esta especificación. Esta implicación garantiza que la especificación funcional impulsa un diseño técnico eficaz y eficaz.
Estos son algunos temas de ejemplo que se deben tratar en esta especificación.
Además de detallar lo que está en el ámbito de este diseño, también sea explícito sobre las preocupaciones adyacentes que están fuera del ámbito. Establecer ámbitos claros reduce el desenredado del ámbito definiendo límites en torno a la funcionalidad.
Resulta útil incluir los detalles sobre cómo se va a medir este cambio. Qué medidas deben recopilarse y qué objetivos empresariales admiten esas medidas.
Los flujos de usuario deben describirse claramente. Los simulacros de fedelidad baja también pueden ser útiles. Si las situaciones de control de errores son importantes para estos flujos, asegúrese de que se describe el comportamiento esperado.
Incluya siempre los requisitos específicos para la accesibilidad, el cumplimiento, el rendimiento, la privacidad o la seguridad.
Incluya cualquier estrategia de implementación planeada. Por ejemplo, "Esta característica estará disponible para nuestros usuarios beta durante dos meses antes de decidir una versión completa".
Evite detalles específicos de implementación técnica en esta especificación. Estas especificaciones funcionales impulsarán las especificaciones técnicas creadas por el arquitecto.
Especificación técnica
La especificación técnica describe cómo se basa en el ámbito y los objetivos descritos en la especificación funcional. Esta especificación está diseñada para que el equipo de ingeniería lo use como plan de registro durante la implementación.
En esta especificación se incluyen elementos como:
- Decisiones tecnológicas, entre las que se incluyen: comprar, compilar, reutilizar, ampliar o retirar.
- Contratos de API y datos (esquemas), incluida la estrategia de implementación de compatibilidad con versiones anteriores
- Detalles de implementación de lanzamiento y reversión
- Ciclo de vida de desarrollo seguro único (SDL) e implementación de privacidad
- El plan de prueba
- Supervisión de claves y orígenes de señal de alerta
- Diseños alternativos que se consideraron
La especificación técnica impulsará los esfuerzos de ingeniería. Los elementos de trabajo de ingeniería se crean principalmente a partir del contenido de esta especificación. Los equipos de implementación hacen referencia a los elementos de trabajo, la especificación técnica y la especificación funcional para asegurarse de que el resultado final cumple los requisitos funcionales y no funcionales.
Planes de recuperación ante desastres
Para cumplir los requisitos de confiabilidad de la carga de trabajo, un arquitecto debe diseñar un sistema que pueda recuperarse dentro del objetivo de tiempo de recuperación (RTO) y los objetivos de objetivo de punto de recuperación (RPO). La especificación de diseño de arquitectura debe incluir el plan de recuperación. Este plan debe cubrir los componentes de arquitectura implicados, los mecanismos de conmutación por error y el impacto en el flujo de datos y el usuario, así como las recomendaciones operativas. Debe describir qué destinos de recuperación cumplen el diseño y cómo.
Aunque se espera que el plan inicial evolucione en función de las conclusiones de los simulacros y las revisiones posteriores a los incidentes, es responsabilidad del arquitecto entregar el plan inicial para todas las arquitecturas nuevas.
Documentación de seguridad y cumplimiento
Un arquitecto es responsable de diseñar una solución que cumpla las restricciones de seguridad y cumplimiento pertinentes. Es importante que los artefactos de diseño resalten las prestaciones incorporadas en el diseño para admitir estos requisitos y para identificar los controles de compensación necesarios cuando no se puedan cumplir directamente los requisitos.
Coherencia
Use una plantilla para documentar las distintas especificaciones de la carga de trabajo. La coherencia ayuda a las partes interesadas, a las partes responsables y a los equipos de implementación cuando se lee la especificación.
Asegúrese de que las especificaciones tienen campos de metadatos clave como:
- Estado: un estado como Borrador, En revisión y Aprobado.
- Vínculo al elemento de trabajo: vínculo al elemento de trabajo principal del trabajo pendiente del equipo.
- Vínculos cruzados clave: vínculos a especificaciones relacionadas u otra documentación que admita la especificación.
- Personas clave: un lugar para enumerar los nombres de los responsables clave de la toma de decisiones implicadas. Esta lista puede incluir roles como: analista de negocios, asociado empresarial, jefe técnico y propietario del producto o cliente potencial que firmó la especificación.