Aunque parezca paradójico, es habitual que sea más complicado generar una solución sencilla, a una compleja, o dicho de otro modo, que para obtener una solución más eficaz y sencilla funcionalmente, tengamos que madurar y trabajar mucho más la parte de diseño e implementación, lo cual a veces, además de escamar un poco, pasa desapercibido como uno de los puntos clave para alcanzar el éxito.
Es más, habitualmente ocurre lo contrario, durante la típica lluvia de ideas antes de llevar a cabo un proyecto, parecen destacar o llevarse el gato al agua las ideas más enrevesadas o llamativas, que no por peculiares suponen mayor sobreesfuerzo de implantación, pero sí de mantenimiento a medio y largo plazo.
Y esto que a priori parece una tontería, no lo es tanto cuando luego el monstruo de turno crece, y has de cuidarlo y mantenerlo a lo largo del tiempo, consumiendo gran cantidad de los pocos recursos que tienes, y especialmente el más importante: el tiempo disponible.
Lo anterior es aplicable a prácticamente cualquier solución TIC, desde un proyecto relacionado a Sistemas, por ejemplo montar un nuevo servicio, sobre todo cuando es relativamente complejo, a proyectos de Desarrollo, en los que el diseño abarca no sólo la idiosincrasia del software de turno, sino la interacción de los usuarios con éste.
Para complicar todo lo anterior un poco, llegamos a ese concepto de sencillez funcional, que aunque puede tener unos objetivos comunes para todos los casos, cambia totalmente de naturaleza según unos y otros, de modo que lo que para una empresa puede ser una solución “sencilla”, para otra supone todo lo contrario, y viceversa. Y es que esta sencillez está relacionada también a los recursos, escalabilidad, conocimiento y naturaleza de la empresa en cuestión.
Ojo, es importante no confundir esta sencillez de la que estamos hablando, con falta de innovación o adopción de nuevas tendencias tecnológicas, todo lo contrario, se trata precisamente de innovar y adoptar las nuevas tendencias, para que el servicio que vas a desplegar o la aplicación que vas a desarrollar, se asiente sobre unos cimientos claros y por decirlo de algún modo lo más “sencillos” posibles, que permitan sus sostenibilidad a lo largo del tiempo, y su robustez ante fallos y errores.
Esto está relativamente relacionado al factor modas, del que hablé en https://ciberseguridadtotal.com/el-peligro-de-las-modas-tecnologicas/, no es necesario adoptar una tecnología porque sea top en un momento dado, sino porque es la mejor solución para el problema al que te enfrentas, de otro modo, te puedes ver enredando en otro tipo de cosas diferentes a los objetivos que tenías en un principio.
Es decir, tratando de resumir todo el rollo anterior, cuando vas a llevar a cabo un proyecto, del tipo que sea, encontrarás diversos caminos que lleven a cumplir los objetivos. Cada camino tendrá unos pros y unos contras, y al final será cuestión de inclinar la balanza hacia un tipo de solución y otra. Pero en todo ese tejemaneje, hay algo que debe prevalecer, y es tratar de conformar una solución lo más sencilla posible: sencilla de desarrollar, implantar, exportar, mantener a lo largo del tiempo, y mejorar continuamente; Y además haciendo relación al título de este blog, que pueda mantenerse segura y parchearse a lo largo del tiempo con objeto de evitar ataques y vulnerabilidades.
Soy de los que piensan que las cosas se entienden siempre mucho mejor con un ejemplo, aunque probablemente a todos se nos vienen a la cabeza unos cuantos relacionados a este tema. Por definir simplemente uno, recientemente me encontré con una empresa con el típico ERP de turno, el mismo estaba parte on-premise, parte en cloud, y además por el parcheo y personalización era imposible su actualización, y el mantenimiento dependía de 2 actores totalmente diferentes e independientes. Estoy seguro que hubo motivos para tener el escenario de este modo, y seguramente cambiarlo ahora conlleve un gran trabajo, pero la situación claramente prevé problemas urgentes en lo relativo a gestión, mantenimiento y disponibilidad del servicio.
Respecto al desarrollo software, los ejemplos salen sólos, pero aquí el asunto se complica, porque el proceso de “toma de requisitos” muchas veces se convierte en una auténtica verbena. Piensas en la mejor manera para llegar a una meta, tomas el camino elegido, y luego te encuentras otras consideraciones, que dejan de hacer tu elección como la más adecuada, pero has andado tanto, que no tiene sentido volver atrás, así que terminas completando la ruta con peros, peros consistentes en el parcheado y complejidad de esa solución “ideal” que tenías en la cabeza.
¿Algún consejo?
Normalmente es inevitable terminar complicando servicios o estructuras inicialmente concebidas de otro modo, esto viene dado por múltiples motivos: nuevos requisitos, funcionalidades, y cambios que surgen a lo largo del tiempo, No obstante, algunas buenas prácticas son:
- Toma de requisitos: Recoger todas las necesidades y objetivos de tu proyecto, ver posibles mejoras a corto o medio plazo susceptibles de ser aplicadas, ya sea con más presupuesto, etc, y ver cómo encaja todo.
- Evaluar: Todo proyecto debiera llevar una masticada fase de evaluación preliminar, ver las distintas opciones para dar solución al desafío al que te enfrentas. Esto puede conllevar evaluar desde aplicaciones concretas, a lenguajes de programación, o incluso soluciones mucho más complejas.
- Prever lo que llegará: Esto más que escalar la solución, que bien puede entrar en la parte de evaluación preliminar, se refiere a tratar de adivinar el futuro, tal cuál, estilo bola de cristal: cómo este proyecto se va a enfrentar a lo que vendrá más adelante, imaginar cómo lo vamos a mantener, cómo se puede integrar en las tecnologías que están a la vuelta de la esquina, qué funcionalidades es posible que nos pidan más adelante, etc.
Todo lo anterior no es mano de Santo, pero ayudará a generar una solución lo más sencilla posible, dentro de la complejidad que lógicamente forma parte de su naturaleza.
