La complejidad no es sencilla: múltiples causas de fracaso de IT

por Peter Kretzman

Peter mantiene un blog “CTO/CIO Perspectives” que como dice en su descripción, presenta tips intensamente prácticos para la gestión de IT. Estuve leyendo su entrada; “La complejidad no es sencilla: múltiples causas de fracaso en IT” y me pareció un enfoque interesante para compartir.

A continuación un extracto de la entrada de Peter;

Roger Sessions ha publicado recientemente un White Paper sobre la complejidad de IT y su papel en el fracaso de los proyectos de IT: «La crisis de complejidad de IT: peligro y oportunidad«. Es ciertamente posible pelearse con su análisis, y por lo tanto modificar sus números, pero la tendencia general sigue siendo innegable: las fallas de IT del mundo están costando cantidades increíbles de dinero real. Sessions incluso lo resume en la frase de terrible sonido «la crisis viene de IT» y dice, «la proliferación fuera de control de los fracasos de IT es una realidad futura de la que ningún país o empresa es inmune» y presenta «pruebas convincentes de que la proliferación de las fallas de IT es causada por la creciente complejidad de IT«. Señala que el costo en dólares de las fallas de IT, sólo en los EE.UU., se aproxima al costo de la crisis financiera reciente de EE.UU. y cita indicios de que la tasa de fracaso también aumenta en un 15% por año.

El papel de Roger es excelente y provoca la reflexión, lo recomiendo altamente. Estoy de acuerdo con su opinión de que la complejidad es el principal culpable de los fracasos de IT. Dicho esto, creo que sus argumentos se centran un poco demasiado en una de las causas de la complejidad (sobre complejidad innecesaria de la arquitectura), en detrimento de otros factores importantes.

Por encima de todo, sin embargo, discrepo con el enfoque de Roger sobre la racionalización de la arquitectura como la clave para reducir la complejidad del sistema. Se podría decir, de hecho, que la solución de Roger es ante todo una técnica, cuando los Bugaboos que veo son fundamentalmente culturales y sociológicos. No veo a uno, pero por lo menos tres distintas cargas que supone la complejidad, cada vez más endémico, y cada vez más derribando a IT:

* Diseño / Arquitectura excesivamente complejo
* Tomando demasiada funcionalidad
* Una deficiente implementación (deuda técnica en lo grande y pequeño)

Roger ha tratado admirablemente la cuestión del diseño / arquitectura excesivamente complejo, al menos en términos de un enfoque viable para la simplificación de la arquitectura, así que voy a concentrarme ahora en los otros dos.

Tomando demasiada funcionalidad

Recientemente alquilé un automóvil económico (la opción menos cara) en un viaje con mi hijo. (Recuerde, mi auto-denominación es «Cheap (barato) Technology Officer.») Él se quedó atónito y consternado de que el coche no tienen cerraduras de puertas automáticas. Del mismo modo, mi hija de 11 años de edad, ha crecido en un mundo TiVo industrializado donde la televisión en vivo siempre se puede detener. Cuando se encuentra con una TV sin un DVR (y por tanto sin capacidad de pausa), se considera irremediablemente primitiva. De hecho, como inaceptable.

Del mismo modo, la norma general para la funcionalidad y el diseño de la interfaz de usuario ha sido planteada por software para PC muy funcional. Ahora esperan poder hacer doble clic sobre un número en cualquier informe en pantalla, y así «profundizar» en los detalles de transacciones que componen este número. Cuando no puedo, me siento engañado. Del mismo modo, espero que todo en una interfaz sea arrastrar y soltar, me siento frustrado si no lo hace.

Así como la industria, hemos elevado el nivel de aceptabilidad considerablemente, en software y sistemas de tecnología en el último par de décadas. Lo que eso significa en términos prácticos, sin embargo, nuestros ojos se han hecho más grandes que nuestros estómagos. Queremos más, por adelantado, que a menudo tiene sentido construir desde el principio. Y nuestras demandas no son negociables, o eso parece. Uno de los primeros teléfonos celulares que tuve ni siquiera tenía un silenciador del sonido, yo solía silenciar el teléfono con la habilidad de desconectar la batería cuando llegaba una llamada en un momento inoportuno. Hoy en día, la mayoría de la gente ni siquiera consideraría comprar un teléfono que no tiene características mucho más elaboradas, tales como una cámara.

