Blog de Fernando Machado Piriz

Artículos sobre transformación digital, arquitectura empresarial y temas relacionados

Toda empresa es una empresa de software, y toda empresa de software puede ser un proveedor de servicios

with one comment

El software está en todos lados. Excepto tal vez en los negocios como los carritos de chorizos de calle, todos los negocios funcionan en base a software. Y el carrito de chorizos es una excepción si y sólo si no acepta pagos con tarjeta de crédito, o no utiliza algún servicio en línea para pedir las materias primas con las que prepara después los chorizos. Al fin y al cabo, cada empresa es una empresa de software, ya sea que sólo consuma software, o que desarrolle y consuma software a la vez.

Para aquellas empresas que hacen desarrollo de software en la propia empresa y luego usan ese software para gestionar su negocio, incluso si es sólo una parte del total de software que utilizan, el tradicional ciclo de vida de desarrollo de software podría no ser apropiado en algunas circunstancias, como lo veremos en un minuto.

Y para aquellas empresas cuyo negocio es el desarrollo de software para que otras empresas o individuos consuman, el tradicional ciclo de vida de desarrollo de software podría no ser apropiado tampoco.

Por tradicional ciclo de vida de desarrollo de software me refiero al proceso que crea un producto de software al final. No me importa si se trata de desarrollo en cascada o ágil, lo único que me importa es que un producto de software es creado como resultado de ese proceso. Tiene las siguientes características:

  • Muchas características. La diferenciación de los productos se basa en tener tantas características como sea posible para un público tan amplio como sea posible. Los productos raramente están dirigidos a funciones o necesidades específicas del cliente.
  • MTTF o tiempo medio entre fallas. Al igual que con los productos manufacturados tradicionales, su objetivo principal es el tiempo medio entre fallas: los productos son mejores si tienen pocas fallas.
  • Cadencia de actualización lenta. Las actualizaciones de productos de software son relativamente poco comunes; pueden ser a través de parches para corregir errores, a través de paquetes de servicio para agregar nueva funcionalidad, o por medio de versiones completamente nuevas. El tiempo de desarrollo de productos de software suele ser largo, seguido por período de garantía de mantenimiento, y luego de un descanso antes de empezar todo de nuevo.
  • Hábitos de consumo desconocidos. Una vez que los productos son liberados, es difícil saber cómo son consumidos por los usuarios, y tomar decisiones en base a los patrones de uso.
  • Dentro del calendario, dentro del presupuesto. La prioridad más importante es liberar productos a tiempo y dentro del presupuesto.

Además, como ocurre con los productos fabricados tradicionales, la confiabilidad es percibida desde la perspectiva de cada unidad individual. Proporcionar confiabilidad requiere control de calidad dentro del proceso de producción. Cuando los usuarios experimentan problemas con los productos, por lo general están dispuestos a esperar hasta el horario de oficina para reportar su problema. Un problema raramente impacta más de una persona a la vez. Y por lo general está claro para los usuarios cuando los problemas se deben a problemas en el producto de software, en lugar de problemas en el entorno en el que el software está ejecutando.

Pero cualquiera de estos negocios podría verse afectados por la transformación actual de las demandas de software:

  • Su empresa desarrolla una aplicación de software para móviles, puede ser una aplicación de línea de negocio en el mundo de las empresas, o puede ser otra aplicación de software de propósito específico del mercado de aplicaciones en el mundo de los consumidores. En el segundo caso, la mayoría de estas aplicaciones por lo menos almacena algunos datos o hace algún tipo de procesamiento en un servidor remoto, lo que las pone en el mismo grupo que las que están en el primer caso: aplicaciones móviles que consumen servicios remotos.
  • Su empresa hace negocio electrónico con otras empresas, puede ser exponiendo los procesos internos a través de software donde otros pueden participar, o utilizando aplicaciones de software para el intercambio de información con el fin de completar una transacción. De una forma u otra están proporcionando servicios basados en software, o consumiéndolos; probablemente ambos.

¿Notaron la palabra software al principio de las dos frases anteriores y la palabra servicio al final? No es casualidad –yo lo escribí de esa manera- pero eso es lo que estamos viendo y vamos a ver en un futuro próximo: aplicaciones de software móviles que consumen algún tipo de servicio remoto y servicios basados en software siendo expuestos para que otros puedan consumirlos.

Si siente que cualquiera de las dos categorías antes mencionadas son aplicables a su empresa, ya sea creando software para su propio consumo, o si está en el negocios de desarrollo de software para que otros utilicen, y todavía está desarrollando software como productos, ¿adivine qué? Usted no está desarrollando software, usted está proporcionando servicios. Los llamo proveedores de servicios basados en software. Y eso es una cuestión completamente diferente, ¿quiere saber por qué? Veamos:

  • Confiabilidad y agilidad en vez de más características. La diferenciación de los servicios se basa en las capacidades de alta confiabilidad que se ajustan a un conjunto específico de necesidades del mercado. Los servicios más eficaces y efectivos ponen la confiabilidad y la agilidad por encima de la candiad de características.
  • MTTR o tiempo medio de resolución. Al igual que con los servicios públicos tradicionales, su foco está en el tiempo medio de recuperación: las interrupciones van a ocurrir, por lo que los servicios son mejores cuando más rápido estén funcionando de nuevo.
  • Actualizaciones continuas, desarrollo continuo. Las actualizaciones de software son continuas; podrían libear nuevas funciones o nuevas versiones enteras con mucha frecuencia, y corregir los errores todos los días. El desarrollo de software para servicios suele ser continuo; puede ser que haya ciclos de liberación, pero por lo general esos ciclos son muy cortos.
  • Patrones detallados de uso. Por lo general es posible recopilar cantidades enormes y muy precisas de datos sobre el uso del servicio, lo que permite tomar mejores decisiones.
  • Siempre funcionando, a costos adecuados. La prioridad más importante es tener el servicio en funcionamiento, manteniendo el costo de operación apropiado.

