Ir al contenido principal

Y... ¿quien necesita arquitectos?


No necesitamos arquitectos.

Claro que NO. Somos un equipo de desarrolladores competentes, todos muy capaces, genios comprobados y mal apreciados, somos la crema y nata de la tecnología, los ases de la codificación, los reyes de los lenguajes y las tecnologías. NO. Nosotros no necesitamos ningún dinosaurio con pretensiones de Anciano de la Matrix que venga a decirnos lo que Nosotros, amos y señores, ya sabemos. Los arquitectos son para equipos de retardado y cuasi idiotas.

Y…. este, mis queridos lectores, es el modo de pensar de muchos equipos de desarrollo en la actualidad.

Como dijo un querido amigo, llenos de concreciones y nada de abstracciones.

Pero, adentrándonos en el tema, primero necesitamos resolver algo, ¿cual es el rol del arquitecto de software en un equipo de desarrollo?

Muchos piensan que el arquitecto es el responsable de definir los componentes estructurales y comunicacionales de un proyecto de software. Y eso es verdad. Pero es baladí por ser una obviedad. En palabras del Dr Lecter “eso es Incidental”.


 Otros ven al arquitecto como la versión técnico funcional del Jefe de Proyectos. Algo así como el hombre del látigo, el negrero que en el buque de esclavos marcaba el ritmo a golpes de tambor. Un tirano cuyo trabajo es imponer sus designios y “mariquismos” detallistas a los genios y esclavizados desarrolladores.

Digamos que esto, en cierta medida, es también verdad, pero sólo en parte. Es parte de las tareas del arquitecto el dirigir algunos aspectos técnicos del proyecto, pero, nuevamente, ese no es el rol central del arquitecto.

Y están los que ven al arquitecto como un Dios del Olimpo, inalcanzable en su mundo de Patrones y estructuras, un ser supremo que, de vez en cuando, se digna a bajar a la tierra y brindar un poco de luz a los parias y demás humanos, quienes deberán obedecer y celebrar ese maravilloso día de epifanía.

No haré comentarios respecto a esto último por ser absolutamente Verdad!! jajajajajaja, bromeo.

Pero no, tampoco ese es el rol principal de dios, digo, perdón, del arquitecto.


Amigos, el arquitecto es el responsable de la CALIDAD.


Si el arquitecto toma decisiones pobres, la calidad del proyecto será pobre.

Si el arquitecto toma decisiones adecuadas, la calidad del proyecto será elevada.

Cómo delegue o implemente el arquitecto esa responsabilidad sobre la calidad puede variar, y de hecho lo hace, y mucho. Quizá use la integración continua, patrones de diseño, anti-patrones, pruebas funcionales, pruebas de integración, pruebas automáticas,, pruebas de calidad estática, esquemas de comunicación, esquemas de capas, políticas de seguridad, esquemas de gestión, virtualización, paralelización, criptografía, y un largo etcétera.

Pero, al fin y al cabo, la calidad de un proyecto de software es responsabilidad directa del arquitecto. Ese es su rol principal. 

Y entonces, ¿necesitamos arquitectos?
Claro que Yes.

Y por una simple razón.

Porque necesitamos a quien echarle la culpa. Sobre todo cuando las cosas van mal. Y es allí cuando contar con un arquitecto es una gran ventaja!!! jajajjaja.

Suena a chiste, pero es verdad. 

Un arquitecto debe hacerse responsable de sus decisiones. De la calidad del proyecto. De la calidad de código. De la calidad funcional y operativa. De toda la calidad. Y sea buena o mala El es el responsable de eso.

Si su arquitecto no toma buenas decisiones, CÁMBIELO.

Pero consiga otro mejor.


A arquitecto muerto, arquitecto puesto.

Comentarios

  1. "El primer matrix que diseñé era casi perfecto, una obra de arte. Preciso. Sublime. Un éxito solo equiparable a su monumental… fallo."
    -Como mi primer gran sistema!!!! jajajajaja

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos a l