En la arquitectura

En los entornos locales, los clientes suelen tener un equipo central para la arquitectura de la tecnología que actúa como una superposición con otros equipos de productos o características para asegurarse de que cumplen con las prácticas recomendadas. Los equipos de arquitectura tecnológica suelen estar compuestos por personas como el arquitecto técnico (infraestructura), el arquitecto de soluciones (software), el arquitecto de datos, el arquitecto de redes y el arquitecto de seguridad. A menudo estos equipos utilizan TOGAF o el Marco de Trabajo Zachman como parte de una capacidad arquitectónica de la empresa.

En AWS preferimos distribuir las capacidades en equipos y no tener un equipo centralizado en esa capacidad. Hay riesgos cuando se elige distribuir la autoridad de la toma de decisiones, p. ej., asegurar que los equipos cumplan con las normas internas. Mitigamos estos riesgos de dos maneras. En primer lugar, tenemos prácticas« [ Maneras de aplicar actividades, procesos, estándares y normas aceptadas. ] »  que se enfocan en que cada equipo tenga esa capacidad y recurrimos a expertos que aseguran que estos equipos aumentan el nivel de los estándares con los que necesitan cumplir. En segundo lugar, implementamos mecanismos«Las buenas intenciones nunca funcionan, se necesitan buenos mecanismos para hacer que algo suceda Jeff Bezos. Ello implica sustituir los mejores esfuerzos de los seres humanos por mecanismos (a menudo automatizados) que comprueben el cumplimiento de las normas o los procesos. ] »  que realizan comprobaciones automatizadas para garantizar que se cumpla con los estándares. Este enfoque distribuido tiene el respaldo de los principios de liderazgo de Amazon y establece una cultura en todas las funciones que trabaja hacia atrás« [ Trabajar hacia atrás es una parte fundamental de nuestro proceso de innovación. Comenzamos con el cliente y lo que quiere y dejamos que eso defina y guíe nuestros esfuerzos. ] »  del cliente. Los equipos obsesionados con el cliente construyen productos en respuesta a una necesidad del cliente.

En el caso de la arquitectura, eso significa que esperamos que todos los equipos tengan la capacidad de crear arquitecturas y cumplir con las prácticas recomendadas. Para ayudar a los nuevos equipos a obtener estas capacidades o a los equipos actuales a aumentar el nivel, permitimos el acceso a una comunidad virtual de ingenieros principales que pueden revisar sus diseños y ayudarle a entender cuáles son las prácticas recomendadas de AWS. La comunidad de ingeniería principal trabaja para que las prácticas recomendadas sean visibles y accesibles. Una forma de hacerlo, p. ej., es a través de charlas a la hora del almuerzo que se centran en la aplicación de las prácticas recomendadas a ejemplos reales. Estas charlas se graban y se pueden utilizar como parte de los materiales de incorporación para los nuevos miembros del equipo.

Las prácticas recomendadas de AWS surgen de nuestra experiencia en el manejo de miles de sistemas a escala de Internet. Preferimos utilizar datos para definir las prácticas recomendadas, pero también solicitamos ayuda a expertos en el tema como ingenieros principales para establecerlas. A medida que los ingenieros principales contemplan el surgimiento de nuevas prácticas recomendadas, trabajan como una comunidad para asegurarse de que los equipos las cumplan. Con el tiempo, estas prácticas recomendadas se formalizan en nuestros procesos de revisión internos, así como en mecanismos que garantizan el cumplimiento. Well-Architected es la implementación orientada al cliente de nuestro proceso de revisión interna, donde hemos codificado nuestro principal pensamiento de ingeniería a través de funciones de campo como la arquitectura de soluciones y los equipos internos de ingeniería. Well-Architected es un mecanismo escalable que le permite aprovechar estos aprendizajes.

Si sigue el enfoque de una comunidad de ingeniería principal con propiedad distribuida de la arquitectura, creemos que puede surgir una empresa Well-Architected que esté impulsada por la necesidad del cliente. Los líderes tecnológicos (como CTO o gerentes de desarrollo) que llevan a cabo las revisiones de Well-Architected en todas sus cargas de trabajo le ayudarán a que comprenda mejor los riesgos en su cartera tecnológica. Utilice este enfoque para poder identificar ejes en los equipos que su organización podría abordar mediante mecanismos, capacitaciones o charlas a la hora del almuerzo, donde sus ingenieros principales puedan compartir su opinión sobre áreas específicas con varios equipos.