La Casa Winchester, en San José, California, es famosa por «estar maldita, embrujada». Efectos paranormales aparte, es famosa, también, por su tamaño, sus curiosidades arquitectónicas y su falta de un plan maestro de construcción.
Según parece, la casa estuvo en constante construcción durante 38 años. No se recurrió a un arquitecto y se amplió el edificio de forma desordenada. Se contrató a distintos grupos de obreros que convirtieron la casa en una mansión de siete plantas con 160 habitaciones -40 de ellas dormitorios-, 467 puertas, 47 hogares, 17 chimeneas y más de 10.000 cristales, entre otros…
La casa contiene rarezas como puertas o escaleras que no van a ninguna parte, ventanas que dan a otras habitaciones o que son ciegas, puertas de distintos tamaños, escaleras con pasamanos heterogéneos y una gran variedad de colores y materiales, entre otros…
Muchas organizaciones pueden parecerse a la Casa Winchester, con su estructura y forma tecnológica surgiendo sin un proyecto general ni integridad arquitectónica. El resultado son definiciones de datos diferentes, distintas fuentes de la verdad, silos de información, lógicas de negocio incoherentes o duplicadas, múltiples soluciones alternativas, sinergias no realizadas, redundancia, reinvención en lugar de reutilización y una miríada de tecnologías diferentes, a veces incompatibles, entre otros…
La arquitectura empresarial trata de establecer un proyecto para el modelo operativo de una organización. Su origen suele presentarse como una disciplina técnica, pues surgió como respuesta al reconocimiento en las TIC de la necesidad de contar con un plan o arquitectura general para crear sistemas de información, pero no lo es, o al menos no lo es totalmente.
Al diseñar cualquier estructura hay que tener en cuenta la perspectiva empresarial. Por eso, los arquitectos debemos insistir en que se nos dé contexto, no solo una retahíla de requerimientos, para poder hacer nuestra labor.
Y en cuanto a requerimientos, «con la Iglesia hemos topado»…
- muchas veces no responden al «Qué «, sino que se dicta directamente el «Cómo».
- están contaminados por una visión particular de un usuario y no de empresa.
- no contemplan los procesos de negocio, de manera que el analista desconoce esa perspectiva fundamental, creándose una zona oscura de conocimiento.
- no contienen el ADN de los buenos requerimientos.
- no contemplan el uso de estructuras de especificación de requerimientos.
El trabajo de un arquitecto es un eslabón más en la cadena de producción de proyectos TIC, eslabón que depende de una etapa previa y fundamental, la toma de requerimientos, tarea que realiza el analista de negocio y a la que, en muchas ocasiones, no le prestamos la importancia que tiene.
Facilitemos la labor de los arquitectos desde las bases, no vomitando requerimientos, sino desde una perspectiva más empresarial:
- explicitando preocupaciones, problemas o necesidades del negocio a subsanar.
- declarando explícitamente visión, objetivos y necesidades.
- enunciando las relaciones con otras iniciativas empresariales.
- formulando casos de uso.