Este es un viaje en un tren imaginario que emprendemos juntos, tú, lector, y yo. La intención es simple: conversar, explorar y disfrutar de una ventana de experiencias tecnológicas que puedo compartir contigo. No se trata de una competencia, una clasificación ni nada aburrido. Mi deseo es que disfrutes esta ventana, que encuentres en ella algo útil o que compartamos el placer de un recuerdo, ya sea completo o en parte.
Aquí disponéis del legado completo de Prometeo en 👉🏻 Amazon
EXPLORA EL LEGADO ↓
LA VANGUARDIA | DIRECTORIO ÚNICO| SECE | BYTEMASTER | IDESK | CNAT | SPLASHTOP | GCO | LINEA DIRECTA | IBERDROLA
En este espacio, deseo comenzar con los proyectos más significativos y de mayor impacto en mi vida; una especie de sencillo escaparate de lo más destacado. Pero, más allá de eso, viviremos la precuela de casi cuatro décadas de proyectos IT, que espero les traiga buenos recuerdos durante este apasionante y, sobre todo, cómodo viaje en tren.
Ahora que miro hacia atrás y empiezo a comprender cuál ha sido mi legado profesional, hay algo que tengo todavía más claro: sin la gente, no habría habido legado.
Las tecnologías cambiaron. Novell dio paso a Windows NT. NT a Active Directory. Llegaron Citrix, VMware, Cloud, Azure, la identidad y la ciberseguridad. Pero detrás de cada arquitectura siempre hubo alguien que confió en mí, alguien que me enseñó algo, alguien que discutió una solución conmigo, alguien que me abrió una puerta o, sencillamente, alguien que estuvo allí cuando había que conseguir que aquello funcionara.
Los proyectos pueden llevar mi firma. Los recuerdos llevan muchos nombres.
Y cuanto mayor me parece hoy lo que construimos, más agradecido me siento hacia toda la gente que hizo posible que pudiera construirlo.
TOP 10 PROYECTOS Y LEGADO PROFESIONAL.
Bienvenidos a mis diez proyectos preferidos y legado profesional derivado de ellos. Representan diez momentos en los que tuve que pensar, decidir, diseñar, construir o resolver algo que terminó cambiando mi manera de entender la tecnología.
Por tanto, aquellos que más cabeza y corazón puse.
Pero dime, lector: ¿qué demonios es lo realmente importante para ti?
Debido al linfoma no Hodgkin que padecí en 2017, y tras avisarme los médicos de los efectos de la quimio, no he podido tener descendencia, aunque quizá una parte de ella esté escrita bajo estas líneas.
No dejo de preguntármelo para no convertir estas páginas en un vano ejercicio de soberbia destinado a alimentar ese maltrecho ego humano que, como la gasolina, conviene utilizar con bastante prudencia. Por este motivo, estos no son necesariamente mis diez proyectos más grandes, ni los más caros, ni los más complejos.
Aquí no encontrarás una colección de medallas. Nunca llegaron. Encontrarás problemas reales, arquitecturas reales, decisiones técnicas, documentación, errores, soluciones y resultados. Desde aquellos primeros sistemas Microsoft hasta Citrix, virtualización, identidad digital, teletrabajo, Digital Workplace y ciberseguridad.
Treinta años después, he elegido estos diez porque, juntos, explican mucho mejor mi carrera que cualquier currículum.
No pretendo decirte que fueron importantes. Prefiero enseñártelos: decide tú.
01 – LA VANGUARDIA: CUANDO EL TELETRABAJO DEJÓ DE SER UNA OPCIÓN
Marzo de 2020 · Grupo Godó / La Vanguardia · Citrix · VMware · NetScaler · Ciberseguridad · Continuidad de negocio
Era marzo de 2020. La COVID-19 acababa de cambiar las reglas del juego y miles de empresas descubrían, prácticamente de un día para otro, que el teletrabajo había dejado de ser una opción. Sin vacunas todavía en el horizonte y con un país entrando en confinamiento, mantener a las personas alejadas de sus centros de trabajo era una cuestión de salud; mantenerlas conectadas era ya una cuestión de continuidad de negocio.
Yo, Francisco Javier Vilá Costa, estaba precisamente en Consultes Externes de Hematología de MútuaTerrassa cuando recibí la llamada de Sergi Aguilar Malgrat, CEO de IDGRUP.
La situación era crítica. La Vanguardia necesitaba pasar al teletrabajo durante la COVID-19 y necesitaba hacerlo inmediatamente.
No estábamos hablando de preparar un proyecto para los meses siguientes. Había que proporcionar a sus profesionales acceso remoto seguro a los sistemas y aplicaciones corporativas, con una plataforma de teletrabajo redundante y preparada para producción, y había que conseguirlo en cuestión de días. El objetivo era tan sencillo de explicar como extraordinariamente complejo de ejecutar:
La Vanguardia tenía que poder trabajar remotamente durante aquel mismo fin de semana para que el periódico pudiera seguir funcionando y su edición en papel estuviera en la calle el lunes siguiente.
Ese fue mi cometido.
Diseñar y poner en producción, junto con IDGRUP, la arquitectura tecnológica que permitió realizar aquel salto al teletrabajo de La Vanguardia en marzo de 2020, utilizando una infraestructura basada en Citrix Virtual Apps and Desktops, Citrix NetScaler y VMware, con alta disponibilidad y acceso remoto seguro. No había una segunda oportunidad. El lunes tenía que haber periódico.
Acepté el reto.
Diseñé una arquitectura completa aprovechando la infraestructura VMware resiliente y en alta disponibilidad existente en el proveedor de hosting. Preparé el proyecto, la documentación técnica, el presupuesto y el calendario de ejecución. Con acceso VPN, delegación controlada sobre Active Directory y acceso a VMware vCenter, construí la plataforma por capas:
Infraestructura → Management → VDA → Master Template → Citrix Virtual Apps and Desktops 1912 LTSR → Acceso seguro → Clúster Citrix NetScaler.
La solución no debía limitarse a permitir que alguien trabajara desde casa. La Vanguardia es un medio de comunicación. Había que contemplar comunicaciones de audio y vídeo, Microsoft Teams y conexiones con televisiones y otros interlocutores repartidos por todo el planeta, trabajando bajo condiciones de latencia muy diferentes. Por eso incorporé también políticas de optimización de comunicaciones, rendimiento y ciberseguridad, aprovechando las capacidades de Citrix Virtual Apps and Desktops 1912 LTSR y una capa de acceso exterior protegida mediante un clúster redundante de Citrix NetScaler.
Todo ello se diseñó y desplegó contrarreloj, en uno de los momentos de mayor incertidumbre tecnológica y social que hemos vivido. Y lo conseguimos. La plataforma estuvo disponible. La gente pudo trabajar. Y La Vanguardia en versión papel también pudo salir ese lunes.
Para mí, este proyecto representa mucho más que una arquitectura Citrix. Resume buena parte de lo que entiendo por ingeniería: experiencia, responsabilidad, resiliencia, seguridad y capacidad para tomar decisiones cuando el tiempo deja de ser una variable y se convierte en el principal requisito del proyecto.
LEGADO | La Vanguardia fue el momento en que todo lo aprendido durante años tuvo que funcionar de verdad y sin red. En pleno inicio del COVID-19, convertí en días una infraestructura corporativa en una plataforma de teletrabajo basada en Citrix, VMware, NetScaler, comunicaciones y seguridad. No había margen para teorías ni retrasos: el lunes el periódico tenía que salir. Y salió. Para mí, ese es el legado: cuando llegó una crisis real, la arquitectura respondió.
02 — GENERALITAT DE CATALUNYA · CTTI : DISEÑANDO EL DIRECTORIO ÚNICO: IDENTIDAD, SEGURIDAD Y UNA NUEVA FORMA DE TRABAJAR
2021 · Generalitat de Catalunya / CTTI · Inetum · Active Directory · Azure AD · Microsoft 365 · ADFS · PKI · PIM · LAPS · Defender for Identity · Ciberseguridad
INICIO:
En 2021 participé en uno de los proyectos de arquitectura de identidad más ambiciosos de mi trayectoria profesional: la consultoría para la evolución hacia un Directorio Activo Único del CTTI, dentro del Pla Director de la Generalitat de Catalunya. Pero el reto iba mucho más allá de consolidar dominios de Microsoft Active Directory.
Había que estudiar el escenario existente —AS IS—, definir el modelo futuro —TO BE— y convertir esa transformación en un ROADMAP tecnológico ejecutable, alineando arquitectura, identidad, seguridad, aplicaciones, comunicaciones, movilidad, dispositivos y servicios Cloud.
Nuestra propuesta, cuya decisión técnica defendí personalmente, apostaba por la creación de un nuevo bosque de Active Directory, diseñado desde cero para facilitar la consolidación de los entornos existentes, reducir riesgos y permitir implantar desde su nacimiento un nuevo modelo de seguridad.
Y alrededor de ese nuevo núcleo de identidad había que diseñar prácticamente todo: Nuevo bosque AD → migración de identidades → ADFS → Azure AD / AD Connect → Microsoft 365 → Exchange híbrido → modelo de privilegios → PIM → PAW → LAPS → Defender for Identity → Conditional Access → Identity Protection → PKI.
El ROADMAP convirtió aquella arquitectura en bloques reales de implantación: construcción del nuevo Directorio Único, migración de Active Directory, transición de Exchange hacia Microsoft 365, aplicaciones y federación mediante ADFS, nuevo modelo de seguridad y despliegue de una infraestructura PKI. Pero probablemente lo más importante del proyecto no era la tecnología. Era comprender que la identidad estaba dejando de ser simplemente el lugar donde almacenábamos usuarios y contraseñas para convertirse en uno de los principales perímetros de seguridad de toda la organización.
El proyecto planteaba administración privilegiada por capas, estaciones seguras de administración PAW, gestión de administradores locales mediante LAPS, gestión de privilegios mediante PIM, auditoría y detección mediante Microsoft Defender for Identity, acceso condicional y protección de identidades.
Todo ello perseguía además un objetivo superior dentro del Pla Director: permitir una nueva forma de trabajar basada en movilidad, colaboración, gestión integral del dispositivo, teletrabajo e identidad única, manteniendo seguridad, sostenibilidad y nivel de servicio.
CUANDO UN ENTREGABLE SE CONVIERTE EN EL PROYECTO :
Mi responsabilidad tenía, además, otra dimensión. Antes de que cientos de técnicos pudieran ejecutar aquella transformación, alguien tenía que convertirla en un plan que pudiera ejecutarse. El resultado fueron los entregables que definían arquitectura, metodología, fases, dependencias, recursos, cronogramas y planificación. El ROADMAP principal alcanzó las 148 páginas y el propio control documental me identifica, junto con Xavier Alonso y Jorge García, como elaborador, revisor y aprobador de su versión 4.0, fechada el 18 de junio de 2021.
Aquello tenía una trascendencia que iba mucho más allá de entregar documentación a un cliente. De ese trabajo dependía buena parte de lo que vendría después.
Implantaciones. Migraciones. Seguridad. Identidad. Cloud. Horas de ingeniería. Y el trabajo posterior de numerosos profesionales de una compañía que acababa de iniciar una nueva etapa bajo el nombre de Inetum, alrededor de uno de sus grandes clientes de referencia de la Administración Pública catalana. En cierta manera, aquellos documentos se convertían también en conocimiento corporativo, metodología y fondo de comercio. Y existe una última parte de esta historia que también forma parte de mi trayectoria.
Después de cuatro documentos y de aquella responsabilidad, no recibí reconocimiento alguno por el trabajo realizado. Ni siquiera unas gracias. Con el paso del tiempo, eso ha dejado de ser lo importante. Porque el reconocimiento no cambia la arquitectura, no modifica los documentos y tampoco altera lo que ocurrió después.
El trabajo quedó hecho.
Y para mí este proyecto representa el momento en que muchas de las disciplinas que habían acompañado toda mi carrera —Microsoft, sistemas, redes, Active Directory, Cloud y seguridad— dejaron definitivamente de ser piezas independientes para convertirse en una sola arquitectura:
LA IDENTIDAD.
Después del proyecto de La Vanguardia en marzo de 2020, considero este el segundo gran proyecto de mi vida profesional. No por sus 148 páginas y sus tres TFC (trabajos de final de carrera) de entregables perfectos. No por la cantidad de tecnologías implicadas. Sino porque pocas veces he tenido sobre mi mesa algo con una consecuencia profesional tan grande: Diseñar hoy el camino tecnológico por el que mañana tendrán que caminar cientos de profesionales.
LEGADO | AD Únic representa el momento en que dejé de ver Active Directory como un directorio para empezar a verlo como el perímetro de seguridad de toda una organización. Convertí una transformación enorme del CTTI en arquitectura y, sobre todo, en un ROADMAP ejecutable: nuevo bosque, identidad única, Cloud, privilegios, seguridad y migración. Mi legado fue dejar documentado el camino para que cientos de técnicos pudieran continuar construyendo después de mí. Para mí, después de La Vanguardia, uno de los mayores proyectos de mi carrera.
Tuve de colaboradores a Xavier Alonso i Aural y Jorge Garcia Dorado.
03 – SECE · SOCIEDAD ESPAÑOLA DE CONSTRUCCIONES ELÉCTRICAS: SEIS AÑOS CONSTRUYENDO UNA RED QUE CRECÍA CONMIGO
2000–2006 · Meinsa Sistemas · Windows NT 4.0 · Active Directory · Citrix · Cisco · RDSI · VPN · SonicWall · Ciberseguridad
Hay clientes para los que trabajas. Y hay clientes que, sin darte cuenta, terminan formando parte de tu propia carrera. SECE fue eso para mí. Llegué al proyecto en el año 2000 a través de Meinsa Sistemas. Técnicamente, mi interlocutor principal era Joan Pagès i Rosas, que con los años acabaría convirtiéndose no solamente en un enorme cliente, sino también en un gran amigo.
SECE fue durante seis años mi laboratorio, mi escuela, mi sueño y, en muchos sentidos, mi familia profesional. Allí hice carrera.
Cuando llegué, la compañía estaba terminando de abandonar su pasado Novell NetWare. Poco más adelante se realizó la migración hacia Windows NT Server 4.0, que fue la que me encontré como Ingeniero de Sistemas.
La arquitectura respondía todavía a una concepción muy propia de aquellos años: servidores y dominios distribuidos por delegaciones, redes locales bastante independientes y unas telecomunicaciones que hoy parecen arqueología informática. Y algunas lo eran casi literalmente. Recuerdo encontrarme EICON DIVA instaladas en servidores de dominio utilizando RAS and Routing para establecer comunicaciones con la central y recuperar información. Aquello funcionaba.
Pero yo quería que funcionara de otra manera.
DE MUCHAS REDES A UNA SOLA RED
Mi primera gran transformación fue ayudar a cambiar completamente el concepto. En lugar de mantener una colección de pequeños dominios independientes asociados a las delegaciones, Joan diseñó un modelo basado en un dominio NT central de SECE y delegaciones comunicadas mediante una infraestructura WAN. Empecé a configurar y desplegar routers Cisco 701 mediante RDSI y a transformar progresivamente los antiguos servidores de dominio de las delegaciones. Los datos seguían estando cerca de los usuarios cuando era necesario, pero aquellos equipos dejaban de constituir pequeñas islas administrativas: pasaban a ser servidores miembro dependientes de una identidad y una administración centralizadas.
SECE continuó creciendo. Y la red creció con ella. Acabaría desplegando esta arquitectura en más de veinte delegaciones, aprendiendo algo que después marcaría buena parte de mi carrera: centralizar no significa necesariamente concentrarlo todo físicamente; significa conseguir que todo forme parte de una misma arquitectura.
Y ENTONCES LLEGÓ ACTIVE DIRECTORY
La aparición de Windows 2000 Server y Active Directory volvió a cambiar las reglas. Y volvimos a cambiar SECE. El antiguo dominio NT dejó paso a un verdadero servicio de directorio. Empecé a trabajar intensamente con Active Directory, unidades organizativas, delegación administrativa y Group Policy Objects —GPO—. Ya no se trataba simplemente de conectar ordenadores. Se trataba de gestionar identidades, equipos, políticas y recursos desde un único modelo lógico. Sin saberlo entonces, estaba entrando en la disciplina que décadas después acabaríamos llamando Identity Management y que terminaría convirtiéndose en uno de los ejes fundamentales de mi carrera.
CITRIX: HACER PEQUEÑA LA DISTANCIA
Pero quedaba otro problema. Las aplicaciones. Las delegaciones necesitaban utilizar las mismas aplicaciones corporativas, mantenerse actualizadas y hacerlo sobre conexiones cuyo ancho de banda resultaría hoy casi inconcebible. Y ahí entró definitivamente en mi vida Citrix. La ejecución centralizada de aplicaciones permitió que las delegaciones trabajaran sobre una plataforma común sin necesidad de transportar constantemente aplicaciones y enormes cantidades de datos a través de aquellos enlaces. Citrix consiguió algo que entonces parecía casi magia: hacer que una aplicación situada a cientos de kilómetros pareciera estar al otro lado de la mesa.
Y allí también hice uno de mis particulares másteres de campo.
Impresión remota. Universal Printing. UniPrint. PDF Distiller. Drivers. Colas. Sesiones. Y aquellos inolvidables pantallazos azules provocados por algún driver de impresora con pocas ganas de colaborar: IRQL_NOT_LESS_OR_EQUAL. No había Stack Overflow, IA generativa ni un botón mágico. Había que entender qué demonios estaba pasando.
DE RDSI A VPN
La arquitectura volvió a evolucionar. Las comunicaciones mediante RDSI y aquellos Cisco fueron dejando paso a una VPN corporativa proporcionada por Jazztel. Servidores, datos y aplicaciones fueron progresivamente concentrándose y profesionalizándose. La infraestructura que había comenzado como una colección de redes locales conectadas de manera rudimentaria se estaba convirtiendo en una verdadera red corporativa distribuida.
Y con esa conectividad apareció inevitablemente el siguiente problema: la seguridad.
Hacia el final de mi etapa incorporé tecnologías SonicWall, construyendo una nueva capa de protección perimetral y obteniendo también certificación sobre la tecnología. El recorrido había sido enorme: Novell NetWare → Windows NT 4.0 multidominio → NT dominio central → Cisco + RDSI → Migración a Windows 2000 → Active Directory + GPO → Citrix → VPN corporativa → SonicWall.
Seis años. Y prácticamente una generación completa de la informática empresarial.
EL PROYECTO EN EL QUE HICE CARRERA
Para mí SECE nunca fue una cifra. Fueron personas. Fue Joan Pagès. Fueron delegaciones que se abrían y había que conectar. Fueron noches buscando por qué una impresora conseguía tumbar un servidor Citrix. Fueron routers, módems, servidores, dominios, políticas, aplicaciones y firewalls. Y fue, sobre todo, la sensación de estar construyendo algo que crecía mientras yo también crecía profesionalmente.
Llegué incluso a soñar con incorporarme como Director Técnico de la compañía. No ocurrió. Cuando Joan Pagès dejó aquella etapa y la dirección técnica tomó otro camino, comprendí que también había llegado el momento de buscar el mío.
En 2006 dejé Meinsa Sistemas y me incorporé a Bytemaster. Pero me llevé algo mucho más importante que un cargo. Me llevé seis años en los que aprendí que un arquitecto no aparece cuando alguien le pone Architect en una tarjeta.
Se convierte en arquitecto cuando deja de ver servidores, routers, aplicaciones y usuarios por separado y empieza a ver el sistema completo.
SECE fue el lugar donde, para mí, ocurrió exactamente eso.
LEGADO | SECE fue donde aprendí a hacer crecer una arquitectura junto al negocio. Pasé de dominios NT4 aislados y delegaciones conectadas por RDSI a Active Directory, GPO, Citrix, VPN, datacenter y seguridad, acompañando una expansión de más de veinte delegaciones. Pero mi verdadero legado no fue tecnológico: allí hice carrera, aprendí el negocio y entendí que detrás de cada servidor, cada red y cada aplicación siempre hay personas que dependen de que todo funcione. Allí empecé a convertirme en arquitecto.
04 – BYTEMASTER: CUANDO EL CLOUD TODAVÍA NO SE LLAMABA CLOUD
2006–2008 · Responsable IT · Microsoft Gold Partner · Citrix Gold Partner · Citrix Presentation Server · Active Directory · Exchange 2003 · SQL Server · Informix · Cisco PIX · VPN · Datacenter · Teletrabajo
Llegué a Bytemaster en 2006, después de seis años en SECE, y allí ocurrió algo que acabaría condicionando buena parte del resto de mi carrera. Implosionó definitivamente en mí la idea del teletrabajo.
Años antes me había fascinado aquel anuncio de Retevisión de las 500 miles: la posibilidad de trabajar independientemente de dónde estuvieras. En Bytemaster dejé de verlo como una idea futurista. Empecé a construirlo.
La compañía había nacido alrededor de cuatro programadores con buenas ideas y había desarrollado un modelo de negocio que, visto desde hoy, resulta especialmente interesante. En 2006 todavía no hablábamos continuamente de Cloud Computing y la virtualización masiva de servidores aún no se había impuesto. Sin embargo, el concepto de Bytemaster ya consistía esencialmente en sacar infraestructura informática de las instalaciones de sus clientes y concentrarla en datacenters, proporcionando desde allí aplicaciones, datos, comunicaciones y servicios.
Era, en esencia, un Application Service Provider —ASP—. Y aquello me fascinó.
TREINTA Y CINCO EMPRESAS. UN DATACENTER.
La infraestructura estaba alojada en racks y datacenters de COLT Telecom. Allí convivían el core de comunicaciones, switches de capa 3, VPN mediante Cisco PIX, servidores de bases de datos en clúster, Microsoft SQL Server, servidores IBM Informix, Microsoft Exchange y las plataformas necesarias para proporcionar aplicaciones y escritorios remotos a los clientes.
Y entonces entraba una parte fundamental de mi responsabilidad. Citrix.
Existían granjas Citrix MetaFrame XP FR3 y durante mi etapa desplegué la evolución hacia Citrix Presentation Server 4. El objetivo era tremendamente moderno para 2006: que los usuarios no necesitaran tener delante sus servidores ni necesariamente sus aplicaciones para poder trabajar.
Las aplicaciones estaban en el datacenter. Los datos estaban en el datacenter. La identidad estaba en el datacenter. Los escritorios podían ejecutarse en el datacenter. El usuario estaba donde tuviera que estar.
Sin llamarlo todavía así, aquello contenía buena parte de los principios que años después acabaríamos asociando al Cloud Computing y al Digital Workspace.
UN ACTIVE DIRECTORY MULTITENANT ANTES DE HABLAR DE MULTITENANCY
Probablemente una de las responsabilidades técnicamente más interesantes que asumí fue la gestión de la identidad. Los aproximadamente 30–35 clientes de la compañía dependían de una infraestructura centralizada.
En lugar de mantener un bosque independiente para cada organización, administrábamos un único bosque de Active Directory, estructurado mediante unidades organizativas que separaban lógica y administrativamente los diferentes clientes. Era una especie de multitenancy construida sobre Active Directory.
Dentro de aquel bosque existía el dominio ASP, alrededor del cual se proporcionaban las aplicaciones y escritorios Citrix. Existía además otro dominio, ISP, utilizado dentro de la arquitectura de servicios de Internet y correo, con Exchange 2003 formando parte de aquel ecosistema.
Desde una misma infraestructura teníamos que proporcionar: Identidad → Datos → Aplicaciones → Escritorios → Bases de datos → Correo → Comunicaciones → Impresión. A decenas de empresas diferentes.
HASTA LAS IMPRESORAS VIVÍAN EN INTERNET
La impresión remota volvió a enseñarme que las arquitecturas aparentemente elegantes terminan enfrentándose siempre al mundo real. Hubo incluso soluciones donde las comunicaciones permitían realizar NAT hacia TCP/9100 para alcanzar impresoras situadas en las instalaciones remotas de los clientes mediante direccionamiento público.
Puede sonar extraño visto desde la arquitectura actual. En aquel momento había que conseguir que funcionara. Y funcionaba. Eso también era ingeniería.
MI UNIVERSIDAD DE LA RESILIENCIA
Pero Bytemaster me enseñó otra cosa todavía más importante: qué ocurre cuando centralizas absolutamente todo.
Si treinta o treinta y cinco empresas dependen de tu infraestructura para autenticarse, consultar sus datos, ejecutar aplicaciones, acceder a sus escritorios, utilizar bases de datos, correo e incluso imprimir, el datacenter deja de ser simplemente infraestructura. Se convierte en el negocio de tus clientes.
Y entonces descubres el verdadero significado de una palabra que posteriormente utilizaría miles de veces: RESILIENCIA.
Porque aquella infraestructura tenía puntos donde la disponibilidad no estaba diseñada todavía como hoy consideraríamos imprescindible. Cuando fallaba un caudal de comunicaciones, no se caía solamente una línea. Podían dejar de trabajar empresas enteras.
Y cuando eres Responsable IT, eso significa guardias, llamadas nocturnas, incidencias, presión y alguna que otra conversación que probablemente no figuraba en ningún manual de Microsoft ni de Citrix. No siempre recibí precisamente buenas maneras cuando algo fallaba. Pero con los años he terminado viendo incluso aquello de otra manera.
PROMETEO EMPEZABA A TENER CAPA
Bytemaster fue una universidad extraordinariamente exigente. Allí comprendí que centralizar servicios sin diseñar resiliencia significa centralizar también el riesgo. Aprendí que una arquitectura no termina cuando funciona. Tiene que sobrevivir cuando algo deja de funcionar.
Aprendí que identidad, comunicaciones, seguridad, aplicaciones y datos no podían diseñarse como mundos independientes. Y aprendí, sobre todo, que si queríamos permitir que alguien pudiera trabajar desde cualquier lugar, primero teníamos que conseguir que pudiera hacerlo de manera segura, disponible y transparente.
Sin saberlo, allí empezaba a ponerme la capa de lo que muchos años después acabaría llamando mi particular Prometeo del teletrabajo ciberseguro.
No guardo rencor por las noches, la presión ni las malas formas que alguna vez acompañaron aquella etapa. Con la distancia suficiente incluso puedo estar agradecido. Porque pocas empresas me enseñaron tanto sobre resiliencia como aquella. Y además tuve el privilegio de aprenderlo en 2006, cuando muchas de las cosas que hoy damos por hechas todavía estaban empezando a escribirse.
APOSTILLA : CUANDO EL DATO DEJA DE ESTAR EN TU CASA
Bytemaster me hizo comprender además algo que acabaría siendo fundamental muchos años después: qué significa realmente que una empresa confíe sus datos y su capacidad de trabajar a un tercero.
Cuando sacas los servidores de un cliente de sus instalaciones y te llevas a tu datacenter su identidad, aplicaciones, bases de datos y documentos, ya no estás simplemente alojando máquinas. Estás asumiendo la custodia del dato: su propiedad, su integridad, su disponibilidad, su seguridad y, sobre todo, la responsabilidad de protegerlo. Aquello me hizo entender muy pronto que externalizar la infraestructura jamás significaba externalizar la responsabilidad.
También descubrí entonces otro problema que años después la industria resolvería de una manera mucho más elegante: el licenciamiento. Nosotros ya imaginábamos servicios donde el cliente no comprara necesariamente toda la tecnología, sino que pudiera consumirla y pagarla mientras la utilizaba. El problema era que las licencias tradicionales de muchos fabricantes no estaban concebidas para ser compradas por un proveedor y posteriormente «alquiladas» a terceros de cualquier manera. La tecnología permitía hacerlo; los modelos contractuales y comerciales no siempre acompañaban.
Bytemaster tenía una ventaja extraordinaria: sus fundadores eran programadores y disponían de software propio y, por tanto, de licencias cuya propiedad y explotación podían controlar directamente. Eso les proporcionaba una libertad comercial que yo no tenía. Llegué a plantearme crear una iniciativa similar, porque el modelo me parecía evidente, pero me faltaba precisamente aquella pieza: programadores y propiedad intelectual sobre el software que debía convertirse en servicio.
Años después normalizamos conceptos como suscripción, Software as a Service y pago por uso. Para mí, sin embargo, aquella idea empezó mucho antes, viendo cómo treinta y tantas empresas trabajaban con aplicaciones, datos e infraestructura que físicamente ya no estaban en sus oficinas.
Fue otra de las grandes lecciones de Bytemaster: el Cloud no empezó cuando aprendimos a poner servidores en Internet. Empezó cuando comprendimos que tecnología, dato, licencia, servicio y responsabilidad podían dejar de venderse como productos separados y empezar a consumirse como una sola cosa.
LEGADO | Bytemaster fue mi universidad de resiliencia IT. Allí entendí, antes de que habláramos de Cloud como hoy, lo que significaba concentrar identidad, aplicaciones, datos, comunicaciones y escritorios de decenas de clientes y asumir la responsabilidad cuando algo fallaba. Aprendí que centralizar tecnología significa también centralizar responsabilidad. Y aquella idea se quedó conmigo: muchos años después volvería, mucho más madura, en iDESK.
05 – iDESK · INETUM: CUANDO VEINTE AÑOS SOÑANDO CON EL TELETRABAJO ACABARON CONVIRTIÉNDOSE EN UN PRODUCTO
2019–2025 · Product Owner · Digital Workplace · Citrix DaaS · Microsoft · Active Directory / Entra ID · VDI · DaaS · Multicloud · Zero Trust · MFA · BRS/DR · Continuidad de Negocio
iDesk no nació de una tecnología. Nació de una idea que llevaba persiguiéndome durante casi veinte años.
En Bytemaster, entre 2006 y 2008, había conocido un modelo que se adelantaba en muchos aspectos a lo que posteriormente llamaríamos Cloud Computing: sacar servidores, aplicaciones y datos de las empresas, centralizarlos y conseguir que los usuarios trabajaran remotamente. Aquello me fascinó tanto que años después intenté construir mi propia versión mediante IT-Consult. No pude convertirla en la empresa que imaginaba; me faltaba, entre otras cosas, una capacidad de desarrollo de software que yo no tenía. Pero aquella idea nunca desapareció. Sobrevivió transformada en CTX Network, mi laboratorio personal: infraestructura VMware, servidores, Citrix, Microsoft y un entorno que durante unos quince años utilicé para aprender, experimentar y también enseñar.
Y entonces llegó 2020. El COVID convirtió en necesidad inmediata algo sobre lo que yo llevaba años trabajando: que el lugar de trabajo no dependiera del lugar físico en el que estuviera el trabajador. Después de experiencias como La Vanguardia, la pregunta para mí era evidente: ¿qué ocurre con una empresa que necesita activar centenares o miles de puestos remotos y no dispone en su datacenter de toda una arquitectura Citrix, NetScaler, brokers, bases de datos, infraestructura y capacidad técnica para construirla contrarreloj? Mi respuesta fue iDesk.
DE UNA ARQUITECTURA A UN PRODUCTO
iDesk empezó apoyándose en Citrix DaaS como broker para proporcionar escritorios virtuales y aplicaciones, pero mi intención desde el principio fue que dejara de ser simplemente «un proyecto Citrix». Quería convertirlo en un servicio de Inetum. Un servicio contratable, dimensionable, desplegable, operable, soportable y repetible; con diferentes niveles de servicio, responsabilidades perfectamente definidas y un coste predecible.
Y eso es exactamente lo que acabó documentándose. El Libro Blanco de 2024 lo define como una solución de escritorio virtual e identidad adaptable al medio, orientada a productividad, acceso ciberseguro y capacidad de regeneración ante desastre. Y hay algo especialmente importante para mi legado: su propia portada dice literalmente «Producto desarrollado para INETUM ESPAÑA por Francisco Javier Vilá Costa», identificándome además como iDesk Product Owner. El control de cambios del documento recoge asimismo mi responsabilidad como elaborador, revisor y aprobador.
Aquella idea ya tenía nombre, arquitectura, metodología y documentación. Se había convertido en producto.
EL PUESTO DE TRABAJO DEJABA DE SER UN ORDENADOR
La idea esencial de iDesk era tremendamente sencilla de explicar. Una empresa podía seguir teniendo SAP, bases de datos, aplicaciones corporativas, ficheros o servicios donde quisiera: On Premise, Microsoft 365, Azure, AWS, SaaS o mediante un modelo híbrido. También podía conservar su propia identidad y sus propias políticas de seguridad. Yo no pretendía apropiarme de sus datos ni obligarla a reconstruir su informática alrededor de una plataforma. Yo le proporcionaba el lugar de trabajo.
Un escritorio virtual corporativo, securizado y conectado a su identidad, aplicaciones y datos, accesible desde prácticamente cualquier dispositivo y lugar con conectividad. El propio Libro Blanco terminó formalizando la arquitectura en tres capas: capa de usuario o endpoint; capa de control, donde se produce acceso, autenticación y autorización; y capa de recursos o zona VDA, donde se ejecutan escritorios y aplicaciones. Y estableció tres grandes paradigmas de despliegue: Multi-Datacenter On Premise, Híbrido On Premise + Cloud y Full Cloud.
Aquello resume perfectamente una de mis obsesiones profesionales: adaptabilidad al medio. No obligar al cliente a adaptarse a nuestra arquitectura. Conseguir que nuestra arquitectura pudiera adaptarse al cliente.
MULTITENANT NO SIGNIFICABA COMPARTIR LA IDENTIDAD
Y había una frontera que para mí era fundamental: la identidad pertenecía al cliente. iDesk podía convertirse en un producto industrializado y administrado por Inetum, pero eso no significaba reproducir literalmente el modelo ASP que yo había conocido en 2006. Cada organización debía conservar su identidad y su gobierno. La solución tenía que integrarse con AD DS, Entra ID, identidades híbridas u otros proveedores, respetando además las exigencias de ciberseguridad y normativa de cada empresa.
Esto hacía el problema bastante más difícil. Porque técnicamente podíamos construir escritorios. Lo complicado era conseguir que arquitectura, identidad, ciberseguridad, operación y responsabilidad estuvieran de acuerdo. Y eso también era iDesk.
UN ESCRITORIO QUE PODÍA DESAPARECER
Una de las ideas que más me interesaban era precisamente que el escritorio dejara de ser algo precioso. El dato era precioso. La identidad era preciosa. La seguridad era preciosa. El escritorio no tenía por qué serlo.
Un iDesk no persistente podía generarse desde una plantilla Golden, utilizarse y regenerarse completamente. El Libro Blanco llegó a definir diferentes estándares para aplicaciones publicadas, laboratorios, escritorios no persistentes con o sin perfil, escritorios con GPU y puestos persistentes para desarrolladores, ingenieros o cargas especializadas.
Eso cambiaba radicalmente el concepto tradicional del PC corporativo. Si el dispositivo se averiaba, se perdía o sencillamente dejaba de estar disponible, el lugar de trabajo podía continuar existiendo. Y por eso iDesk tenía para mí una segunda naturaleza fundamental: continuidad de negocio.
El producto contemplaba explícitamente escenarios de BRS/DR, recuperación ante desastre, activación parcial o masiva de teletrabajo y creación de decenas, centenares o incluso miles de escritorios a partir de estándares previamente definidos. Después de vivir el COVID, esto ya no era teoría. Sabíamos exactamente para qué podía servir.
LA iDESK FACTORY
Pero un producto Enterprise no puede depender de que su creador recuerde cómo instalarlo. Tenía que poder repetirse. Por eso concebí la iDesk Factory: metodología, consultoría previa, dimensionamiento, estándares, plantillas, conectividad, identidad, automatización, costes y responsabilidades que permitieran convertir una necesidad de negocio en un escritorio desplegable de forma industrializada.
Había que decidir quién autentica al usuario, dónde reside el broker, dónde se ejecuta la VDI, qué plantilla necesita, quién mantiene las Golden Images, qué automatización se aplica, cómo se conecta con los recursos del cliente y qué responsabilidades conserva cada parte.
La presentación comercial incluso reducía el proceso de hibridación a cuatro pasos comprensibles: POC → INFRA → APPS/DATA → HYBRID COMPLETE. Primero crear el escritorio y conectarlo con la identidad; después validar infraestructura y experiencia; posteriormente acceder a aplicaciones y datos; y finalmente entregar un workplace híbrido completamente funcional.
Eso era lo que yo buscaba. No hacer treinta y cinco proyectos distintos para treinta y cinco clientes. Crear una factoría capaz de fabricar treinta y cinco variantes de un mismo producto.
Y DETRÁS DEL PRODUCTO, UN SERVICIO
iDesk tampoco terminaba cuando aparecía el escritorio. Diseñé alrededor de él un modelo de soporte por capas: L1 Service Desk, L2 Engineering, L3 Arquitectura y L4 Producto. La documentación contemplaba desde recepción y triaje de incidencias hasta gestión de plantillas y perfiles, troubleshooting avanzado, monitorización, disponibilidad de tenants, atención 24×7 para situaciones críticas y escalado final hacia Citrix o Microsoft.
Y se diseñó también una matriz RACI para establecer hasta dónde llegaba la responsabilidad del fabricante, dónde comenzaba la del cliente y qué responsabilidades podían asumir conjuntamente cliente e Inetum. La propia presentación confrontaba el VDI convencional con distintos modelos DaaS y con las modalidades iDesk Standard, Advanced y Premium.
Ese detalle es importantísimo para mí. Porque significa que iDesk ya no era únicamente tecnología. Tenía arquitectura, operación, soporte, responsabilidades y modelo comercial. Era un producto.
EL PRODUCTO QUE CONSEGUÍ QUE EXISTIERA
Probablemente esta sea también la parte más agridulce de la historia. Conseguí algo que hasta entonces yo no había conseguido hacer con IT-Consult: convertir aquella visión en una solución corporativa real dentro de una gran compañía.
Inetum llegó a darle entidad de producto. Hubo presentación comercial, estándares, RACI, metodología, arquitectura, casos de uso, soporte y finalmente un Libro Blanco propio. Y, sin embargo, nunca conseguí que la organización apostara por iDesk con la intensidad con la que yo creía en él. Seguí desarrollándolo y documentándolo, pero llegó un momento en que mi tiempo, mi esfuerzo personal y mi propia realidad profesional tenían también un límite. Y finalmente me marché.
No considero por ello que iDesk fuera un fracaso. Porque hoy puedo abrir un documento corporativo de Inetum de 2024 cuya primera página dice: «Producto desarrollado para INETUM ESPAÑA por Francisco Javier Vilá Costa».
Y eso cierra para mí un círculo que había comenzado casi veinte años antes. En Bytemaster descubrí que las aplicaciones y los datos podían abandonar la oficina. Con IT-Consult soñé con construir mi propio servicio. Con CTX Network creé el laboratorio donde pude aprender y enseñar durante años. Con La Vanguardia comprobé, en mitad de una pandemia, que el teletrabajo podía convertirse de un día para otro en continuidad de negocio. Y con iDesk intenté reunir finalmente todas aquellas piezas en una sola cosa: identidad + escritorio + aplicaciones + datos + Cloud + ciberseguridad + resiliencia + soporte + servicio.
Por eso iDesk ocupa un lugar entre los cinco grandes proyectos de mi vida. No porque consiguiera vender todos los escritorios que imaginé. Sino porque fue la primera vez que una idea que llevaba veinte años dentro de mi cabeza dejó de ser una idea y se convirtió en un producto.
LEGADO | iDESK fue el momento en que dejé de construir soluciones para empezar a construir mi propia solución. Convertí décadas de Citrix, Microsoft, identidad, Cloud, ciberseguridad y teletrabajo en un producto Enterprise estandarizado, multitenant, multicloud y desplegable. No nació de una presentación: nació de años de laboratorio, proyectos y clientes reales. Para mí, iDESK demuestra algo muy sencillo: no solo podía diseñar arquitecturas; podía convertir mi conocimiento en producto.
06 — CNAT · CENTRALES NUCLEARES ALMARAZ–TRILLO: CITRIX CLOUD EN PLENA PANDEMIA: LLEVANDO UN ENTORNO CRÍTICO HACIA DAAS SIN SACAR SUS RECURSOS DEL DATACENTER
2020 · Enterprise / Citrix Architect · Citrix Cloud · Citrix DaaS · Microsoft Hyper-V · System Center Virtual Machine Manager · Active Directory · FSLogix · MCS · HDX · Microsoft Teams · BRS/DR · Alta Disponibilidad
En 2020, en plena crisis del COVID-19, participé desde IECISA / GFI —posteriormente Inetum— en uno de los proyectos que mejor representan mi concepción del teletrabajo como infraestructura crítica: la evolución del entorno Citrix de Centrales Nucleares Almaraz-Trillo (CNAT) hacia Citrix Cloud, abarcando el escenario corporativo de Almaraz, Trillo y Madrid. No se trataba simplemente de permitir que unos usuarios trabajaran desde casa. Estábamos hablando de proporcionar continuidad de puesto de trabajo a una organización perteneciente a un sector donde las palabras disponibilidad, seguridad, continuidad y resiliencia adquieren una dimensión completamente diferente.
El proyecto nació precisamente en el contexto tecnológico provocado por el COVID-19. De un día para otro, el teletrabajo había dejado de ser una opción para convertirse en un elemento fundamental de continuidad de negocio. Mi documentación del proyecto identificaba ya entonces las nuevas exigencias que aquella situación estaba imponiendo: acceso remoto ciberseguro, conexión desde múltiples dispositivos, optimización de comunicaciones, colaboración mediante Microsoft Teams, alta disponibilidad, nuevos estándares VDI, aplicaciones publicadas, escritorios compartidos y modelos de trabajo preparados para contingencia.
La decisión arquitectónica fue especialmente interesante porque no consistió en llevarlo absolutamente todo a la nube. Diseñamos un modelo híbrido: Citrix Cloud asumía las capas de acceso y control, proporcionando el broker, Gateway, portal, licenciamiento y servicios centrales de Citrix, mientras que CNAT mantenía identidad, recursos, aplicaciones, datos y capacidad de ejecución dentro de sus propios datacenters On Premises. La zona VDA continuaba ejecutándose sobre infraestructura Microsoft, utilizando Hyper-V y System Center Virtual Machine Manager como plataforma de virtualización. Era, por tanto, un verdadero modelo Citrix Cloud + On Premises Hosting.
Y precisamente ahí estaba, para mí, la elegancia de la arquitectura: Cloud no significaba renunciar al datacenter; significaba utilizar el Cloud allí donde aportaba resiliencia, elasticidad y simplificación operativa. Citrix Cloud absorbía buena parte del antiguo core Citrix —brokers, bases de datos, licenciamiento y componentes de acceso— mientras que las cargas de trabajo permanecían bajo el gobierno de CNAT. Los Cloud Connectors establecían el puente seguro entre ambos mundos y Active Directory continuaba siendo el propietario de la identidad corporativa.
Diseñamos además el nuevo estándar de puesto de trabajo alrededor de servidores multisesión y escritorios no persistentes, incorporando FSLogix Profile Container y Office 365 Container para desacoplar el perfil y los datos del usuario de la propia máquina que ejecutaba su sesión. La plantilla de negocio podía convertirse mediante Citrix Machine Creation Services en nuevos catálogos de máquinas, que posteriormente eran presentados mediante Delivery Groups a los grupos de seguridad correspondientes de Active Directory.
Eso significaba algo conceptualmente muy importante: la máquina dejaba de ser importante; lo importante era el servicio. Podíamos regenerar capacidad de puesto de trabajo desde una plantilla conocida, manteniendo identidad, perfiles, aplicaciones y acceso corporativo. Es exactamente la filosofía que años después terminaría llevando mucho más lejos con iDesk.
El proyecto incorporaba además una preocupación que durante el COVID se volvió crítica: Microsoft Teams dentro de Citrix. Audio, vídeo y colaboración podían destruir la experiencia de usuario y consumir enormes cantidades de ancho de banda si se trataban como tráfico convencional de una sesión virtual. Por ello trabajamos sobre las capacidades HDX, WebSockets y las tecnologías de optimización que permitían descargar ese tráfico del canal ICA/HDX y proporcionar una experiencia de colaboración adecuada incluso desde conexiones domésticas.
Pero quizá lo que más me interesa hoy de CNAT es que no diseñé la solución pensando únicamente en el confinamiento. En el documento ya distinguía explícitamente entre la situación In-COVID-19 y la exigencia Post-COVID-19. La pandemia era el detonante; la transformación del puesto de trabajo debía permanecer después de ella. Había que aprovechar aquella crisis para elevar definitivamente el nivel tecnológico del Digital Workplace.
Por eso estudié además cinco paradigmas arquitectónicos diferentes: Citrix completamente On Premises, control On Premises con recursos Azure, Citrix Cloud con recursos On Premises, Citrix Cloud con Azure y una arquitectura Citrix desplegada íntegramente sobre Azure. No se trataba de poner «Cloud» en una presentación. Se trataba de decidir qué debía estar en Cloud, qué debía permanecer On Premises, quién debía administrarlo, dónde debía residir la identidad y dónde tenía sentido económico y tecnológico ejecutar las cargas de trabajo. Para CNAT, el paradigma escogido fue Citrix Cloud con hosting On Premises.
Y ahí está, para mí, el verdadero legado de aquel proyecto. Almaraz, Trillo y Madrid podían evolucionar hacia Citrix DaaS sin desprenderse de la infraestructura Microsoft System Center Virtual Machine Manager que sostenía sus recursos On Premises. Cloud y datacenter dejaron de ser dos alternativas enfrentadas y se convirtieron en dos partes de una misma arquitectura de continuidad.
CNAT fue también otro paso en una idea que llevaba años madurando y que terminaría cristalizando definitivamente en iDesk: el puesto de trabajo no debía depender del ordenador, del edificio ni siquiera de que una determinada infraestructura de acceso estuviera disponible. Debía depender de la identidad, de las aplicaciones, de los datos y de nuestra capacidad para reconstruir de forma segura el entorno desde el que el usuario trabaja.
LEGADO | CNAT fue llevar el teletrabajo a una infraestructura crítica cuando el mundo se paró. Durante el COVID-19, evolucionamos Almaraz, Trillo y Madrid hacia Citrix Cloud / DaaS, manteniendo redundancia con la infraestructura on-premise. Para mí, su legado es sencillo: Cloud, resiliencia y continuidad dejaron de ser arquitectura sobre el papel. Había que mantener el negocio funcionando. Y funcionó.
07 – CTTI · GENERALITAT DE CATALUNYA: SPLASHTOP · CUANDO EL CONTROL REMOTO SE CONVIRTIÓ EN UN PROYECTO DE IDENTIDAD, CIBERSEGURIDAD Y GOBIERNO
2023–2025 · Enterprise Architect · Digital Workplace · Splashtop Enterprise · Identity Management · Azure AD / Entra ID · SSO · MFA · SCIM · Cisco Duo · Cybersecurity
En 2023 abordé para el CTTI de la Generalitat de Catalunya un proyecto que inicialmente podía parecer mucho más sencillo de lo que realmente era: implantar una nueva solución corporativa de asistencia y control remoto del puesto de trabajo mediante Splashtop Enterprise. Pero en una organización de esta dimensión no bastaba con instalar una herramienta para conectarse remotamente a un PC. Había que convertirla en un servicio corporativo gobernado, securizado, auditable e integrado con la identidad de la Generalitat.
Mi responsabilidad fue diseñar la arquitectura y convertirla en documentación ejecutable. Elaboré el HLD de Arquitectura Splashtop, definiendo desde sus principios fundamentales que la solución debía estar subordinada a la normativa del CTTI y de la Generalitat, a sus requerimientos de ciberseguridad, al principio de mínimo privilegio y a un modelo unificado de gobierno. La propia documentación establece explícitamente la integración con Azure AD mediante SSO, MFA y SCIM Provisioning, además de Cisco Duo, y me identifica como autor del entregable de arquitectura.
El proyecto terminó abarcando mucho más que la arquitectura del producto: roles, privilegios, controles granulares, grupos, identidades, dispositivos, licenciamiento, modelos mono-tenant y multi-tenant, unidades administrativas de Azure, monitorización y gobierno del servicio. El objetivo era establecer un estándar transversal de asistencia remota para el Digital Workplace de la Generalitat que pudiera mantenerse y evolucionar sin perder control sobre quién podía acceder, a qué dispositivos, bajo qué identidad y con qué privilegios.
Pero hubo un punto técnico especialmente importante que para mí representa perfectamente lo que significa trabajar como arquitecto: la arquitectura sobre el papel tenía que funcionar en producción. La integración de identidades mediante SCIM necesitaba hacer encajar correctamente el modelo de identidad corporativo On-Premise con el modelo esperado por el servicio Cloud. Ese problema terminó resolviéndose mediante una expresión regular aplicada a la transformación de identidad, permitiendo realizar correctamente el aprovisionamiento y sincronización SCIM. Fue uno de esos pequeños detalles técnicos de los que puede acabar dependiendo la viabilidad de una arquitectura mucho mayor.
Y esa fue precisamente una de las características de mi etapa en Inetum: no fui únicamente arquitecto; fui también documentador y hombre de laboratorio. Cuando necesitaba demostrar una arquitectura, probar una integración o encontrar la solución a un problema, utilizaba también CTX Network, mi propio laboratorio tecnológico construido durante años, poniendo infraestructura, conocimiento y tiempo personal al servicio de proyectos profesionales cuando era necesario desbloquearlos.
Splashtop fue otro ejemplo, después del proyecto de Directorio Activo Único del CTTI, de una forma de trabajar que acabó caracterizando mi paso por Inetum: pensar la arquitectura, construir el modelo, probarlo, resolver sus incompatibilidades, documentarlo y dejar detrás un entregable que permitiera a otros continuar trabajando sobre él.
El reconocimiento personal por aquel esfuerzo fue prácticamente inexistente. No hubo compensación adicional por poner mi laboratorio personal al servicio del proyecto y, desde mi perspectiva, tampoco recibí un reconocimiento proporcional al trabajo realizado. Pero con los años he aprendido a separar ambas cosas: el reconocimiento que recibí y el valor del trabajo que dejé hecho no son lo mismo.
Hoy quedan los entregables. Queda una arquitectura Splashtop Enterprise definida alrededor de identidad, SSO, MFA, SCIM, mínimo privilegio, gobierno y ciberseguridad. Y queda algo que para mí tiene todavía más valor: haber conseguido encontrar el punto técnico que impedía hacer funcionar correctamente la integración de identidad y convertir una solución comercial en un servicio viable dentro de la arquitectura real de una gran Administración Pública.
LEGADO | Splashtop fue convertir una herramienta de control remoto en arquitectura Enterprise para la Generalitat de Catalunya. Identidad, SCIM, seguridad y puesto de trabajo tenían que hablar el mismo idioma, y la clave estuvo en resolver desde laboratorio la sincronización correcta de identidades. Para mí, su legado es muy claro: cuando una integración parecía un problema de producto, la convertí en un problema de arquitectura. Y lo resolví.
08 – GCO · GRUPO CATALANA OCCIDENTE | DE GSLB A MFA: CUANDO EL LABORATORIO TERMINÓ RESOLVIENDO LO QUE EL FABRICANTE NO PUDO RESOLVER
2019–2024 · Enterprise Architect · Citrix NetScaler / ADC · GSLB · Alta Disponibilidad · Identity Management · MFA · SAML · OTP · Active Directory · Azure · Citrix Virtual Apps and Desktops · Flexxible IT
Mi relación técnica con Grupo Catalana Occidente (GCO) comenzó prácticamente al inicio de mi etapa en Inetum, en 2019, con un proyecto que inicialmente estaba centrado en Citrix NetScaler. El entorno debía evolucionar desde un esquema tradicional de alta disponibilidad basado en un HA Pair activo/pasivo hacia una arquitectura geográficamente redundante. El objetivo era disponer de servicio tanto en Barcelona como en Madrid, proporcionando continuidad y distribución inteligente del acceso a los usuarios mediante GSLB —Global Server Load Balancing—.
Aquello implicaba mucho más que añadir dos appliances. Había que evolucionar versiones y licenciamiento de NetScaler, construir la nueva arquitectura y conseguir que ambos emplazamientos funcionaran como partes coordinadas de un único servicio. Diseñé y desplegué la arquitectura GSLB con NetScaler en Barcelona y Madrid, estableciendo los mecanismos necesarios para dirigir los usuarios hacia el servicio correspondiente según la lógica de proximidad y persistencia definida para el entorno. El resultado fue una arquitectura Citrix mucho más resiliente que el antiguo modelo basado exclusivamente en HA local.
Pero la segunda parte de esta historia llegaría años después, alrededor de 2023–2024, cuando GCO necesitó incorporar doble factor de autenticación al acceso Citrix. Y ahí el proyecto dejó de ser principalmente un proyecto de networking y NetScaler para convertirse en un problema mucho más interesante de identidad, autenticación y arquitectura.
Mi primera solución fue la que técnicamente parecía más lógica: federación SAML contra la identidad Cloud del cliente en Azure, integrando el proceso de autenticación con NetScaler. Era una arquitectura perfectamente razonable sobre el papel. El problema apareció cuando aquella arquitectura tuvo que atravesar la realidad de dos ecosistemas tecnológicos distintos.
Por una parte estaba la infraestructura gestionada por Flexxible IT, donde residía buena parte de la zona VDA y de los componentes Citrix. Por otra, estaba el ecosistema propio de GCO, con su red corporativa, sus datos, su Active Directory y sus políticas de ciberseguridad. Aunque los componentes formaban parte del entorno corporativo del cliente, existían segmentación de redes, NAT y diferentes dominios de responsabilidad operativa.
Y ahí apareció el problema.
El flujo SAML podía iniciar correctamente su recorrido hacia Cloud, pero en determinados puntos del retorno de autenticación y su interacción con StoreFront, NetScaler, el SNIP y los servicios internos, la arquitectura de red impedía que el flujo terminara funcionando de forma fiable. Analicé las comunicaciones, revisé resolución y encaminamiento e incluso utilicé las herramientas de desarrollo de Edge y Chrome para observar exactamente qué información intercambiaban los componentes durante el proceso de autenticación.
Escalé el problema al propio Citrix, pero tampoco conseguimos obtener una solución que hiciera viable aquella arquitectura SAML dentro de las particularidades de red existentes.
Y entonces tomé una decisión que representa bastante bien mi manera de trabajar como arquitecto: dejé de intentar imponer al entorno la solución que decía el libro y busqué una solución que funcionara en el entorno que realmente teníamos.
Volví a CTX Network, mi laboratorio personal. Allí disponía de una arquitectura donde llevaba años probando Citrix, Microsoft, Active Directory y diferentes mecanismos de autenticación. Reproduje el escenario, trabajé con varios dominios y recuperé una tecnología de autenticación que tenía perfectamente estudiada y estandarizada: OTP integrado con NetScaler y Active Directory.
Funcionó.
La alternativa permitía implementar el segundo factor dentro del ecosistema On-Premise, eliminando del camino problemático la dependencia que estaba introduciendo la federación SAML hacia Cloud. La autenticación OTP podía integrarse con NetScaler y con los atributos correspondientes del usuario en Active Directory, proporcionando el segundo factor sin obligarnos a mantener aquella ruta de autenticación que estaba chocando con la segmentación y el NAT existentes.
Por tanto, descarté la arquitectura SAML y diseñé e implanté la alternativa basada en OTP.
Y funcionó en producción.
Para mí, ahí está el verdadero valor de este proyecto. No en haber sabido configurar SAML ni OTP, sino en haber sabido abandonar una arquitectura técnicamente elegante cuando la realidad demostraba que no era la adecuada, entender dónde estaba fallando, reproducir el problema en laboratorio y encontrar una solución diferente que respetara las restricciones reales del cliente.
Una vez más, CTX Network dejó de ser solamente mi laboratorio personal y pasó a convertirse en una herramienta de I+D aplicada al negocio. El conocimiento, las pruebas y los procedimientos que había desarrollado por iniciativa propia terminaron permitiéndome resolver un problema Enterprise que ni siquiera el escalado al fabricante había conseguido cerrar satisfactoriamente.
La implantación de identidad y MFA mediante OTP quedó bajo mi responsabilidad y fue completada con éxito, mientras que posteriormente transferí a otro compañero la continuidad de determinados trabajos relacionados con GSLB. Y hay algo que para mí diferencia este proyecto de otros de mi etapa en Inetum: el reconocimiento sí llegó directamente del cliente. Mi trabajo y mi capacidad técnica fueron valorados por las personas de GCO con las que trabajé, aunque yo no percibiera un reconocimiento equivalente dentro de mi propia compañía.
Por eso Grupo Catalana Occidente forma parte de mi legado. Porque permite recorrer en un mismo cliente varios años de mi propia evolución profesional: NetScaler → Alta Disponibilidad → GSLB → Identidad → SAML → MFA → OTP → Active Directory → Ciberseguridad.
En 2019 ayudé a construir la resiliencia del acceso entre Barcelona y Madrid. Años después regresé a esa misma arquitectura para construir la resiliencia de la identidad y de la autenticación.
Y cuando la solución prevista no funcionó, no me quedé esperando a que el fabricante encontrara la respuesta.
LEGADO | Catalana Occidente fue aprender que una buena arquitectura también consiste en saber cambiar de camino. Diseñé la resiliencia de acceso con NetScaler GSLB entre Barcelona y Madrid y, años después, afronté el reto de incorporar MFA. Cuando SAML y Azure no resolvieron correctamente aquel escenario, volví a mi laboratorio CTX Network, validé una alternativa con OTP y Active Directory y la llevé a producción. Para mí, su legado es ese: si el camino de libro no funciona, vuelvo al laboratorio hasta encontrar el que sí funciona.
9. LÍNEA DIRECTA ASEGURADORA | Arquitectura Citrix, Flexxible IT, Teletrabajo y evolución hacia Citrix DaaS / Azure
Mi relación profesional con Línea Directa Aseguradora comenzó prácticamente a mi llegada a IECISA en 2019 y terminó convirtiéndose en una colaboración de varios años alrededor de la evolución de su Digital Workplace. El primer reto no fue implantar una tecnología, sino transferir conocimiento. Diseñé la documentación y posteriormente impartí presencialmente en Tres Cantos un programa de formación diferenciado para dos perfiles: por una parte, responsables IT, ingenieros y arquitectos; por otra, los profesionales del CAU. No se trataba de un curso genérico de Citrix: utilizábamos la propia arquitectura de Línea Directa para explicar Microsoft, Active Directory, Citrix XenDesktop, DDC, StoreFront, licenciamiento, alta disponibilidad, almacenamiento, Flexxible VDI Manager y resolución de problemas de Workplace. La documentación oficial demuestra hasta qué punto aquella formación estaba adaptada al entorno real del cliente, llegando a trabajar sobre sus dos emplazamientos, TC1 Isaac Newton y TC4 Ronda Europa, sus Sites Citrix, plantillas, catálogos, hipervisores y modelos de administración.
Aquella formación fue el comienzo. Cuando llegó la crisis del COVID-19, participé en la adaptación de la plataforma para responder a la necesidad inmediata de teletrabajo, precisamente sobre muchas de las disciplinas de Oficina Remota que ya habíamos trabajado con sus equipos. La documentación de formación que había preparado para el CAU llegaba hasta los problemas reales del usuario remoto: conectividad, VPN, Citrix Workspace, dispositivos, impresión, monitorización y diagnóstico de incidencias. Posteriormente participé en una nueva evolución de la plataforma Citrix on-premise sobre VMware, desplegada en infraestructura de datacenter en Madrid, modernizando la arquitectura Citrix y manteniendo el principio de alta disponibilidad que caracterizaba el servicio.
La tercera gran evolución llevó el proyecto hacia el Cloud. Diseñé un escenario basado en Citrix DaaS y Microsoft Azure, incorporando escritorios virtuales no persistentes y capacidad multiusuario, de forma que el plano de control pudiera evolucionar hacia Citrix Cloud mientras los recursos de ejecución se adaptaban al modelo tecnológico requerido. El resultado fue una evolución completa: desde una infraestructura Citrix tradicional y su transferencia de conocimiento a los equipos responsables de operarla, pasando por la respuesta al teletrabajo durante la pandemia, hasta arquitecturas híbridas y Cloud basadas en Citrix DaaS y Azure Virtual Desktop.
LEGADO | Línea Directa fue pasar de enseñar una arquitectura a ayudar a transformarla. Empecé formando a sus equipos técnicos y CAU sobre su propia infraestructura y acabé acompañando su evolución desde Citrix on-premise, pasando por el teletrabajo durante el COVID, hasta Citrix DaaS y Azure Virtual Desktop. Para mí, su legado es muy mío: no basta con construir tecnología; hay que documentarla, enseñarla y conseguir que quienes se quedan puedan hacerla suya.
10. IBERDROLA | SECURIZACIÓN, EVOLUCIÓN CITRIX E iDESK
Durante mi etapa en Inetum, Iberdrola se convirtió en uno de los clientes más importantes dentro de mi trabajo como arquitecto Citrix y, especialmente, en el escenario que impulsó la creación y evolución de iDESK. Mi actividad se centró en la evolución, securización y estandarización de su infraestructura Citrix, trabajando directamente con los equipos técnicos del cliente y sobre un entorno gestionado mediante Flexxible IT.
Uno de los proyectos más relevantes fue la securización de las aplicaciones utilizadas para la Junta General de Accionistas, para la que diseñé una arquitectura de bastionado destinada a impedir accesos no autorizados al sistema operativo, almacenamiento, impresión y otros mecanismos susceptibles de provocar fugas de información, manteniendo al mismo tiempo la funcionalidad completa de las aplicaciones y la experiencia del usuario. Para realizar estos trabajos construí entornos de laboratorio aislados donde validar previamente las configuraciones antes de trasladarlas a producción, convirtiéndolas posteriormente en estándares mediante políticas Citrix y Microsoft GPO.
También desarrollé diferentes evolutivos de la plataforma, entre ellos la optimización de perfiles FSLogix para entornos VDI no persistentes, actualización y estandarización de configuraciones, compactación automática de perfiles y automatizaciones mediante PowerShell y GPO. La metodología consistía nuevamente en desarrollar y validar las soluciones en laboratorio antes de incorporarlas al entorno productivo, minimizando riesgos y permitiendo reutilizar posteriormente los procedimientos.
Iberdrola fue además el cliente objetivo que dio origen conceptual a iDESK. Mi intención era evolucionar el modelo existente hacia una metodología propia para diseñar e implementar Citrix DaaS de forma estandarizada, automatizada y cibersegura, convirtiendo años de experiencia técnica, laboratorio y documentación en un modelo de servicio reproducible para grandes organizaciones. Parte de esa metodología llegó a materializarse dentro de los propios evolutivos realizados para Iberdrola, donde incluso aparece iDESK integrado como elemento de soporte técnico.
LEGADO | Iberdrola fue donde mi forma de trabajar dejó de ser solo arquitectura para convertirse en método. Securización Citrix, bastionado, FSLogix, GPO, PowerShell y, sobre todo, laboratorio antes que producción. Allí confirmé que podía transformar problemas Enterprise en soluciones estandarizadas, documentadas y reproducibles. Para mí, su legado fue el germen de iDESK: dejar de resolver cada problema una vez para empezar a diseñar una forma de resolverlos siempre.