Debo confesar que últimamente me he preguntado constantemente hacia donde va el desarrollo de software?… Después de leer artículos de distintos blogs, de los cuales por cierto rescató algunos tips, pero en general no comparto las conclusiones o afirmaciones finales, me he decidido a escribir este articulo, haciendo un esfuerzo por trabajar en el tema de manera que al menos presente mi opinión de la forma mas fundamentada posible (en el contexto de un articulo breve escrito en un blog).

Sin embargo para no ser arrogante al respecto solo me centrare en las soluciones orientadas a empresas en lo que se conoce como soluciones específicas, que normalmente se venden a un precio llave en mano. En el clásico escenario en que una empresa requiere una versión nueva o una herramienta de software que no tiene y que requiere construir bajo especificaciones muy propias de un negocio en particular.

Cual es el futuro de este tipo de software?

Que mejor forma de resolver esta pregunta, observando que nos dice el pasado y la historia, en relación a como se construían estos tipos de soluciones. Desde mi humilde punto de vista, éste, nos indica que la tendencia histórica es que las herramientas de programación exitosas se orienten a soluciones que disminuyan el costo de los desarrollos y aumenten el nivel posible de complejidad a alcanzar en las mismas. Sin embargo cada vez que esto ocurre, esas mismas herramientas o tecnologías se fuerzan contra proyectos de desarrollo cada vez mas complejos. En un punto en particular, una nueva generación de herramientas nace. Dando respuesta a este nuevo nivel de dificultad en los proyectos que se abordan.

Por ejemplo, hace 15 años, lo normal a la hora de programar era utilizar lenguajes clásicos como pascal, C++, Basic, ADA, Fortran u otros similares. La búsqueda en esos años se centro en buscar el mejor lenguaje. Efectivamente surgieron muchos que aun se mantienen, pero la tecnología del desarrollo de software llego a un punto donde el lenguaje no era lo importante, ya que los niveles de complejidad estaban ligados al código independientemente del lenguaje. En el algún punto hace ya varios años, aparecieron los IDEs Visuales o herramientas de programación que intentaron llevar de forma mas visual como se programaban los sistemas, ejemplos masivos de esto son Visual Basic, Delphi, y un sin numero de otras tecnologías que sin utilizar el mejor lenguaje evolucionaron rápidamente, finalmente la mayoría de los lenguajes que sobrevivieron se adaptaron a soluciones mas visuales de programación. De esta forma un nuevo nivel de complejidad pudo ser aumentado en el alcance posible de las soluciones. La era de los sistemas Cliente Servidor clásicos nació, y los grandes proyectos de desarrollo se presentaron como posibles a un precio y plazo razonables para las medianas y grandes empresas.

En el mundo de los PCs, los MainFrames fueron desapareciendo lentamente debido a la dificultad de mantenerlos en relación al modelo Cliente Servidor. El Clásico modelo cliente servidor sufrió una importante mejora cuando la Web empezó su desarrollo, los clientes se empezaron a adelgazar hasta construir sistemas Cliente Servidor donde el cliente era la Web, y el servidor se parecía mas a un pequeño Mainframe. Asi aparecieron los sistemas WebEnable, el cambio en las herramientas de desarrollo desde mi punto de vista no fue grande. Solo se afecto la parte gráfica y se adaptaron los lenguajes de manera de convivir con el Html. Las ventajas de no tener que instalar el cliente en cuanto PC era necesario también ayudo mucho a que las soluciones Web Enabled se difundieran como nuevo modelo a seguir.

En un punto muy cercano al presente las soluciones Web Enabled, han sido capaces a través de tecnologías como WebService y otras como SOA, subir un peldaño mas en la sofisticación y complejidad de las soluciones posibles de enfrentar. Ahora construir sistemas interconectados que integren un sin numero de componentes o subsistemas de una forma relativamente sencilla y masiva como base para integraciones de gran nivel, son posibles. Grandes corporaciones puden ahora con estas tecnologías llegar a soluciones Globales y de gran alcance. La pregunta de oro, para poder entender cual será el próximo salto para un nivel mayor de complejidad a abordar es:

