7 síntomas de una mala arquitectura de TI y 4 consejos



identifica-signos-mala-arquitectura-software-TI-colombia-consultoria

¿Crees contar con una mala arquitectura TI? En nuestra búsqueda de implementar las mejores soluciones en las organizaciones estamos constantemente creando mejoras que pueden ser aplicadas en las compañías para tener una sólida arquitectura de TI.

Hoy queremos compartir lo que hemos identificado basados en nuestra experiencia y el de algunos otros especialistas en el tema. Te podría interesar Una Arquitectura Orientada a Servicios podría potenciar tus recursos TI

Una buena arquitectura de TI mantiene viva la estrategia de tecnología de las empresas; su ‘buena implementación’ potenciará tus resultados hasta un 100% del cumplimiento de objetivos. Por ello, antes que nada, y poniéndote un poco en contexto, aunque ya lo sepas, queremos que tengas clara qué es la arquitectura de software.

La arquitectura de software es el conjunto de elementos que hacen parte de algún sistema, su estructura y cómo estos interactúan con cada uno de ellos. Para incluirla dentro de las organizaciones se recomienda aplicar metodologías de desarrollo.

Sin embargo, en ocasiones, en algunos momentos de planeación de esta arquitectura TI se han podido presentar situaciones: mala gestión, políticas internas, recursos, entre otros; lo que han dejado una estrategia de implementación un poco coja. ¿Crees que tu organización cuenta con algunos problemas de arquitectura TI? Puedes identificarlo aquí.

Señales de alerta de una mala arquitectura de TI

1.      Aplicaciones redundantes

Las aplicaciones empresariales resuelven problemas empresariales, lo que es bueno, ¿cierto? Pero resolverlos más de una vez debería ser aún mejor ¿o no? Bueno, pues no lo es y aun así muchas empresas mantienen muchas aplicaciones redundantes.

Ya sea que estas se superpongan, aún no son lo suficientemente buenas para integrar a todos en el negocio. Estas herramientas aisladas aumentan los gastos y seguir con ellas es puro desperdicio.

El impacto que tiene en la arquitectura TI impulsa la necesidad de tener interfaces del sistema y aún más una cantidad de plataformas que deberían ser compatibles con otras. ¿Por qué no apostarle a una que integre todo, o en su mayoría de las necesidades de negocio?

Por otro lado, la empresa se ve afectada al tener estas aplicaciones al eliminar los recursos de TI en actividades que generan valor y desperdician dinero en licencias de software que no aportan nuevas funcionalidades al negocio, por lo que en ocasiones pueden crear la necesidad de un rekeying manual.

2.      Demasiadas interfaces

Cuando tienes datos redundantes y quieres mantenerlos sincronizados, debes crear interfaces. Entre más sistemas y bases de datos tengas, por obvias razones terminarás teniendo demasiadas interfaces. Y aunque sea mejor que no tenerlos, estos se acumulan y la arquitectura TI se va volviendo frágil y será más difícil mantenerla. En realidad, ocuparás tu tiempo administrándolas que creando nuevas funcionalidades.

Así, la creación de interfaces regularmente elimina los recursos de TI de las actividades que crean valor en la organización.

3.      Tecnología obsoleta

A considerar, tener tu arquitectura TI y todos tus sistemas obsoletos, es una de los síntomas más importantes y decisivos de tener una mala arquitectura. Es crítico adquirir herramientas que no se integren y no operen bajo lenguajes de programación actuales. Por lo que, una de dos, hay que gastar dinero para estar actualizándolo por terceros constantemente o para mantenerlo.

De todas formas, tener tecnología obsoleta es la manera más obvia, pues más anticuados sean, más difícil será mantener e interactuar con nuevos sistemas y/o equipos. Por lo que aumenta los costos y aumenta su incapacidad para adaptar los sistemas al mercado cambiante.

4.      Re-keying manual:

Si bien no es uno de los mayores costos que pagan las empresas por una mala arquitectura, es otra de las más cuestionables. La modificación manual de data podría es una de las alertas más identificables en la arquitectura TI cuando algo le va mal. En la actualidad, contratar colaboradores y/o personal que hagan las veces de motor de interfaz para conectar aplicaciones incompatibles no es solamente caro, es inhumano.