Además, como ocurre con los servicios públicos tradicionales, la confiabilidad es una función de todo el sistema. Proporcionar confiabilidad requiere monitoreo proactivo en tiempo real del comportamiento de cada componente del sistema. Cuando los usuarios sufren interrupciones del servicio, el impacto es mucho más amplio, un problema impactar una amplia gama de clientes. La respuesta no puede esperar al horario de oficina. El soporte tiene que estar disponible 24x7x365. Los usuarios no se preocupan dónde están los problemas cuando se producen cortes en el servicio. Puede ser que estén en el software en el que se basada el servicio, o en el centro de datos, o en la red, o en cualquiera de los componentes dependientes.

¿Su fábrica de software no puede seguir el ritmo de las solicitudes de cambio y no tiene suficiente agilidad para acompañar a transformación de su negocio? ¿Tiene requisitos contradictorios de diferentes unidades de negocio o diferentes grupos de usuarios? ¿No puede encontrar una buena manera de organizar sus equipos de operaciones de software y de desarrollo de software? ¿Quiere saber una cosa?… su fábrica de software probablemente no está organizada como tiene que ser organizado un proveedor de servicios.

Las fábricas de software se organizan en torno a los productos de software, mientras que los proveedores de servicios se organizan en torno a los servicios. ¿Y todavía se preguntan por su fábrica no funciona?

La organización de los equipos alrededor de los productos significa dos cosas. Uno: que muy probablemente tenga un equipo para cada producto, algunos de los miembros podrán ser compartidos entre los equipos, pero los equipos trabajan para un sólo producto. Y dos: que muy probablemente tenga una segregación de tareas dentro de los equipos: analista de negocios, arquitectos, diseñadores, desarrolladores, probadores, y hasta operadores si ejecuta su propio software. ¿Un producto utiliza otros? Por supuesto, excepto si tiene pedazo gigante de software monolítico, en cuyo caso usted está peor que el resto de nosotros, y tiene problemas más urgentes e importantes que resolver. Cada una de las funciones de un equipo de producto que he mencionado antes, trabaja para su propio producto. Los equipos de un producto realmente no se preocupan por otros los productos que utilizan los suyos y ciertamente no controlan los demás productos que ellos consumen. Y la transición desde desarrollo hasta operaciones se parece a desarrolladores que lanzan algo sobre el muro para que la tomen los operadores… ¿a quién le importa lo que sucede en el otro lado? Invariblemente hay una venganza, los operadores siempre pueden enviar solicitudes de corrección de errores hacia los desarrolladores.

La organización de equipos alrededor de los servicios, significa que un equipo de servicio tiene todo lo que necesita para ofrecer el servicio y cumplir con el acuerdo de nivel de servicio. No hay muros. El dueño del servicio, analistas de negocio, desarrolladores, probadores y operadores se sienta juntos por adelantado para definir cómo lucirán en el futuro el servicio en sí y el proceso de desarrollo del servicio, de extremo a extremo. Radical, ¿no? Sí, pero es lo que necesita. Un operador diciéndole a un desarrollador de software qué tipo de despliegue automatizado, monitoreo y capacidades de telemetría necesitará para operar el servicio. Estos son requisitos no funcionales y los arquitectos y desarrolladores de software están acostumbrados a tratar con este tipo de requerimientos. Un probador diciéndole a un desarrollador de software la manera en la que debe diseñar el software para que él o ella pueda probarlo de forma eficaz y eficiente. Estos son requisitos no funcionales también. Un arquitecto de software o desarrollador diciéndole al dueño del servicio lo que se puede o no se puede construir en un momento dado y las restricciones de recursos y presupuesto. Parece una locura, pero estos ejemplos son tan sólo requerimientos del negocio, el propietario del servicio está acostumbrado a tratar con ellos durante la definición del servicio.

Si piensa que los servicios están sólo en la capa externa en contacto con el mundo exterior, está equivocado. El mismo concepto se puede utilizar en las capas internas, en lo que me gusta llamar como arquitectura empresarial orientada a servicios. No es lo mismo que la arquitectura orientada a servicios simple y llana, donde los servicios de aplicación eran la piedra angular. Estoy hablando de servicios de negocio, servicios de aplicaciones y servicios de infraestructura, todos organizados de la misma manera, confiando uno en uno a través de acuerdos de nivel de operación bien definidos desde el lado de los consumidores de servicios, y de acuerdos de nivel de servicio como parte de una clara definición de servicio desde el lado del proveedor de servicios.

Las empresas de software más grandes (bueno, depende de su definición de grande) son de hecho proveedores de servicios basados en software (Microsoft, Google, Amazon, Facebook, Twitter, WhatsUp, Apple, y así sucesivamente). Su empresa podría no ser tan grande como éstas, pero si se trata de un proveedor de servicios basado en software, es posible que tenga más cosas en común con ellos de lo que usted piensa. De alguna manera u otra, todos ellos se organizan detrás de los servicios que proporcionan. ¿Por qué no habría de hacerlo usted?

Written by fernandomachadopiriz

20/11/2014 a 09:58

Una respuesta

Subscribe to comments with RSS.

  1. Excelente contenido con información relevante.
    Un saludo!
    Emiliano

    empresa para desarrollo en software

    20/04/2015 at 23:40


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: