Blog de Fernando Machado Piriz

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

Archive for the ‘Arquitectura’ Category

Las bases de la transformación digital: “todo definido por software” y “todos programan”

leave a comment »

Parece haber un acuerdo acerca que la transformación digital se trata menos de tecnología y más sobre diseño del negocio y sobre cultura centrada en el cliente. Obviamente no se trata de tecnología digital: los DVD, como su propio nombre lo indica, son contenedores de películas digitales en lugar de cintas de vídeo analógicas o películas en celuloide, pero no fue hasta que Netflix añadió video a demanda a través de Internet al negocio de entrega física de DVD, que se convirtió en una referencia en transformación digital.

Como George Westerman et al. han puesto claramente en este libro -o en este artículo que lo resume-, es la intensidad de la gestión transformacional, es decir, cuánto están apostando los altos directivos a la transformación digital, lo que separa los “digiratis” -maestros digitales- del resto de los mortales. Sin embargo, las empresas todavía necesitan pensar en las bases para la transformación digital, y precisamente allí es donde las plataformas digitales tienen su lugar; dicho de otra forma, una plataforma digital no hará transformar digitalmente una compañía, pero una compañía no puede transformarse sin una plataforma digital.

¿Qué son esas plataformas digitales? Son lo que hace que pueda funcionar sin fricción un negocio que involucra a los titulares de la empresa y sus socios, y que a su vez permite que la empresa participe en otros negocios “para [que la organización pueda] ejecutar su estrategia de negocio digital”, según Gartner.

Hace un tiempo las computadoras eran una cosa física; ahora existe la virtualización de hardware por software y en consecuencia tenemos máquinas virtuales. También hace un tiempo teníamos matrices de discos duros, y ahora tenemos almacenamiento definido por software; teníamos cables físicamente conectados, enrutadores, cortafuegos, etc. y ahora tenemos redes definidas por software; y la lista continúa hacia cosas muy grandes como los centros de cómputo definidos por software o hacia cosas muy pequeñas como los chips definidos por software o, más precisamente, matrices de puertas lógicas programables en terreno.

Incluso los dispositivos IoT, que son comunes en muchas empresas que se transforman digitalmente, pueden cambiar sus comportamiento basados en el software que ejecutan; cuanto menos inteligente sea el dispositivo, mayor será la duración de su batería, pero menor será su capacidad de ejecutar software sofisticado, o incluso ejecutar software a secas; pero conecte el dispositivo a la nube a través de una puerta de enlace para IoT, y entonces tendrá también su IoT definido por software.

Estas plataformas digitales tienen otra característica interesante: para lograr agilidad y facilidad de adaptación, no sólo permiten cambios sino que los alientan, haciendo que sean más fáciles. Las reglas [de negocio] que controlan el comportamiento de las aplicaciones que se ejecutan en estas plataformas pueden ser cambiadas de forma declarativa -a diferencia de imperativas o algorítmicas-, eventualmente a través de una interfaz de usuario gráfica manejada por algún usuario de negocio, no por un programador. Es declarativo, pero sigue dando órdenes a una computadora para hacer algo, así que sigue siendo programación.

Los usuarios finales que hacen las pruebas de aceptación no necesariamente usan la aplicación en sí para ver si funciona como debería. Probablemente no lo hagan lo suficientemente rápido y probablemente no estén dispuestos a hacerlo tantas veces como sea necesario para poder entregar nuevas versiones de la aplicación cada día o varias veces al día. Entonces la única manera es pedirles que declarativamente especifiquen cómo hacer las pruebas, en lugar de hacer las pruebas por sí mismos. Una vez más, es declarativo, pero sigue siendo programación.

Entonces resulta que tenemos usuarios finales codificando, ya sea adaptando aplicaciones que se ejecutan en plataformas digital para hacer cosas diferentes o incluso cosas nuevas, o ya sea para asegurarse que las aplicaciones funcionan como quieren, pero también hay más gente programando: los operadores de las plataformas.

Los operadores suelen escribir scripts para realizar tareas repetitivas. Alguien me dijo alguna vez “cuando quieras que la computadora haga algo, ejecuta los comandos; cuando quieras que haga lo mismo de nuevo, piensa en escribir un script y luego ejecuta los comandos; cuando quieras que haga lo mismo por tercera vez, escribe un script que ejecute los comandos por ti”. Es más rápido ejecutar el script que escribir los comandos, pero todavía más importante, los scripts no se equivocan: una vez que funcionan, no se olvidan de ejecutar algún comando ni cometen los errores que las personas cometemos cuando estamos cansados, apurados, o estresados por una fecha de entrega.

Y los programadores siempre programaron, entonces ahora todo el mundo programa.

Eso es lo que implica desde un punto de vista personal una plataforma de transformación digital: “todo definido por software” y “todo el mundo programa”. De nuevo, una plataforma no va a hacer que su organización se transforme digitalmente, pero es muy poco probable que pueda transformarse sin una. Me considero afortunado de haber estudiado ciencias de la computación y por haber programado alguna vez; me facilita entender y poder explicar a mis clientes como Microsoft Digital Advisor este fundamento de la transformación digital.

Anuncios

Written by fernandomachadopiriz

24/03/2017 at 22:16

Agile Architecture Workshop por Martín Salías

leave a comment »

Mi amigo Martín va a estar en Montevideo el 26 y 27 de mayo con un taller de arquitectura ágil que les recomiendo. Más detalles en la página del evento.

Written by fernandomachadopiriz

17/05/2015 at 12:56

Publicado en Anuncios, Arquitectura

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 at 09:58