Definiendo Capacity de Arquitectura

Hace poco en una empresa me pidieron que les ayude a definir la capacidad de arquitectura que necesitaban para poder hacer frente a las necesidades de la organización. Como no es la primera vez que surge la necesidad de definir la capacidad, voy a tratar de explicar cuál es mi experiencia y conocimiento sobre el tema.

¿Qué arquitecto?

Antes que nada, para definir cuantos arquitectos necesita una empresa hay que preguntar a que llaman arquitecto.

En una organización podemos encontrar varios tipos  de arquitectos distintos, arquitectos empresariales, de dominio, de segmento, de solución, de software, de un lenguaje en particular, de una tecnología en particular… Como ven el menú es variado.

Dependiendo del tipo de industria y cultura de las empresas, la tendencia a futuro es contar cada vez con más arquitectos “dueños” del conocimiento y utilizar proveedores de servicios en implementar las definiciones de arquitectura.

Por tal motivo, los roles de arquitecto empresarial y de solución se imponen como preponderantes para el éxito de las soluciones informáticas del futuro. Dependiendo de la madurez de la organización, podríamos encontrar arquitectos de dominio y de segmento, pero definitivamente los arquitectos de software, lenguaje o de una tecnología en particular estarían del lado del proveedor de servicios.

Ahora bien, retomando el tema, deberíamos decir: ¿Cuántos arquitectos empresariales necesito? ¿Cuantos arquitectos de solución? ¿Cuantos arquitectos de segmento? ¿Cuantos arquitectos de dominio?

En este post me gustaría hace foco en ¿Cuantos arquitectos de solución? Más adelante hablaremos de los otros arquitectos.

Participación del arquitecto

Un ciclo de entrega de soluciones típicamente tiene las fases de Idea, Inicio, Definición, Diseño, Construcción, Testing, Deploy y su posterior Operación.

Claramente, el primer esfuerzo del arquitecto de solución se da en la fase de inicio, donde es parte de entender el alcance, el contexto y los principales stakeholders, luego es el principal responsable de la fase de definición donde sería el diseño de alto nivel sale a luz, finalmente, en la fase de diseño debería adoptar un rol de ser fuente de consulta de los analistas que hacen el diseño técnico detallado.

En algunas empresas los arquitectos, están presentes en todas las fases, convirtiéndose en una especie de PM técnico. Este tipo de práctica, hace que el arquitecto pierda su principal foco que es conseguir el mejor diseño posible alineado con las prácticas de arquitectura empresarial y empiece a preocuparse por temas de implementación, como si se habilitaron las reglas del firewall, si están los accesos para todos los usuarios, etc.

Otra práctica que no  es recomendable,  es que el arquitecto de solución este diseñando muchas soluciones al mismo tiempo, es preferible ajustar los programas de proyectos, para asegurar la participación de arquitectura de forma escalonada y evitar que se convierta en un cuello de botella por todas los diseños que es estén encarando a la vez.

Una regla que se suele utilizar para el dimensionamiento de los arquitectos de solución, es emparejarlos con el de PM, si un proyecto tiene un PM, entonces tiene que tener un Arquitecto de Solución, si hay proyectos con menos complejidad y un mismo PM puede tener 2 proyectos en forma simultánea, el  Arquitecto de Solución podría estar diseñando 2 soluciones de forma simultánea.

 

Conclusión

• ·       La cantidad de arquitectos de solución que se necesita, depende de la cantidad de proyectos, su complejidad y su calendarización
  ·         La regla del PM puede servir para determinar la cantidad de arquitectos de solución
  ·         El tiempo que dura la fase de definición, donde se concentra el mayor esfuerzo del arquitecto de solución, es de entre 15% y 25% del total del proyecto, dependiendo de la complejidad e impacto en la arquitectura.
  ·         Calendarizar los proyectos para asegurar la optimización del arquitectos de solución (en realidad, debería hacerse para todos los recursos críticos).
  ·         Si tenemos 100 proyectos, no necesitamos 100 arquitectos de solución, necesitamos un mago, porque no hay organización que pueda llevar adelante tal cantidad de proyectos de forma exitosa