Siguiendo con las entregas de antipatrones veamos los pertenecientes a la segunda categoría:
Arquitectura de Software. Parte 1
Autogenerated Stovepipe
Esto ocurre cuando trasladamos el diseño de un sistema existente hacia una arquitectura distribuida manteniendola igual. Es evidente que un sistema distribuido debe estar especialmente diseñado para tal caso, por ejemplo la transferencia de información puede llegar a ser mas costosa que si trabajaras un arquitectura puramente local.
Esas son cosas a tener en cuenta y se debe rediseñar el sistema para tal forma.
Stovepipe enterprise
Se refiere a lo que llaman islas de automatización en una empresa y tienen un diseño independiente y único que no permite interoperabilidad ni comunicación adecuada de los procesos en todos niveles. Esta falta de uniformidad restringe la interacción, reuso y eleva los costos. Terminología incompatible, sistemas monolíticos, imposibilidad de extender, aumento de costo en mantenimiento, rotacion y sobrecarga de horarios en empleados son algunas consecuencias.
Solucionable con una buena coordinación de tecnologías, la elección de
estándares a través de modelos de referencia, establecer un entorno operativo común que coordine la selección de productos y
perfiles de sistema para el uso de dichos productos. La clave con grandes sistemas es definir las convenciones de
interoperabilidad mientras se abordan los requerimientos y estrategias tecnológicas.
Jumble(Revoltura)
El software contiene lo que se denomina elementos verticales y horizontales. Los elementos horizontales son aquellos que tienen que ver con cosas que se pueden usar en varias aplicaciones, por ejemplo sistema de seguridad, logging, transacciones y persistencia. Los elementos verticales aquellos que son específicos de un tipo aplicación, por ejemplo, de recursos humanos o inventario.
Este antipatron aparece cuando esos elementos empiezan a mezclarse haciendo la arquitectura poco flexible e
inestable. La solución es identificar los elementos horizontales y separarlos en sus respectivas capas y módulos.
Cover your assets (Cubrir los bienes )
Este tiene que ver con los procesos del software basados en la documentación, osea los requerimientos y especificaciones. Se produce cuando los autores evaden importantes decisiones por el miedo a cometer errores. Se van por una vía mas segura y el resultado son enormes y enigmáticos documentos sin ninguna abstracción útil para los lectores, que generalmente son los desarrolladores. Sin decisiones y prioridades un documento tiene un valor limitado.
La solución es poner en practica una arquitectura de esquemas o blueprints(planos). Los blueprints son un conjunto de diagramas
y tablas que comunican la arquitectura operacional y técnica del sistema.
Vendor Lock-In (Bloqueo del vendedor)
Se produce en sistemas que son muy dependientes de arquitecturas propietarias o una linea de productos en particular.
Por experiencia sabemos que esto puede traer un sin numero de problemas desde interoperabilidad hasta mal funcionamiento
del mismo sistema cuando se hacen actualizaciones. La solución ideal es hacer un aislamiento de capas para lograr independencia,
seguir los estándares de la industria seria una muy buena idea.
Wolf ticket (Billete lobo)
Este ocurre cuando un producto declara ser compatible con estándares de la industria. Estos productos poseen interfaces
propietarias que pueden variar de lo especificado en la norma o estándar. Generalmente un estándar favorece mas a los proveedores
por el reconocimiento a su marca y beneficia menos a los usuarios ya que las especificaciones podrían ser demasiado flexibles
o muy complejas causando poca interoperabilidad y portabilidad.
