En otro artículo, hablamos de la implantación de software y le preguntamos si su empresa confía en soluciones estándar para las compras. Aquí nos enfrentamos a la pregunta: ¿tenemos que renunciar a la personalización con soluciones estándar? Y: ¿Qué entendemos por software configurable?

Software estándar: muchos términos, un solo principio

Empecemos por el principio. Decidimos comprar la llamada solución estándar. ¿Qué es eso? Seguro que hay diferentes opiniones al respecto, al igual que hay diferentes términos, como software "out-of-the-box" o " commercial off-the-shelf" (COTS). Definimos aquí un software estándar principalmente en referencia a la forma en que el software es desarrollado y mantenido por el proveedor.

El desarrollo de un programa informático estándar discurre por un único camino sin ramificaciones . En esta ruta de desarrollo principal -también conocida como tronco- se crean sucesivamente versiones que siempre contienen nuevas funciones (también conocidas como características). De este modo, la solución estándar sigue evolucionando con el tiempo. Esto también garantiza que una versión anterior del software pueda actualizarse fácilmente a una más reciente en cualquier momento. Esto se denomina capacidad de liberación del software, un punto muy crítico en la configurabilidad, al que llegaremos más adelante.

La estrategia de desarrollo es crucial

Por lo tanto, diferentes clientes o usuarios del software pueden tener el mismo software estándar pero con diferentes estados de liberación. En el caso del software estándar, no existen en ningún momento versiones paralelas que hayan surgido de una versión anterior común (es decir, ramas) y que cubran diferentes necesidades del cliente. Para ser precisos: esas versiones paralelas no existen "externamente", es decir, hacia el mercado. Internamente, el desarrollo puede tener diferentes ramas para que diferentes equipos puedan trabajar en diferentes partes del software en paralelo. Estas ramas de desarrollo se fusionan simplemente con una versión de mercado en el momento oportuno. Esto se llama fusión.

La estrategia de desarrollo del proveedor debe ser ahora (al menos en nuestra opinión) conciliar en la medida de lo posible todas las diferentes necesidades de los distintos clientes mediante la búsqueda de soluciones genéricas. Estas soluciones, de aplicación general, pueden configurarse de forma específica para el cliente con el fin de tener en cuenta su situación concreta. Aquí es donde encontramos por primera vez el término "configurable".

Con esta estrategia de desarrollo, naturalmente también hay que llegar a compromisos en determinadas situaciones, por ejemplo, implementando deliberadamente sólo una de las diversas variantes de la solución para una misma necesidad del cliente, que entonces puede no configurarse en absoluto o sólo de forma limitada. En este caso, el proveedor de software tiene que aceptar que no podrá satisfacer a todos los clientes para poder seguir su estrategia de forma coherente. Así, todos los clientes se beneficiarán de las ventajas. Volveremos a hablar de ello al final de este artículo.

La configurabilidad está en la base de datos, no en el código fuente

Pasemos ahora al concepto central de este texto: Configurabilidad. Otros también hablan aquí de parametrización o términos similares. La configurabilidad de una solución estándar puede explicarse como sigue.

En el caso de una aplicación empresarial con una arquitectura común de tres niveles, una instalación de software típica consta de un servidor de aplicaciones (nivel intermedio) y un servidor de bases de datos (nivel inferior). El usuario accede al servidor de aplicaciones a través de un cliente (nivel superior, en el caso de una aplicación web es el navegador). En la base de datos del sistema se pueden almacenar ajustes(valores de configuración) que controlan el comportamiento del sistema. Sin embargo, el servidor de aplicaciones se basa en una versión específica. Sin embargo, los usuarios notan diferentes funcionalidades o comportamientos del sistema, dependiendo de cómo esté configurado.