"Cual es el problema a solucionar cuando la tecnología actual nos indica que a nivel tecnológico están listos para un próximo paso", en otras palabras, cuando el problema principal no es tecnológico donde esta el próximo paso. Mi humilde hipótesis es que esta mas cercano a la forma que a la tecnología. Pues la tecnología de base, ya esta. Entonces que tipo de forma es la que debemos buscar para poder entender por donde ira la próxima tendencia de desarrollo de software del tipo que trato en este articulo?

Si la tecnología no es el mayor problema, la forma en relación a la gráfica a aportado mucho para desarrollar de mejor manera las soluciones informáticas y aun podría ayudar un tanto mas. Donde esta el aporte que aun no aparece masivamente? (No se si lo aburro con tanta pregunta, pero mi intención es que su intuición le de algunas claves antes de contarle mi hipótesis).

Finalmente veamos los actores para ver a donde voy con tanta pregunta. Tenemos tecnologías, tenemos forma mas usables y rápidas de programar, tenemos integración posible a gran escala. Que se nos olvida?. Muy simple. Se nos olvida el Cliente, se nos olvida su negocio, se nos olvidan sus PROCESOS!. Hubo un tiempo en que este mismo enfoque y principio realizo un intento de evolución (la historia nos demuestra que eso pasa siempre antes del gran salto, son lo que yo llamo intentos marginales). Las herramienta CASE originales aportaban algo de ello, pero se centraban mas en pasos simples que en flujos o procesos, la era de los WorkFlows no fue tan exitosa como se esperaba, por que los WorkFlows no sirven siempre, sobre todo cuando la interacción humana en un sistema no es el fuerte de la solucion y arquitectura, sino solo la parte que se ve en mundo real. Entonces si miro en el mercado que tipo de soluciones aporta más en esta línea, sin duda veo que las soluciones de tipo BPM son lo mas parecido. En ellas usted no programa en base al lenguaje de tipo codigo, no programa en base a un a gráfica visual del lenguaje (aunque hay algo de esto), pero si en base a una gráfica visual de su negocio y sus procesos, nota la similitud con la historia?.

Finalmente estoy convencido que en los años por venir podremos ver como herramientas orientadas a la programación en base a procesos de negocios (gráficamente), que se soporten con tecnologías y arquitecturas Web como SOA y WebService (que serán el comoditi de la solución y no lo principal) surjan fuertemente. No deje de ver como evoluciona BPMN y BPEL, una sorpresa puede estar a la vuelta de la esquina.

No lo convence mi hipótesis? Piense en cuales son las principales criticas de las empresas no solo cuando quieren subir su nivel de sofisticación de sus soluciones. Pensemos solo cuando quieren modificar sus soluciones un poco. Su queja, es que quieren modificar su proceso, y usted termina modificando primero sus sistemas. No es lo mismo! convénzase!, que el software ayude a su proceso de negocio no es lo mismo que su proceso de negocio sea llevado por su software. Los ERP han ayudado mucho en esta línea, pero ya están agotándose por que los ERP solo juegan las reglas comunes de las empresas, no las especificas. No las que integran. Compare los ERPs mas sofisticados hoy en día, se parecen a una mezcla extraña de BPM con Sistemas clásicos del tipo Contable, Control de Inventarios, Cajas, Etc.

Finalmente mi experiencia me dice que cuando usted enfrenta un proyecto de desarrollo con herramientas de BPM, su énfasis No esta en la programación, sino en el negocio y los procesos de su cliente. Creo finalmente que este es el punto de inflexión donde los BPM terminaran imponiéndose a otras formas clásicas de desarrollo, y que la tecnología ya esta mucho mas madura que cuando aparecieron los WorkFlow hace unos años atrás, y que los procesos globales de mercado necesitan mas que nunca, orientar las soluciones informáticas a los procesos y negocios de los clientes y no a los sistemas informáticos en si.

Javier Urrutia

(2 votos, promedio: 5 de 5)

 Loading ...