Para que una organización tecnológica pueda ofrecer productos en apoyo de la misión de una empresa, las decisiones sobre qué tecnología utilizar y cómo utilizarla deben tomarse con regularidad. La creación de una estrategia para tomar estas decisiones es un problema para muchas organizaciones.
En el caso de las organizaciones pequeñas, las decisiones suelen adoptarse buscando el consenso mediante debates en grupo. A medida que las organizaciones crecen, es necesario adoptar nuevas estrategias. Una estrategia común, aunque defectuosa, es que los primeros miembros conserven la autoridad para tomar decisiones en toda la organización. Esta estrategia crea un cuello de botella en la toma de decisiones para la compañía que lleva a una variedad de comportamientos indeseables.
El equipo de ingeniería está compuesto por profesionales cualificados y experimentados. Valoramos la intencionalidad y la claridad en nuestra comunicación y toma de decisiones. Como organización, abrazamos el principio de subsidiariedad.
Subsidiariedad
Los asuntos deben ser manejados por la autoridad competente más pequeña, más baja o menos centralizada.
Esto significa que el equipo de liderazgo tecnológico proporciona una visión y dirección central, y esperamos que nuestros colegas se comporten como profesionales competentes que son capaces de tomar buenas decisiones técnicas para la organización a medida que ejecutan la visión.
Una de las técnicas que utilizamos para compartir nuestra visión es un Radar Tecnológico que categoriza las decisiones tecnológicas y proporciona orientación para tomar decisiones que tienen un impacto sistémico. Evolucionamos nuestro radar tecnológico con el tiempo usando el marco de toma de decisiones RAPID.
Sin embargo, el Radar Tecnológico no es integral. Por esta razón, hemos explorado otras formas de honrar nuestros principios mientras proporcionamos la claridad sobre la toma de decisiones necesaria para que los equipos se ejecuten de manera efectiva. Lo que encontramos es el marco de los 7 niveles de delegación en el libro Managing for Happiness de Jurgen Appelo.
Este marco desglosa las decisiones en 7 categorías basadas en cuán centrales o distribuidas son las decisiones. A medida que lo aplicamos a nuestras decisiones tecnológicas, los niveles se ven así:
Con el fin de entrenar nuestra heurística interna sobre qué decisiones deben tomarse en cada nivel, hicimos un ejercicio con cada uno de nuestros equipos de desarrollo en el que categorizamos muchos tipos de decisiones tecnológicas que toman. Hemos compilado una lista incompleta, pero representativa, de éstas y las presentamos aquí para que todos puedan entender quién tiene la autoridad para tomar decisiones, cómo deben tomarse esas decisiones y quién es el responsable final del resultado de las mismas.
Decisiones del equipo de arquitectura
Tell
El equipo de arquitectura toma una decisión para los equipos de desarrollo de productos y puede explicar la motivación. Abrir una discusión sobre la decisión no es ni deseado ni asumido.
- Decidiendo que todo el código de producción debe ser revisado por 2 o más personas.
Vender
El equipo de arquitectura toma una decisión para la organización y luego trata de convencer a los miembros de los equipos de desarrollo de productos de que es la elección correcta y les ayudará a sentirse involucrados.
- Seleccionando y definiendo la arquitectura del sistema de productos.
- Definiendo un menú de patrones de mensajes para su uso entre Contextos Limitados.
- Seleccionar una plataforma de mensajería o un agente de mensajes para la comunicación entre Contextos Limitados.
Consultar
El equipo de arquitectura pedirá primero una aportación, que será considerada antes de tomar una decisión que respete las opiniones de los equipos de producto.
- Actualizando el menú de los lenguajes de programación aprobados para el código de producción.
- Actualizando el menú de los almacenes de datos.
- Seleccionando el orden en que se aborda la deuda técnica a nivel de sistema.
- Añadiendo al menú un servicio no utilizado anteriormente proporcionado por AWS.
De acuerdo
El equipo de arquitectura entrará en una discusión con el equipo o equipos de desarrollo del producto y tomará una decisión como grupo.
- Seleccionando una biblioteca compartida pagada.
- Seleccionando un servicio gratuito de terceros.
- Seleccionando un servicio de terceros pagado.
- Decidir cuándo y cómo dividir un contexto limitado.
- Decidir cuándo y cómo combinar los contextos límites.
- Decidiendo publicar una nueva API de cara al cliente.
- Integrar los contextos delimitados en la capa de la base de datos.
Aconsejar
El equipo de desarrollo del producto solicitará el asesoramiento del equipo de arquitectura antes de tomar una decisión.
- Seleccionando un patrón de mensajes del menú existente para una integración específica entre Contextos Limitados.
- Definiendo el límite entre los contextos delimitados.
- Decidir cuándo y cómo dividir un equipo.
- Decidir cuándo y cómo combinar los equipos.
- Decidiendo publicar un nuevo mensaje.
- Decidiendo publicar un nuevo API de cara al sistema.
Preguntar
El equipo de desarrollo del producto tomará una decisión e informará al equipo de arquitectura de lo que se ha decidido y se le podrá pedir que comparta el proceso y la información que conduzcan a esta elección.
- Definiendo la arquitectura para un único contexto limitado.
- Seleccionando un método de integración de componentes dentro de un contexto limitado.
- Especificar la forma o el contenido del cuerpo del mensaje.
- Seleccionando un lenguaje de programación para el código de producción en el menú.
- Seleccionando un almacén de datos en el menú.
- Decidiendo crear y publicar una biblioteca compartida.
- Decidiendo suscribirse a un nuevo mensaje.
- Decidiendo consumir un nuevo API de cara al sistema.
- Seleccionando una pista tecnológica.
- Integrar contextos delimitados en la capa de UI (por ejemplo, con componentes web).
Delegado
El equipo de desarrollo del producto tomará la decisión y no se requiere ninguna notificación, presentación o documentación por parte del equipo de arquitectura.
- Definiendo la arquitectura para una sola aplicación.
- Definiendo la arquitectura para un solo sitio web o API web.
- Definiendo la arquitectura para un solo servicio o demonio.
- Seleccionando una biblioteca de mensajes para integrarla con el bus/broker de mensajes.
- Seleccionando una característica para construir.
- Seleccionando una biblioteca compartida de código abierto (de nuget/npm/etc).
- Seleccionando un editor de código o IDE.
- Decidir qué práctica utilizar para revisar el código de producción.
- Iniciar o detener una práctica de desarrollo.
- Introduciendo una biblioteca de JavaScript del lado del cliente.
- Seleccionando y haciendo cumplir un formato de código fuente o una convención de nombres.
- Abordar la deuda técnica dentro de un contexto limitado.
- Seleccionando una herramienta o marco de pruebas.
- Diseñando un modelo de dominio para un contexto limitado.
- Diseñar un modelo de dominio para una aplicación.
- Diseñando un esquema de base de datos.
- Decidiendo publicar una nueva API para el contexto limitado.
Decisiones del equipo de operaciones
Tell
El equipo de operaciones toma una decisión para los equipos de desarrollo de productos y puede explicar la motivación. Abrir una discusión sobre la decisión no es ni deseado ni asumido.
- Seleccionar un proveedor de alojamiento para los sistemas de producción.
- Localización en red/VPC de los sistemas de producción (almacenes de datos, servicios, hosts de ejecución y otros).
- Se requiere el uso de MFA en sistemas particulares.
- Conjunto de etiquetas requeridas para utilizar en los objetos de la nube.
- Seleccionando un proveedor de servicios de guardia/alerta pagado.
Vender
El equipo de operaciones toma una decisión para la organización y luego trata de convencer a los miembros de los equipos de desarrollo de productos de que es la elección correcta y les ayudará a sentirse involucrados.
- Selección de elementos obligatorios para la lista de verificación de la aplicación de la producción.
- Seleccionando un proveedor de alojamiento de control de versiones.
- Seleccionando una herramienta de configuración de estado deseada para aprovisionar y administrar servidores.
- Seleccionando un formato de registro del sistema, contenidos y servicio de agregación.
- Actualización del menú de sistemas operativos aprobados para aplicaciones de producción.
Consultar
El equipo de operaciones pedirá primero una aportación, que será considerada antes de tomar una decisión que respete las opiniones de los equipos de producto.
- Seleccionando un servicio de integración/construcción continuo.
- Actualizando el menú de herramientas de despliegue.
- Actualizando el menú de los almacenes de datos.
- Añadiendo al menú un servicio no utilizado anteriormente proporcionado por AWS.
De acuerdo
El equipo de operaciones entrará en una discusión con el equipo o equipos de desarrollo del producto y tomará una decisión como grupo.
- Estrategias de respaldo para cada BC.
Aconsejar
El equipo de desarrollo de productos solicitará el asesoramiento del equipo de operaciones antes de tomar una decisión.
- Estrategia de vigilancia de los anfitriones/servicios de propiedad del desarrollo de productos.
- Estrategia de alerta para el desarrollo de productos de propiedad de los anfitriones/servicios.
Preguntar
El equipo de desarrollo del producto tomará una decisión e informará al equipo de operaciones de lo que se haya decidido y se le podrá pedir que comparta el proceso y la información que conduzcan a esta elección.
- Seleccionando un sistema operativo de servidor de aplicaciones en el menú.
- Seleccionando un lenguaje de programación para el código de prueba y configurando los agentes de construcción para ejecutarlo.
- Seleccionando una herramienta de despliegue en el menú.
- Modelado del esquema de Cassandra.
Delegado
El equipo de desarrollo del producto tomará la decisión y no se requiere ninguna notificación, documentación, ni tampoco la documentación del equipo de operaciones.
- Determinar el formato de registro de la aplicación, los contenidos y el servicio de agregación.
- Selección de un marco de aplicación web
Decisiones del equipo de seguridad
Tell
El equipo de seguridad toma una decisión para los equipos de desarrollo de productos y puede explicar la motivación. Abrir una discusión sobre la decisión no es ni deseado ni asumido.
- Selección de servicios de exploración de vulnerabilidades de seguridad y proveedores de pruebas de penetración.
- Acciones a tomar durante una brecha o un incidente de seguridad importante.
Vender
El equipo de seguridad toma una decisión para la organización y luego trata de convencer a los miembros de los equipos de desarrollo de productos de que es la elección correcta y les ayudará a sentirse involucrados.
- Selección de elementos de seguridad obligatorios para la lista de verificación de la aplicación de la producción.
- Seleccionando las normas de seguridad de la industria que la empresa cumplirá (es decir, ISO 27001⁄2, PCI, CIS, NIST 800, etc.).
Consultar
El equipo de seguridad pedirá primero su opinión, que será considerada antes de tomar una decisión que respete las opiniones de los equipos de producto.
- Categorizando los riesgos de seguridad y las vulnerabilidades.
- Normas y estrategias criptográficas para los datos sensibles en tránsito.
- Normas y estrategias criptográficas para datos sensibles en reposo.
De acuerdo
El equipo de seguridad entrará en una discusión con el equipo o equipos de desarrollo del producto y tomará una decisión como grupo.
- Capacitación anual requerida para el desarrollo específico de la seguridad.
- Estrategia de vigilancia de la seguridad de los anfitriones/servicios de la BC.
- Estrategia de alerta de seguridad para los anfitriones/servicios de BC.
Aconsejar
El equipo de desarrollo del producto solicitará el asesoramiento del equipo de seguridad antes de tomar una decisión.
- Cómo implementar controles específicos de seguridad estándar.
Preguntar
El equipo de desarrollo del producto tomará una decisión e informará al equipo de seguridad de lo que se ha decidido y se le podrá pedir que comparta el proceso y la información que conduzcan a esta elección.
- Determinar las técnicas de endurecimiento de la configuración específica de la tecnología.
- Determinar cómo manejar, procesar y almacenar de forma segura los autentificadores o credenciales.
Delegado
El equipo de desarrollo del producto tomará la decisión y el equipo de seguridad no requiere ninguna notificación, documentación ni
- Seleccionar un proceso para garantizar que se utilicen prácticas de codificación seguras en el desarrollo.
- Seleccionando herramientas o métodos de seguridad para revisar el código antes de que se comprometa con los repositorios corporativos.
Ejecutar con mayor claridad
Al establecer un marco de toma de decisiones, podemos liberar el poder de nuestros equipos de desarrollo. No hay necesidad de reuniones excesivas para elegir la tecnología, y nuestros equipos no ocultan sus elecciones con la intención de buscar el perdón después de que la implementación se haya completado.
Categorías: prácticasTags: architecture, devops