Así como se busca hacer
software cada vez más inteligente, creo que deberíamos buscar hacer software cada vez más responsable, que
conozca sus limitaciones, qué que tiene que hacer y qué no.
Hace tiempo atrás las
aplicaciones o programas en las empresas eran monolíticos, únicos y se
encargaban de hacer todo, por lo tanto cuando surgía una nueva necesidad o
requerimiento era fácil decidir dónde había que hacerlo… ya que había un único
lugar para eso.
En las nuevas arquitecturas de software SOA tenemos cada vez más aplicaciones
separadas y con funcionalidad específica y concreta, se busca que cada una de
ellas esté desacoplada funcionalmente de las otras para evitar solapamientos
funcionales.
Uno de los mayores desafíos
entonces, es conseguir que cada una de ellas haga lo que tiene que hacer, sin
caer en la tentación de hacer más de lo que corresponde, es decir, es fundamental que las aplicaciones sean
responsables, la pregunta es, cómo conseguir que esto suceda?
Si vas a una peluquería y
pedís que te corten el pelo o que te afeiten, el dueño no dudará ni un instante
en hacerlo; pero si pedís que te haga un sándwich de milanesa, lo más probable
es te diga que no puede hacerlo, ya que no forma parte de sus responsabilidades
como peluquero.
Entonces porque cuando viene
un usuario a pedir que hagamos en nuestra aplicación algo que no corresponde
aceptamos hacerlo?
El desarrollador debería saber
la responsabilidad de la aplicación que está a su cargo, sus límites, qué puede
hacer y qué no, para evitar aceptar pedidos que no corresponden. Inclusive el
usuario debería ser consciente de estas responsabilidades para no pedir algo
que fuera de lugar.
Por qué resulta tan importante que el
software no haga más de lo que corresponde?
La tecnología avanza cada vez
más rápido, con lo cual cada vez más rápido nuestras aplicaciones se vuelve
obsoletas, viejas y necesitamos
cambiarlas o actualizarlas. Hacer esto en una aplicación con claras
responsabilidades y límites es mucho más sencillo, inclusive si la decisión es
tirarla y comprar una nueva, es más fácil buscar su reemplazo en el mercado; en
cambio si tenemos una aplicación que hace un poquito de cada cosa, seguro que
no va a existir en el mercado y si queremos volver a desarrollarla será difícil
entender qué hace actualmente.
Cómo puedo saber si mi aplicación es
responsable?
Una forma rápida de saberlo en
a través del nombre y su descripción funcional de alto nivel.
El nombre, más allá del nombre de fantasía, debe ser claro y marcar
sus responsabilidades, por ejemplo, si pregunto le preguntó a un desarrollador
en que aplicación está trabajando y me contesta cosas como: en el tasador, el facturador, el administrador
de recursos de red o el administrador
de campañas, estaríamos escuchando las respuestas correctas; cada una de
ellas tiene claro desde su concepción del nombre qué hacen.
Inclusive, si le pregunto a
esa misma persona qué es, cuál es su descripción,
estoy seguro que me podrá responder en un párrafo no más extenso que un tweet.
Sin embargo, cuando nos
encontramos con aplicaciones cuyos nombres son la web de Juan, el portal,
la aplicación de Pedro, el sitio de los vendedores, claramente
estamos en problemas; si a esa misma persona le preguntamos qué hace la
aplicación nos empezará a enumerar cada una de las opciones que incluye y luego
de estar hablando un largo rato dirá: ah, me olvidaba también hace…
Limitar una aplicación no es
sencillo y lamentablemente no hay una única forma de hacerlo, existen lineamientos,
tipificaciones o estándares para algunas industrias, como por ejemplo el
TmForum (www.tmforum.org) para la industria de las comunicaciones, pero esos
límites nunca son 100% claros y dejan en manos de quienes desarrollan la
definición del alcance de cada aplicación.
Entonces, qué debo pensar antes de
agregar un requerimiento a una aplicación?
Lo primero a pensar no es si
se puede hacer o no, o cuanto me cuesta, lo primero que debe pensar, tanto el
desarrollador como el usuario, es este
requerimiento debe ser resuelto por esta aplicación?
Si la respuesta es afirmativa,
entonces vendrán las preguntas de costo y factibilidad, pero si la respuesta es
no, bajo ninguna condición deberemos tomar ese requerimiento por más tentador
que resulte.
A veces por temas de costos,
económicos o de tiempos, se aceptan requerimientos que no corresponden, eso
tarde o temprano será más costoso para la empresa, para el usuario y para el
desarrollador, no permitan caer en esa tentación.
Puede el peluquero hacer un sándwich?
Claro que puede, pero no va a
saber hacerlo tan bien cómo lo harían en un bar, ni va a tener las variedades
que podría tener un bar, pero sobre todo mientras me esté haciendo el sándwich
no podrá cortarme el pelo o peor aún se distraerá y quizá termine con una oreja
menos.
Una de las principales tareas de
un arquitecto de software, es ayudar
a que cada aplicación de la empresa sea responsable y esté bien delimitada, es
fundamental que cada desarrollador lo sepa así no permite que esas
responsabilidades se diluyan; pero sobre todo se debe transmitir este
conocimiento a los usuarios para que sepan a quién deben pedirle que les
resuelvan sus necesidades y requerimientos.
No hay comentarios:
Publicar un comentario