Para muchos es difícil definir la línea que separa al desarrollador con el arquitecto de software. Algunos creen que no existe y que es una extensión del desarrollador, y otros creen que es una línea que se pasa por un excelente desarrollador cuando hace abstracciones de la abstracción y no se estanca en los detalles de implementación molestos.
Siempre existirán diferencias pero es interesante pensar o debatir como pasar la línea o notar la diferencia.
Algunas de los factores claves para determinar la arquitectura incluyen la escalabilidad, la abstracción y la toma de decisiones correctas en base al diseño. Es necesario tener una visión holistica y ver un panorama más amplio para entender como funciona un sistema en su totalidad. Si bien todo esto indica la diferencia con el desarrollo no precisamente lo hace para indicar como un desarrollador puede ser un arquitecto. Tampoco esto implica que se logrará una buena arquitectura.
Como lograr entonces identificar un arquitecto de un desarrollador?
Principalmente hay que identificar la experiencia del desarrollador. Ser arquitecto no pasa de un día al otro o de un proyecto a otro, o por un ascenso. Es algo evolutivo de determinados desarrolladores. Se logra con el tiempo y con la experiencia en diferentes negocios, proyectos, arquitecturas, soluciones, tecnologías, etc. Para detectar un arquitecto es necesario evaluar sus niveles de participación en la toma de decisiones, lo analítico que es, su influencia, su liderazgo, y la capacidad de moverse en diferentes áreas.
Para la arquitectura es necesario lograr la definición y su correcta implementación.
Un arquitecto tampoco se improvisa, he visto casos de supuestos arquitectos que necesitan googlear palabras relacionadas a arquitectura o buscar por ejemplo «como verificar si ya se hizo un alter en una tabla de base de datos». Hay conocimientos que ya deben ser parte del arquitecto, también conocer tipos de arquitectura, diferencias entre lenguajes, cómo trabaja un sistema operativo, cómo funciona un servidor web, conocer herramientas de debugging, etc, etc…
Algunos creen que la definición de la arquitectura es sencilla y se define en poco tiempo, facilmente o aplicando determinada tecnología o patrones o modelos, pero es necesario diferenciar distintos puntos:
1) La administración de requerimientos no funcionales: Es fundamental identificar requerimientos no funcionales, definirlos bien, poder medirlos, ser alcanzables, comprobables y saber como satisfacerlos. Es común que el usuario nos diga que quiere un sistema rápido y para lograrlo hay que poder identificar los requerimientos no funcionales.
2) La definición de la arquitectura: Es necesario una vez que tenemos todos los requisitos, evaluarlos y definir como vamos a resolverlos. Hay que definir las estructras y todos los aspectos técnicos del proyecto. También es importante diferenciar cuando un proyecto es de 0 y otro ya implementado que necesita extenderse, ya que hay que evaluar más puntos y la convivencia o modificación de lo ya existente.
3) Seleccionar la tecnología: Es importante evaluar varios puntos, como licencias, los proveedores, el soporte, la compatibilidad, la interoperabilidad, la instalación, el impacto en el usuario, los costos, etc. Es importante medir los riesgos. Deben evaluarse todos los casos y buscar el costo/beneficio apropiado. En este punto también es importante si el proyecto es de 0 o ya implementado.
4) Concepción: Es necesario saber el objetivo del sistema, la necesidad real del usuario y como ayudarlo técnicamente. Es importante saber que dinero piensa gastar para desarrollar el sistema y con qué recursos cuenta para llevarlo a cabo (infraestructura, equipos, licencias, software, etc.)
5) Construcción: Hay que tener la cintura para estimar los tiempos de desarrollo en base al presupuesto y con que metodologías trabajar para cumplir los objetivos.
6) Implementación: Es importante tener un plan de puesta en marcha de los sistemas y cómo actualizar y mantener las aplicaciones.
7) Visión: Es necesario tener visión en muchos aspectos, como el equipo que trabajará en el sistema, metodologías, estimaciones, capacitaciones, problemas y bugs esperados, casos de prueba, participación grupal, comunicación, recomendaciones, sugerencias, status, etc.
8) Caracteríscas de perfil: Ser autodidacta, lógico, tener experencia, racional, emocional, planificador, líder, entusiasta y sobre todas las cosas, compartir el conocimiento, enseñar y marcar al equipo para lograr los objetivos.
9) Medición: Es importante saber de métricas, todo lo que se mida, sirve para sacar estadísticas y mejorar día a día.
10) y sobre todo, saber ponerse un proyecto al hombro… si es necesario dar solución a problemas, remangarse las mangas (valga la redundancia) y meter mano en el código!
About the author:
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License
|
|
This content is property of Matias Creimerman Any misuse of this material will be punishable This work is licensed under a International Copyright Law protects «original works of authorship» including photographs, videos, and blog posts posted on social media sites The content has no rights to be shared without authorization or citation to the author. This content cannot be sold be adapted or modified partially or totally. All content shared outside this blog that doesn’t belong to the author must have citations to the author. |
Desarrollo y Arquitectura de Software por Matías Creimerman 