"De comprar a construir"
Teki Cloud Blog Team
Published 17 Dic 2020Ver mas publicaciones
Learn about everything from AI & machine learning to productivity & collaboration
ver más
En nuestros artículos anteriores hemos hablado sobre los factores y los argumentos más comunes ala hora de "comprar" o "construir", nombramos una reglas básicas que pueden servir de manera general para las empresas, etc. Ahora, en este artículo queremos poner una situación hipotética de lo que podría llegar a pasar cuando las empresas inicialmente compran un software preestablecido pero luego deben adaptar y personalizar dicho software para que se ajuste al entorno de la empresa.
Cabe resaltar que es un pequeño ejemplo de una de las miles de posibilidades de lo que podríapasar, en el mundo de TI cualquier cosa puede ocurrir y cada empresa actual de manera diferente,pero este ejemplo es un poco común dentro de varias organizaciones y queremos contarte que pasa en esta situación y como se puede pasar fácilmente de comprar a construir de manera errónea.
El comienzo de toda empresa en su viaje de TI Instancias
La mayoría de las empresas inician en los campos de TI comprando software y como lo hemos dicho antes, esto tiene en un principio tiene sentido porque le permite a la organización beneficiarse de la experiencia de los vendedores y de las economías de escala y necesitan aprender de la experiencia de empresas con más recorrido en el campo tecnológico. Claramente las empresas compran más de un software y después de comprar varios de estos paquetes de software comercial tienen un panorama de TI con varios software preestablecidos con sistemas independientes que al inicio no tienen conexión y no han tenido ningún cambio.
Sin embargo, dichos sistemas no permanecen en su estado inicial por mucho tiempo, las empresas personalizan rutinariamente el software que compran, inicialmente a través de configuraciones provistas por el proveedor, luego las empresas empiezan a personalizar dependiendo sus necesidades y empiezan a crear conexiones entre los diferentes sistemas. Es muy común que se lleve a un entorno que esté totalmente integrado y personalizado según los requerimientos de la empresa.
Una vez se haya realizado la personalización y la integración inicial de los diferentes software en la empresa, este proceso nunca se detiene porque los niveles de integración y personalización tienden a aumentar todo el tiempo, y esto puede causar dos antipatrones de TI:
Antipatrón IBAR
El primer antipatrón se llama IBAR y es el resultado de una integración excesiva, también conocida como la "bola de pelo gigante" o, más técnicamente, como IBAR, "Integrated Beyond All Recognition". Esta especie de arquitectura lamentablemente, hace que cambiar o reemplazar los sistemas sea casi imposible debido al excesivo acoplamiento e interdependencias entre los sistemas ya existentes de manera que hace que los sistemas iniciales sean irreconocibles, podríamos decir que sería el extremo de integración.
Antipatrón CBAR
El segundo antipatrón se llama CBAR, técnicamente conocido como "Customized Beyond All Recognition", es diferente en naturaleza al IBAR pero igualmente nefasto. Ocurre cuando la personalización lentamente se hace cargo del paquete de software comprado, que queremos decir con eso, en este caso es cuando la personalización se lleva al extremo de manera que pueden ocurrir bloqueos, fallos y la fragilidad del sistema se ve afectada.
Los dos anti-patrones no son excluyentes, en realidad puede ocurrir que las empresas caigan en una combinación de ambos. Lamentablemente, este escenario no es tan raro como debería ser, pero deberíamos pensar como hacen las grandes empresas para desviarse de caer en esta condición. El comprender los mecanismos de la empresa y de los software no sólo puede ayudar a evitar el desastre, también puede darnos valiosos consejos sobre cómo podemos salir del agujero en caso de que ya estemos dentro de algunos de estos antipatrones.
La causa principal de la excesiva personalización e integración es a menudo un desajuste entre el software que se compró y el modelo operativo de tu empresa. Aunque se espera y se planifica cierta personalización en el diseño del producto comercial, hay casos en los que se puede sospechar que se está construyendo su propio software sobre un paquete de software comercial, en ese momento es importante replantear su estrategia.
Una visualización de cómo una empresa puede pensar en la TI
La mejor manera de visualizar cualquier posible desajuste entre los paquetes de software y la forma en que piensas en tu TI es trazar los principales bloques de tu entorno de TI sin tener en cuenta los paquetes de software ya existentes. Un ejemplo podría ser: el bloque de página web, el bloque de una aplicación móvil y el bloque de interfaces API para clientes externos, etc.
El siguiente paso crítico es comparar esta vista con los paquetes de software que se compraron. Una vez más, para simplificar este ejemplo, supongamos que están operando tres paquetes de software comercial importantes para esta parte de su empresa, digamos que compro un software CRM, ERP y un software para la tienda web.
Un ejemplo de lo que podrías concluir al momento de hacer la comparación podría ser que las API de terceros no están cubiertas, los límites de los paquetes no se alinean con los límites de la capacidad, las capacidades básicas están cubierta por los tres paquetes, etc. Aqui sería necesario realizar cambios.
Pero, si las cosas encajan bien, no será necesario que construyas nada por ti mismo. El desarrollo de un panorama de capacidades y su asignación a paquetes de software comercial no es algo que se pueda pedir a los proveedores de software ya que su motivación esta en asegurar que su producto se vea perfecto. Por lo tanto, este es un ejercicio interno y debería ser el pan de cada día para tu departamento de arquitectura empresarial.
Al momento de identificar un desajuste te deja dos opciones:
Puedes ajustar tu modelo operativo a los paquetes de softwarePuedes ajustar tu modelo operativo a los paquetes de softwarePuedes ajustar tu modelo operativo a los paquetes de softwarePuedes ajustar tu modelo operativo a los paquetes de softwarePuedes ajustar tu modelo operativo a los paquetes de software
Puedes ajustar el paisaje del software para que se ajuste mejor a tu modelo de funcionamiento
La primera opción no es tan insignificante como parece ya que, si necesitas ajustar tu modelo operativo a paquetes de software que se encuentran alojados en la nube, obtendrías el máximo provecho de la computación en nube si ajustas tus procesos existentes. Sin embargo, si tu modelo operativo está relacionado con el éxito de tu empresa, te convendría retroceder y analizar que hace que tu empresa tener éxito y asegurarte que cuentas con la TI adecuada para ajustar ese paisaje de software a tu modelo de funcionamiento.