architecture - software - Configurar un departamento de arquitectura
architecture traduccion (9)
Algún contexto por adelantado:
Imagine una empresa de más de 200 desarrolladores que finalmente establezca un equipo / departamento de arquitectura más o menos independiente. La cartera de software que consta de más de 20 "proyectos" / aplicaciones de diversos tamaños en la producción fue atendida por los líderes del equipo / técnicos, que también se responsabilizaron y se encargaron de la arquitectura del proyecto.
Debido a la necesidad de consolidar y controlar la arquitectura y permitir ciertas revisiones necesarias en los sistemas en su conjunto, además del tan necesario intercambio de conocimientos, la empresa decidió establecer un departamento de arquitectura.
¿Cuáles son los HACER y NO HACER de tal empresa?
¿Quiénes son las personas que componen ese equipo de arquitectura?
¿Cuáles deberían ser sus responsabilidades?
¿Qué está fuera de su alcance?
¿Cuáles son las estrategias de transición útiles para la empresa?
¿Cómo evitar esas miradas irónicas cada vez que alguien menciona "el equipo de arquitectura"?
¿Tu empresa sufrió un cambio de este tipo con éxito?
¿Por qué falló?
¿Por qué fue exitoso?
Eso no debería ser una discusión sobre "¿Qué es architecutre?" (Que está muy relacionado;).
Los puntos realmente interesantes serían aceptables / realistas, tal vez incluso sin fricciones, para instalar un equipo así, además, por supuesto, algunas advertencias sobre las batallas mejor ni siquiera comenzarían.
Aquí hay algunas cuestiones que deben tenerse en cuenta:
- ¿Cuál es el mandato exacto para el equipo de arquitectura?
- ¿Cuál es el producto del equipo de arquitectura? Un marco, directrices, ayuda para la implementación ... ¿O solo son astronautas de arquitectura ?
- ¿Esto es solo para aplicaciones en el futuro, o será un respaldo?
- ¿Quién será responsable de backporting? (Y nos referimos a presupuesto aquí ...)
- ¿Habrá recursos asignados para probar los backports?
- ¿El equipo de arquitectura tiene un músculo real, o la gestión se retirará cuando el primer grupo gruñe durante los 4 meses que tardará en implementar los cambios?
- ¿Cómo va a lidiar con la fricción entre los grupos de proyectos individuales y el equipo de architure (y habrá fricción?). Los oportunistas tomarán esto como una maravillosa oportunidad para competir por posición ...
- Tenga en cuenta que esto será principalmente un juego político ...
Amigo mío, tienes un camino difícil por delante ...
El primer paso es ser muy claro sobre lo que se supone que debe lograr el equipo de arquitectura.
¿Por qué estás poniendo el equipo en su lugar?
¿Estás tratando de unificar todas las aplicaciones, desarrollar un marco común, qué?
¿Cuál es el mandato y la visión de este equipo?
Quienquiera que sea el líder en este equipo, mejor tenga una ** habilidad interpersonal.
No debería ser el codificador brillante que puede silbar la canción del tema de las Guerras de las Galaxias y hacer ruidos de sables de luz ... pero probablemente debería estar en el equipo en una capacidad técnica.
Probablemente deberías completar el equipo con personas que estén familiarizadas con la mayoría de los proyectos. Sería cauteloso de seleccionar todas las pistas actuales, ya que podría tomar una gran parte del conocimiento de los equipos actuales. Y enfrentémoslo, esos equipos deben ser productivos mientras que el equipo de arquitectura presenta sus propios entregables.
Creo que el equipo de arquitectura necesita personas lo suficientemente experimentadas que conozcan el funcionamiento interno de todos los equipos de desarrollo y puedan decir No a las solicitudes / líneas de guía. He estado en equipos con buenos desarrolladores, pero aún no tengo suficiente autoridad y terminé siguiendo a los gerentes de desarrolladores de rango más alto de diferentes equipos y producí marcos inconsistentes.
Interesante pregunta.
Primero, debe tener una noción clara de qué problema está resolviendo este equipo de "arquitectura". Si no puede definir claramente la "misión" del equipo, fallará y lo hará con grandes explosiones. :)
Dicho esto, el primer paso es definir el problema que está resolviendo. ¿Estás tratando de mantenerte al día con la tecnología? ¿Estás tratando de incorporar alguna reutilización de código entre proyectos? ¿Estás tratando de utilizar al personal de desarrollo para obtener el mejor efecto posible? Existen varios motivos para implementar un equipo de arquitectura y, dada su configuración, cualquiera de estos puede ser suficiente. A partir de su pregunta, parece que su objetivo es volver a trabajar con las aplicaciones existentes, por lo que es un buen primer paso.
Como ya tiene un grupo de clientes potenciales que tienen un buen conocimiento específico de las aplicaciones, sería una buena idea comenzar con ellas. Reúnalos y explique cómo debería ser la nueva arquitectura global. Es posible que también desee obtener un asesor para ayudar a facilitar la conversación en este punto. Defina los objetivos de la reelaboración y obtenga un "panorama general" con el que todos puedan estar de acuerdo.
Después de eso, tomaría un puñado de clientes potenciales y los promocionaría (rellenando los contactos del grupo de desarrolladores) con el equipo de arquitectura. Luego se reunirán con los líderes para asegurarse de que las cosas vayan de acuerdo con esa "Gran imagen".
NO TRAERÍA un grupo completamente nuevo desde el exterior. Eso crearía una dinámica no deseada de Us vs. Them que nunca es buena. Los forasteros tampoco tendrían idea de cómo se supone que funcionan las cosas o por qué las cosas no funcionan de la forma en que la lógica implicaría que deberían funcionar. :)
La arquitectura es difícil de hacer bien.
Los "Arquitectos" necesitan el poder de hacer las cosas, pero deben ser lo suficientemente inteligentes como para no abusar de ese poder y alienar por completo al resto de la empresa.
He trabajado en dos lugares donde se implementaron equipos de arquitectura: uno fue un éxito y el otro no se ve tan bien. En el lugar exitoso, era un entorno relativamente pequeño donde el arquitecto jefe era reconocido como un líder técnico, y los otros miembros del equipo tenían excelentes habilidades de redacción y políticas. Todos actuaron en el mejor interés de la organización.
En el lugar en el que no funcionó tan bien, los arquitectos representaron claramente facciones específicas en la organización, y no ganaron la confianza o el respeto de todo el lugar. El resultado fue que se pasó más tiempo cocinando excusas para eludir la arquitectura que extraer cualquier valor de ella. En este caso, la frustración se convirtió en pasiva / agresiva y otras conductas antisociales.
Creo que las demás preguntas que hace sobre alcance / responsabilidades / transición se responden todas ellas con "depende". Depende de la compañía, la gente, el dinero y el cronograma.
en general, tenga mucho cuidado con los incentivos tanto políticos como asociados con el grupo de arquitectura. es muy fácil para la ''junta de revisión arquitectónica'' (o como se quiera llamar) convertirse en barreras para el progreso. Todo lo que se necesita es un incentivo cero para mejorar las cosas y un incentivo negativo cuando las cosas cambian y no mejoran de inmediato.
darse cuenta de que se cometerán errores, que algunas "nuevas y excelentes tecnologías" se convertirán en modas a medias y que impulsarán el cambio y la innovación. esto puede ocasionar un trastorno ocasional a corto plazo y una transformación fallida, pero eso es mejor que el estancamiento.
y la alternativa inevitablemente produce estancamiento; en las organizaciones más grandes he visto arruinadas las carreras porque un gerente creía lo suficiente en su equipo como para respaldar su recomendación de una nueva tecnología hasta el tope, proporcionar los estudios de caso para probarlo y volver al grano. Cuando finalmente se aprobó la nueva tecnología (después de casi un año de luchas internas políticas), el CTO (que se opuso a ella todo el tiempo) reclamó crédito por la innovación y transfirió al gerente a un departamento alejado. En otro incidente, se propuso una nueva tecnología, con numerosos ejemplos de éxito en la misma área comercial, y se formó un comité para estudiar el tema. Cinco años después todavía están estudiando el problema, y no se ha hecho nada
"Arquitectura" en este contexto en sí mismo no significa nada. Significa "expertos en temas transversales".
Cada vez que tenga un "Equipo de Arquitectura", tendrá un equipo transversal que proporcionará servicios para muchos proyectos.
Como se indicó en las respuestas anteriores, debe saber qué temas tendrá que abordar un "departamento de arquitectura".
Ahora, aquí hay un ejemplo de organización de equipos de arquitectura basados en varios temas:
- Equipo de negocios y arquitectura funcional: escribe muchas especificaciones relacionadas con el negocio y verifica la alineación entre la aplicación existente y el flujo de trabajo funcional, para completar una cartografía coherente de la aplicación.
- Equipo de arquitectura de aplicaciones: proporciona la cartografía, pero también decide cómo las especificaciones funcionales decididas por el equipo de arquitectura comercial y funcional se organizarán en aplicaciones.
Por ejemplo, necesita un módulo funcional para "proceso de cartera", pero el equipo de Arquitectura de aplicaciones puede decidir dividirlo en un "iniciador", un "despachador", una GUI, y así sucesivamente. - Equipos de Arquitectura Técnica, siempre integrados por:
- El equipo de Execution Architecture, para todos los temas no puramente técnicos (registro, KPI, marcos, ...)
- Equipo de Arquitectura de Desarrollo (evaluación y soporte de herramientas, estudio tecnológico, gestión de repositorios para control de versiones y configuración)
- OA (arquitectura operativa) para hacer que un entorno sea "ejecutable" (es decir, conocer los procesos correctos, los servidores correctos y las redes correctas para implementar su sistema, ya sea para la homologación o para la producción).
Es posible que desee agregar un equipo de logística para toda la administración de servidores y redes, con las tareas de las estrategias de Copia de seguridad y DRP. Y una estrategia de soporte basada en un buen sistema de casos.
Y eres bueno para ir.
Ahora, no olvides que cuando comiences un "gran trabajo", tu Arquitectura Funcional tendrá la misión de reforzar las coherencias entre:
- los proyectos reelaborados para asegurarse de que permanezcan dentro del perímetro funcional fijo
- los proyectos heredados para asegurarse de que sus mantenimientos no impliquen elecciones opuestas en comparación con la aplicada a los proyectos rediseñados.
Cualquier revisión en una tienda de este tamaño significa, de hecho, poder realizar las evoluciones necesarias para los proyectos heredados mientras se espera que el reprocesamiento produzca los primeros lanzamientos. (El legado no puede esperar y quedarse quieto durante 2-3 años de retrabajo)
Un gran retrabajo debería implicar tres hitos importantes:
- 1 / diálogo con el legado
- 2 / completa el legado
- 3 / reemplazar el legado
¡Significa que cualquier componente dado está en efecto desarrollado tres veces! ;)
Buena suerte y buenas noches.
Necesita trabajar a través de los escenarios empresariales A) y B)
A) ¿Qué sucede si no lo configura, es decir, no hace nada?
Estimaciones de la repetición de los costos de mantenimiento
B) Usted configura entonces:
Interrupción a entregables a corto plazo, debido a la desviación de recursos.
Riesgo de productos múltiples pueden desaprovecharse en el corto plazo.
Costos de la mano de obra extra percibida.
Quién marcará si los productos se debilitan por el ejercicio (rendimiento o inflexibilidad percibida)
A continuación, obtenga los equipos de productos para el mismo ejercicio, compare los resultados.
Si lo justifica, aquí hay dos rutas que he visto :
1. Elija un producto líder para impulsar la arquitectura y agregar recursos a este proyecto.
Luego, prepárese para agregar más recursos y sea paciente, de lo contrario, el producto principal sufrirá.
Se arriesga a la división con esta ruta, funcionó cuando el producto líder era el 40% de los ingresos.
2. Poner en marcha un pequeño equipo, extraído de las discusiones más prometedoras que se han estado produciendo internamente, envolver gradualmente la nueva arquitectura en cada producto.
Tejemos este trabajo de equipo en el trabajo de los productos.
Alguna pregunta para que veas :
1. ¿Qué tan pronto debe lograr la convergencia de arquitectura para obtener el beneficio comercial?
2. ¿Quiénes son los miembros del equipo que ya están hablando sobre la convergencia de la arquitectura, y están preguntando / sugiriendo su importancia, usted necesita esta pregunta en el "segundo plano" para el 80% de los líderes de su equipo?
Qué no hacer
* Contratar expertos desde fuera (a menos que estés en un verdadero lío ahora)
* Renunciar después de unos meses, esto es a largo plazo.
* Cambia todos los proyectos a la vez.
* Comience hasta que tenga un núcleo de tres que pueda hacer que esto suceda.
* Deje que el departamento de arquitectura se vuelva más grande de lo que tiene que ser
* Permita que se perciba que el departamento de arquitectura resolverá los problemas de los equipos de productos
* Deje que cualquier producto parezca estar "esperando la nueva arquitectura"
* Permitir que el departamento de arquitectura "defina todo" o tenga alcance fluencia
* Forzar todos los productos en la arquitectura, algunos pueden no encajar (por ejemplo, no desarrollados en el mismo país)
Que hacer?
* Armado con una buena justificación a partir de la primera pregunta, haga que la gerencia superior compre y solicite a los equipos de producto que informen el progreso.
* Realice cambios paso a paso en la alineación del producto al mapa de la arquitectura
* Trabajar en la alineación de las líneas de productos más prometedoras o de bajo riesgo primero
* Configure las métricas para que pueda demostrar el valor agregado (consulte la justificación del primer conjunto de preguntas)
* Tener una hoja de ruta para todos los productos converger o no.
* Piense en lo que ofrece la arquitectura central y quién mantiene sus artefactos
* Permitir que los equipos de producto contribuyan al núcleo en términos de especificaciones, código y mantenimiento del núcleo
* Configurar la capacitación sobre cómo usar el trabajo del equipo de arquitectura para los nuevos titulares y los equipos existentes
La arquitectura sola puede convertir a las personas en astronautas / zombis. Por lo tanto, definitivamente deberían tener alguna codificación que hacer, incluso si eso es prototipos básicos. De hecho, el éxito de sus prototipos debe ser un factor de revisión definido.
Deben dar presentaciones mensuales / blogs frecuentes que sigan su trabajo, para que otros en la organización puedan aprender.
Debe haber objetivos académicos como estar familiarizado con ciertas plataformas / herramientas / libros y filosofías de diseño.
Se les debe dar tiempo para buscar nuevas herramientas / proyectos / responsabilidades en los proyectos existentes si así lo desean.
Tendrían la responsabilidad de hacer al menos 3-4 revisiones de códigos de módulos críticos y elaborar pautas de estilo de código.
Tendrían la responsabilidad de revisar los diseños de bajo nivel al menos de los módulos clave.
Se les debe dar tiempo libre como individuos o equipo para construir algo que sientan que puede ser útil.
Deben tener la opción de renunciar a la arquitectura y volver al trabajo habitual si les da la gana sin penalizaciones.
Deben tener la información sobre lo que sucede en todos los proyectos que se ejecutan en la organización. Al menos un proyecto debe seguirse de cerca para que puedan informar a sus propios compañeros acerca de las cosas que suceden en otros lugares. Este puede ser posiblemente el proyecto en el que realizan revisiones de código y tal.
Deben tener una persona altamente técnica como su gerente.
Los arquitectos deben cambiar de proyecto una vez que estén muy familiarizados con uno de ellos, y se les permita seguir cualquier prototipo que estén siguiendo mientras trabajan con el proyecto original.
Tener al menos un objetivo real (como consolidar todos los elementos comunes en todos los proyectos en una sola biblioteca) cada 1 año
Invierta tiempo y capacitación para asegurarse de que los arquitectos no se comprometan con su ego y lo conduzcan de manera bastante profesional. La resolución de conflictos y otras capacitaciones de habilidades blandas junto con el presupuesto para reuniones técnicas y capacitaciones serían definitivamente necesarias también.
Considere leer / comprar este artículo de ACM: The Software Architect . Hay varias referencias disponibles allí y el autor es inusualmente lúcido sobre un tema tan difuso. Él no responderá sus preguntas directamente, pero el artículo enfocará su estrategia.
La respuesta mejor clasificada a su pregunta es un buen punto: concéntrese en las habilidades interpersonales y defina los objetivos. Agregaría una comprensión profunda de cómo se hacen las cosas en su organización.