Sobre la arquitectura

En entornos locales, los clientes suelen contar con un equipo central dedicado a la arquitectura tecnológica que está por encima de otros equipos de productos o características para verificar que sigan las prácticas recomendadas. En los equipos de arquitectura tecnológica suelen haber distintos roles como el de arquitecto técnico (infraestructura), arquitecto de soluciones (software), arquitecto de datos, arquitecto de redes y arquitecto de seguridad. A menudo, estos equipos usan TOGAF o el Zachman Framework como parte de una capacidad de arquitectura empresarial.

En AWS, preferimos distribuir capacidades dentro de los equipos en lugar de tener un equipo centralizado con esa capacidad. Existen riesgos cuando se elige distribuir la autoridad de la toma de decisiones, por ejemplo, al verificar que los equipos cumplan con los estándares internos. Mitigamos estos riesgos de dos maneras. En primer lugar, tenemos prácticas (formas de hacer las cosas, procesos, estándares y normas aceptadas) que se centran en permitir que cada equipo tenga esa capacidad, además de que contamos con expertos que verifican que los equipos eleven el nivel de los estándares que deben cumplir. En segundo lugar, implementamos mecanismos que realizan comprobaciones automáticas para verificar que se cumplan los estándares.

Esto significa reemplazar los esfuerzos humanos por mecanismos (a menudo automáticos) que controlan el cumplimiento de las normas y los procesos. Este enfoque distribuido está respaldado por los principios de liderazgo de Amazony establece una cultura en todos los roles que funciona a partir de las necesidades del cliente. Pensar en el cliente es esencial en nuestro proceso de innovación. Comenzamos con el cliente y lo que quiere, y dejamos que eso defina y guíe nuestros esfuerzos. Los equipos centrados en el cliente crean productos como respuesta a una necesidad del cliente.

Para la arquitectura, esto significa que esperamos que cada equipo tenga la capacidad de crear arquitecturas y seguir las prácticas recomendadas. Para ayudar a los nuevos equipos a obtener estas capacidades o a los equipos existentes a subir el listón, activamos el acceso a una comunidad virtual de ingenieros principales que pueden revisar sus diseños y ayudarlos a comprender cuáles son las prácticas recomendadas de AWS. La comunidad de ingenieros trabaja para que las prácticas recomendadas sean visibles y accesibles. Una forma de hacerlo es, por ejemplo, a través de charlas a la hora del almuerzo centradas en la aplicación de las prácticas recomendadas a casos reales. Estas charlas se graban y pueden utilizarse como parte de los materiales de incorporación para los nuevos miembros del equipo.

Las prácticas recomendadas de AWS surgen de nuestra experiencia con miles de sistemas a escala de Internet. Preferimos usar datos para definir las prácticas recomendadas, pero también usamos expertos en la materia, como ingenieros principales, para establecerlas. A medida que los ingenieros principales ven emerger nuevas prácticas recomendadas, trabajan como una comunidad para verificar que los equipos las sigan. Con el tiempo, estas prácticas recomendadas se formalizan en nuestros procesos de revisión interna, y también en mecanismos que garantizan su cumplimiento. El Well-Architected Framework representa la implementación orientada al cliente de nuestro proceso de revisión interna, donde hemos codificado la forma de pensar de nuestros ingenieros principales en roles de campo, como los de la arquitectura de soluciones y de los equipos de ingeniería internos. El Well-Architected Framework es un mecanismo escalable que le permite aprovechar estos aprendizajes.

Al seguir el enfoque de una comunidad de ingeniería con propiedad distribuida de la arquitectura, creemos que puede surgir una arquitectura empresarial Well-Architected impulsada por las necesidades del cliente. Los líderes tecnológicos (como los CTO o los administradores de desarrollo) que realicen revisiones Well-Architected en todas sus cargas de trabajo podrán comprender mejor los riesgos de su cartera de tecnología. Con este enfoque, puede identificar temas en todos los equipos que su organización podría abordar mediante mecanismos, formaciones o charlas a la hora del almuerzo donde los ingenieros principales pueden compartir sus ideas sobre áreas específicas con múltiples equipos.