Así que nuestro incremento en las expectativas, solo, ha incrementado considerablemente la funcionalidad de los sistemas que se tienden a construir. Hay más funcionalidad en sí mismo, y por lo general más puntos de interfaz a otros sistemas complejos. De hecho, las pruebas de integración, donde se conecta el nuevo código en un entorno de trabajo donde tiene que tener una interfaz correcta con otros sistemas, se ha convertido en un punto frecuente e importante para el lanzamiento de proyectos de tecnología de la información. En esencia, hemos caído en el dilema de las «nueces«, tanto en formas grandes y pequeñas. Queremos tanto, y tratamos tanto, que hemos aumentado el riesgo de fracaso considerablemente.

Deuda técnica (en lo grande y en lo pequeño)

Cualquier desarrollador de software le dirá que su primer intento en la aplicación de una pieza dada de funcionalidad es a menudo (si no es por lo general) mucho más complejo de lo que resulta ser necesario. Sólo después de explorar el dominio del problema, con los experimentos y dar marcha atrás y reiniciar, los desarrolladores no suelen darse cuenta que su código puede ser reducido, simplificado, combinado con otros módulos, etc Esto se llama normalmente «refactoring», y su importancia es un relativamente reciente conocimiento en la disciplina de desarrollo de software.

Una de las claves acerca de refactorización, sin embargo, es que significa mejorar el código sin tener que cambiar sus resultados globales. No hay a menudo repago inmediato evidente de este enfoque. En la medida en que la no se realiza refactorización (ni tiempo, ni inclinación, ni el reconocimiento de un enfoque más simple), el producto final se queda con los vestigios de una complejidad innecesaria. Cuanto mayor es la escasez de tiempo, y mayor es la aspiración a la profundidad y el alcance funcional del software inicial, lo más probable es que estos vestigios perduren. Y uno de los aspectos accesorios de la creciente espera de funcionalidad mínima es que causa que la escasez de tiempo sea cada vez mayor. Ya no se trata de ofrecer sólo una solución que funcione, se trata de asegurarse de que la solución incluye (metafóricamente hablando) una cámara de 5 mega píxeles también.

Emparejando esta complejidad innecesaria, sino accidental con lo que a menudo equivale a un trabajo urgente en el diseño para el bien del calendario de reuniones (la creación de «deuda técnica en lo grande»). Un ejemplo que he usado antes aquí: la elección de un núcleo DBMS diferente para implementar una función determinada, simplemente por conveniencia, y no tener tiempo para modificar la funcionalidad anterior al uso del DBMS nuevo. Soportar dos DBMS dentro de un mismo producto representa la deuda técnica importante: cada cambio posterior en el sistema además supondrá «el pago de intereses» en la que la deuda, no sólo aumenta la programación y los costos de mano de obra, sino también aumenta el riesgo de fracaso. Y eso es sólo un ejemplo, las cascadas de la deuda técnica, función a función, release a release. La deuda técnica, hasta que no sea pagada, se puede equiparar a un sustrato invisible en el aumento de la complejidad, y que contribuye enormemente a un sistema cada vez más tambaleante, arriesgado. Y últimamente, veo más y más organizaciones aumentando su deuda técnica, no teniendo nunca el tiempo y costo para pagarla, con resultados desastrosos. Como Hemingway dijo acerca de ir a la quiebra, ocurre lentamente, a continuación toda a la vez.

¿Y ahora qué?

El análisis de Roger, a su gran crédito, se refirió a un aspecto importante de la complejidad y que plantean una solución (un enfoque que él llama SIP, o Particiones Simples Iterativas). Los aspectos que estoy presentando (tomando demasiada funcionalidad, y la pirámide de la deuda técnica) son, como he dicho, cultural y sociológico en las empresas. La respuesta no es tan simple o tan limpia como una solución técnica específica (aunque estoy seguro de que recibiré comentarios de esta entrada, tal vez con razón, de los devotos de Agile).

En mi opinión, el liderazgo comprometido, inteligente y fuerte es el único que puede abordar estos temas, frenar el tren de la demanda, detener la locura. En todo caso, creo que hay una creciente falta de liderazgo en los círculos de IT que convenientemente puede reconocer y abordar estos factores, así como educar a sus pares. Y eso es lo que necesita solucionar la mayoría.