Tener esta ‘señal’ impacta de 2 formas las empresas, en la arquitectura y en el negocio directo: en el primero, los errores de codificación nos dan información inexacta e inconsistente. En el segundo, la reintroducción manual aleja los recursos empresariales en las actividades que generan valor.

5.      Data redundante

En ocasiones, diversas aplicaciones requieren hacer uso de la misma información para ejecutar sus tareas.

Aquí tenemos 2 opciones: dirigirlos hacia una misma base de datos subyacente; lo que no siempre es posible, y la segunda: sincronizar las bases de datos separadas, que puede ser algo caótico. No obstante, es algo que no aconsejamos, teniendo en cuenta nuestro primer aspecto, es que se introduzca manualmente es otra opción.

Las unidades de información repetida requieren la interfaz del sistema y en ocasiones crean la necesidad de introducirla manualmente. Mantener la sincronización de datos en múltiples bases de datos es complejo, lo que nos lleva a tener esfuerzos vanos en las actividades de conciliación y obtener respuestas erróneas en la función de la base de datos que se consulta.

6.      ¿Arquitectura de imitación ‘Faux-Elegant’?

En nuestra búsqueda de algunos otros síntomas de una mala arquitectura TI, encontramos un artículo de CIO que nos trae la información sobre la ‘Arquitectura Faux-Elegant’, el cual nos llama la atención por lo que destacaremos este punto dentro de nuestro artículo. Te lo dejaremos debajo para que puedas consultarlo.

Resumiendo un poco, son plataformas que hacen que la solución de los problemas fáciles, sean aún más fáciles, pero no resuelven problemas difíciles en absoluto.

Entonces, tu equipo TI quiere resolver problemas de interfaz con falsos-elegantes sistemas de integración de aplicaciones empresariales, o un bus de servicios, o de cualquier forma de middleware-plus-metadata que mantenga todo en orden.

Por lo que plataformas novedosas, están integradas en una arquitectura que se ‘vende’ para proporcionar una solución a problemas complejos; aprovechando tareas simples que ya estaban siendo abordadas adecuadamente por las ‘soluciones no elegantes’.

Por eso las integraciones elegantes son frágiles y complicadas de mantener, al igual que contar con un exceso de interfaces; además de restar recursos de TI en las actividades de valor, lo que lo hace también costoso.

7.      Soluciones alternativas, rápidas y torpes

Al hablar de tecnología todo puede ser maravilloso y la diversidad plataformas existentes que pueden verse como la panacea de la organización, nos pueden dejar impactados de todo lo que pueden hacer.

Tantos precios y funcionalidades o desarrolladores que te entregan tu proyecto en tiempos locamente cortos y mucho más. Te hacen adquirir un Kludge, esas plataformas a precios bajos… que al final vienen siendo de dudosa efectividad. Puede sonar exagerado, pero esos ofrecimientos y características solo pueden generar sistemas pegados con chicle y cinta adhesiva.

Estos Kludges son ineficientes, rápidos y torpes, resuelven problemas inmediatamente, pero crean sistemas frágiles. El costo de mantenerlos aumenta con cada solución innecesaria al igual que su inactividad, la capacitación del personal y lo complejo que se volvería comenzar nuevos proyectos.

Ahora que has identificado algunas señales de una mala arquitectura TI, te traemos algunos consejos para mantener óptimos tus sistemas.

Consejos para una buena arquitectura de TI

Como sabes, la arquitectura suele depender de las necesidades y objetivos de la empresa, ya que pueden ser muy rígidas o flexibles a diferentes proyectos. Un diseño limpio de tus sistemas pueden ser claves para estrategias que generen valor.

He aquí unos cortos, pero claros consejos:

  1. Elige las herramientas que considere tu equipo de TI para mantener optimizados tus procesos. En lo posible unificando servicios de automatización de sistemas, integración de aplicaciones que desde su inicio sean claves en la estrategia de tu organización.
  2. Procura establecer sistemas robustos libres de frameworks, que te permitirá una estructura estable e independiente.
  3. Mantén un ambiente en el cual el código pueda ser evaluado, medido y regulado
  4. Ajusta tus bases de datos a las necesidades del negocio y no al revés, alinea su construcción y el uso de esta.