El punto crucial es el siguiente: los valores de configuración mencionados están en la base de datos (como mucho en archivos de configuración en el servidor de aplicaciones), pero nunca como parte del código fuente en el servidor de aplicaciones. Por lo tanto, la configuración real no tiene nada que ver con el desarrollo posterior o la adaptación del código fuente específicos del cliente. Esto daría lugar a una desagradable ramificación, que pondría en peligro o incluso haría imposible la capacidad de liberación. Esto es precisamente lo que hace que el desarrollo posterior sea costoso para el cliente, ya que estos desarrollos posteriores tienen que hacerse por separado para cada cliente y el cliente individual no puede beneficiarse de un desarrollo posterior global para todos los clientes.

Por lo tanto, la configurabilidad no significa, en particular, que las adaptaciones se realicen programando el código fuente. La adaptación del código fuente tiene lugar siempre y exclusivamente mediante el desarrollo genérico de las funcionalidades básicas del software estándar y da lugar a una nueva versión. Las configuraciones existentes pueden adoptarse simplemente en la nueva versión. Se trata de la capacidad de liberación de sistemas de software estándar configurables o ya configurados.

¿Cómo se reconoce el software configurable?

Esta pregunta no es tan fácil de responder desde la perspectiva externa, es decir, desde la perspectiva del cliente que quiere evaluar y comprar dicho software. Desde el punto de vista interno del desarrollador, por supuesto, esto es fácil. Sin embargo, en el proceso de venta, se puede presentar al cliente un software que en realidad no es configurable en absoluto (en el sentido definido anteriormente) como "configurable", que no merece en absoluto esta etiqueta.

Una solución de este tipo puede llamarse, con razón, software estándar, ya que se desarrolla a lo largo de una única vía de lanzamiento. Pero no se construyó desde el principio con una estrategia de desarrollo que implementara las funcionalidades de forma genérica y las hiciera adaptables mediante la configuración. La "configurabilidad" de estos sistemas se implementa de forma efectiva a través del desarrollo posterior. Por supuesto, esto no se vende al cliente de esta manera.

Algunas características sencillas del software (verdaderamente) configurable son las siguientes:

• Una configuración específica para el cliente es rentable porque implica poco esfuerzo de implementación para el proveedor.
• La configuración puede aplicarse rápidamente en términos de tiempo (con la misma justificación).
• El sistema sigue estando listo para su lanzamiento en todo momento, es decir, las actualizaciones a futuras versiones no cuestan nada, ni dinero ni esfuerzo.

En el caso de PQFORCE, por ejemplo, una configuración por parte del cliente (de todo el sistema, eso sí) supone un esfuerzo aproximado de ½ a 2 días, dependiendo de los deseos específicos y del alcance de los detalles. Y cuando ofrecemos una nueva versión, se puede instalar fácilmente para cada cliente sin ningún esfuerzo.

poll/110626]

Las ventajas del software estándar configurable desde la nube

Por último, nos gustaría enumerar las ventajas más importantes del software estándar configurable desde la nube en comparación con el software individual. Programas como PQFORCE...

• ...es significativamente más barato de adquirir. Y no estamos hablando de porcentajes, sino de factores. Simplemente porque no hay que financiar ningún proyecto de desarrollo costoso. Y la capacidad de configuración permite incluso una adaptación específica para el cliente a un coste extremadamente bajo, para todos aquellos clientes que no quieren conformarse con la solución lista para usar.
• ...está listo para su uso en muy poco tiempo después de la compra. La configuración de un cliente PQFORCE lleva unos minutos (¡sic!), por lo que la operación piloto puede comenzar inmediatamente. En este caso, la disposición de la organización del cliente es más bien el factor de frenado.
• ...permite aprovechar las economías de escala. El desarrollo posterior es impulsado(crowdsourcing) y financiado(crowdfunding) por toda una cartera de clientes.
• ...ofrece innovaciones periódicas (lanzamientos de características) en ciclos cortos de unas pocas semanas, que pueden ser iniciados por los clientes y utilizados inmediatamente en cuanto están disponibles(principio DevOps).

Así que no es de extrañar que hoy la tendencia se dirija claramente hacia el software estándar basado en la nube. Si además es realmente configurable, entonces usted como cliente tiene todas las ventajas de su lado.