1. KISS (Keep it simple, stupid). Creo que nunca valoraremos lo suficiente el valor de simplificar todo lo posible los sistemas que construimos.
2. No construyas si puedes usar algo que ya existe.
3. Entrega (parte de) el producto cuanto antes a sus usuarios, sigue construyéndolo apoyándote en los comentarios de los usuarios.
4. La interfase del usuario debe ser web, siempre.
5. La interfase del usuario es un animal totalmente distinto. Debe diseñarla y construirla un equipo de especialistas en interfases de usuario y debe estar totalmente desacoplada de la lógica de la aplicación.

¿Qué opináis?.

Siempre reacciono de la misma forma, preguntando cuáles son (cifras) esos enormes volúmenes y muy a menudo resulta que la respuesta no está muy a mano. La enormidad es una sensación que no se concreta en cifras.

Y entonces llego a artículos como éste (la fuente original es ésta) en el que se informa de que eBay atiende mas de 5.700 millones de invocaciones mensuales a su API y pienso – esto si que es volumen y no los que gastamos por aquí –

En este otro artículo podéis encontrar información acerca de cómo eBay es capaz de hacer esto. Para los impacientes, el stack tecnológico es Java, IBM WebSphere Application Server y Oracle Enterprise Server; nada demasiado cool . Lo cool está en la forma de usarlo, lo estrictos que son en el cumplimiento de los principios de diseño. Algunas pinceladas:

• La base de datos es el cuello de botella, hay que llevarse todo el proceso posible a las capas superiores (incluso joins).
• La estrategia de escalado es horizontal.
• El desacoplamiento es vital. Integración asíncrona entre los componentes.
• Hay que virtualizar todos los componentes posibles. Reduce las dependencias de los elementos físicos y facilita el despliegue y la evolución de la plataforma.

En este documento los autores definen el concepto de RAIDb como una extensión del concepto de RAID (Redundant Array of Inexpensive Disks) aplicado a los repositorios de datos y presentan la implementación que han realizado de su concepto bajo el nombre de C-JDBC.

El problema a resolver es la escalabilidad de las bases de datos y la propuesta es hacerlo de forma horizontal utilizando hardware (y software) de bajo coste.

Tradicionalmente se ha avanzado mucho en la escalabilidad de las capas superiores de una arquitectura de sistemas de información moderna (multi-capa). Así el escalado de la capa de presentación (servidores web) y de la capa de aplicaciones/procesos (servidores de aplicaciones) está bastante bien resuelta. Mientras que la escalabilidad de la capa de datos normalmente se aborda mediante el escalado vertical (agrupaciones con un número de nodos pequeño, típicamente 2, y muy potentes).

Así es “fácil” encontrar instalaciones en las que existen centenares de servidores web atendiendo la presentación, decenas de servidores de aplicaciones ejecutando la aplicación/los procesos y un macro-cluster de base de datos soportando todo eso.

Ese macro-cluster acaba siendo la hardware más potente del fabricante de turno (IBM pSeries, Sun Fire Enterprise Server 25K, HP Superdome, etc.) con decenas de procesadores (sino cientos), cantidades ingentes de memoria y de almacenamiento. En estos clusters casi siempre y por definición, la mitad de la capacidad de proceso está desperdiciada. En un cluster de 2 nodos cada uno de los nodos tiene que ser capaz de asumir la carga completa del cluster ante la caída del otro nodo. Esto significa que se intenta mantener la carga del cluster de forma que ninguno de sus nodos supere el 50% de carga y, por lo tanto, el otro 50% de su capacidad no se usa en condiciones normales.

El planteamiento de RAIDb es llevar el concepto de escalabilidad horizontal a la capa de datos. Permitir el escalado horizontal (añadir más servidores, más pequeños, más baratos) de una forma sencilla, eficaz y económica. RAIDb viene a cubrir las necesidades de escalabilidad y de tolerancia a fallos de la capa de datos.

Al igual que en el caso de RAID, los creadores de RAIDb identifican tres tipos de agrupamiento: RAIDb-0, RAIDb-1 y RAIDb-2. RAIDb-0 es un modelo en el que las bases de datos se particionan pero no se distribuyen (no hay redundancia), RAIDb-1 implica un mirrorring completo de las bases de datos (redundancia completa); mientras que RAIDb-2 define un escenario de replicación incompleta de las bases de datos.

Adicionalmente los autores identifican distintos subtipos: RAIDb-1ec, RAIDb-2ec

En el documento mencionado no solo se explica y define todo lo dicho hasta ahora, sino que también recoge información acerca de un conjunto de benchmarks realizados por los autores (concretamente han utilizado el benchmark TCP-W) y que ilustran las capacidades de escalado de las distintas alternativas dependiendo del número de nodos en el cluster.

Como os decía antes os recomiendo la lectura del documento original.

Para introducirnos, REST significa REpresentational State Transfer y se trata de un estilo de de hacer las cosas basado en el principio de que todo debe ser accesible vía una URI. Fundamentalmente este concepto se aplica a las entidades de un sistema, los datos.

Por otro lado ROA significa Resource Oriented Architecture y se aplica a aquellos sistemas cuya arquitectura sigue el concepto de REST.

Si deseais produndizar más en estos temas os recomiendo empezar por aquí:

• Architectural Styles and the Design of Network-based Software Architectures. El documento primigénio en el que, por primera vez, se plantea el concepto de REST. Es un documento de Roy Thomas Fielding, estudiante de la Universidad de California, Irvine; elaborado para la obtención del doctorado en ¡filosofía en información y ciencias de la computación!.
• REST ‘ideally suited’ for SOA-style data services – Burton. Un artículo en el que se define de forma sencilla REST y se plantea el concepto de ROA.
• Mini-Guide: REST. Una mini-guía preparada por TheServerSide Interoperatibility Blog en la que se recopilan decenas de URL’s interesantes para aquellos que se quieran introducir en el concepto de REST.

A través de un artículo en CNET News.com he llegado a la web SOA Facts .

Bueno, en realidad he intentado llegar sin conseguirlo, he tenido que recurrir al cache de San Google

El caso es que la web en cuestión recoge una serie de “verdades” acerca de SOA, me han parecido muy graciosas así que os traduzco algunas de ellas.

Las traducciones son a _mi_ libre albredio. Y no he traducido algunas “verdades” que, simplemente, no he sabido traducir.

1. SOA es la única cosa que Chuck Norris no puede matar
2. SOA inventó Internet, e Internet fue inventado por SOA.
3. SOA no es complejo. Es que tu eres tonto.
4. En el último año SOA incremento el PIB de Turquía un 1000%
5. Una persona fue capaz una vez de describir correcta y completamente SOA, murió inmediatamente después.
6. Otra persona también fue capaz de describir correcta y completamente SOA, inmediatamente fue objeto de externalización de sus servicios.
7. Larry Ellison murió en un terrible accidente, pero le administraron SOA inmediatamente. Después de eso revivió, fundó una compañía de software multimillonaria y ahora pilota jets privados.
8. Las armas no matan a la gente, los modelos conceptuales de servicios SOA lo hacen.
9. SOA puede escribirse y compilarse a si misma.
10. SOA es un anagrama de osa (hembra de oso). Es bien conocido en el mundo hispanohablante que las osas son capaces de modelar procesos de negocio y optimizar la reutilización de los activos de TI mejor que cualquier otro animal que hiberne.
11. SOA es tan estupendo que no bastan con 10 verdades.
12. SOA es la dueña de todos los Directores de TI.
13. Si un árbol cae en el bosque, SOA lo sabe.
14. Si buscas en Google “SAP” y “Chuck Norris”, el primer resultado que aparece es SOA Facts.
15. SOA está siendo utilizado en el tercer mundo para resolver el problema del hambre. Poblaciones enteras están siendo alimentadas con el valor futuro que SOA aportará a los negocios.
16. SOA es capaz de ganarte siempre al tres en raya. Aunque tu empieces primero.
17. J2EE puede, a veces, convertir en diamante un trozo de carbón. ¡SOA puede obtener diamantes del aire!.
18. SOA sabe lo que hiciste el último verano y no le gusta por que no era SOA.
19. En una pelea entre un ninja y un jedi, SOA ganaría.
20. SOA viola la primera y tercera leyes de la termodinámica. Pero no la segunda, ya que toda la energía fluye desde SOA.
21. El octavo día Dios creo SOA, entonces SOA creó el rock&roll.
22. Plutón ya no es el noveno planeta del sistema solar porque SOA quería el puesto.
23. SOA enseño a Chuck Norris todo lo que sabe.
24. SOA es el ingrediente secreto que hace “los pollos del coronel” tan sabrosos.
25. Durante décadas los científicos han buscado una teoría única capaz de explicar toda la complejidad del universo,… uuuhhhmmmm,… SOA?
26. SOA no puede ser denominado BOA (Business Oriented Architecture) porque sería demasiado restrictivo para SOA.
27. SOA es también una postura de yoga que consiste en realizar todas las otras posturas simultáneamente.
28. En el infierno de Dante hay un nivel dedicado exclusivamente a aquellos consultores en cuyo currículo no aparece la palabra SOA.
29. SOA es la respuesta correcta a todas las paradojas zen.
30. Mike Tyson never physically beat an opponent. He ‘Edumacated’ them about SOA.
31. SOA es una fuente de energía más eficiente que la nuclear, más limpia que la solar o eólica, más accesible que el carbón y más estable geopolíticamente hablando que el petróleo. Es tan mala que no puedes soportarlo.
32. SOA lo puede hacer con solo una línea de código.
33. La primera regla de SOA es que no debes hablar acerca de SOA.
34. El resumen ejecutivo de SOA son 7.351 páginas distribuidas en 10 tomos.

Se trata de un extenso documento en el que el autor detalla a fondo no solo el estado actual de los sistemas de información que están detrás de elmundo.es, sino que también nos explica cuál ha sido su evolución a lo largo del tiempo y los criterios y circunstancias que les han llevado a adoptar una estrategia tan definida como la que tienen.

Desde el punto de vista técnico es un documento con innegable valor y que describe “el mundo real” de una sede web como la del periodico. Seguro que su lectura os deparará algunas sorpresas.

Desde el punto de vista estratégico también es muy interesante. Raúl recoge en el documento de forma muy estructurada los principios de diseño que han dirigido sus sistemas de información. Y todo el plantemiento posterior es tremendamente coherente con esos principios de diseño. En su discurso soy incluso capaz de identificar los ciclos que aplicamos desde hace años en el diseño de sistemas de información complejos:

• Ciclo contextual
• Ciclo conceptual
• Ciclo lógico
• Ciclo físico

Respecto al análisis del contexto (punto de partida), Raúl dice textualmente,

Y quizás uno de los puntos que más llamativos me resultan es el párrafo que sigue al anterior,

Esto, traducido a mi lenguaje, representa la transición desde el análisis del contexto a la definición del modelo conceptual futuro. Este paso es crítico y sinceramente creo que una parte importante del éxito que el grupo de I+D de elmundo.es ha tenido se debe a haberlo dado.

Muchos pensaréis que lo que diferencia la situación del elmundo.es del de otras organizaciones es su apuesta por el software libre, su apuesta por un equipo propio, especializado y “mimado”. Esto está muy bien, es muy bonito y, sobre todo, aporta un aire romántico que, aunque nos cueste admitirlo, a los profesionales de los sistemas de información nos encanta (nuestro amor/odio hacia la figura de los piratas tradicionales no es casualidad).

Pues a lo mejor tenéis razón y esos aspectos son los que han hecho de elmundo.es una “mejor práctica”; pero en mi opinión su éxito debe mucho más a la existencia de unas líneas estratégicas claras y al respeto a estas líneas estratégicas a lo largo de todo el ciclo de evolución de sus sistemas que ha decisiones físicas (técnicas) que, desde el punto de vista de un estratega, no son más que decisiones tácticas a corto plazo.

Mi enhorabuena al grupo de Investigación y Desarrollo de elmundo.es, sea cuál sea el fundamento de su éxito es un mérito que a nadie más puede atribuirse.

Una de las primeras etapas de un proyecto de diseño de arquitectura de sistemas de información es la identificación de los principios de diseño.

Es probablememte una de las etapas más importantes y, paradójicamente, una de a las que menos atención se le presta. En mi experiencia cometer el error de no dar la importancia necesaria al proceso de identificación de los principios de diseño es uno de los errores más comunes y más graves que se cometen en los proyectos de diseño de arquitecturas de sistemas de información empresariales.

El objetivo es ayudar al “dueño” del proyecto (al cliente, a la organización) a identificar cuáles son las características más importantes que deben cumplir sus sistemas de información.

¡El objetivo del arquitecto de SI en este etapa es ayudar a hacer, no hacer!.

Cuando alguien contrata a un arquitecto para que le construya la casa, la misión del arquitecto es construir la casa que el cliente quiere, necesita y le gusta (y puede pagar); los principios del diseño los marca el cliente, la misión del arquitecto es ayudarle a identificarlos. En el caso de los sistemas de información es exactamente lo mismo.

Hay ocasiones en las que la personalidad o intereses del arquitecto priman sobre las del cliente y el resultado es una casa/edificio/sistema de información excelente, innovador, “de firma”; pero que no es el que el cliente quiere y/o necesita.

Sin perder entonces de vista que los principios de diseño debe idenficarlos el propietario del sistema de información, si es verdad que el arquitecto de sistemas de información puede (y debe) proporcionar un conjunto de principios básicos, más o menos ineludibles, extraidos de la experiencia propia y del análisis de la evolución de los sistemas de información empresariales.

En esta línea hace años que se ha identificado una suerte de “ideal” al que una organización debe tender si quiere sobrevivir en un entorno como el actual. Este ideal se ha denominado “Empresa Adaptable” (Adaptive Enterprise). Múltiples proveedores de servicios de sistemas de información han abrazado este ideal, uno de ellos es HP que ha hecho del concepto de “Empresa Adaptable ” (Adaptive Enterprise) el eje de su discurso comercial. Evidentemente el interés que cada organización pone en el concepto de empresa adaptable depende de sus propios objetivos, lo que por otra parte es totalmente lícito. En el caso de HP, por ejemplo, todo el discurso de “Empresa Adaptable” tiene como objetivo la venta de los productos y servicios de HP; en mi opinión esto no resta validez a los principios en sí mismos.

HP identifica cuatro principios básicos de diseño que hay que considerar cuando se trata de construir una “Empresa Adaptable” (aunque quizás en el caso de HP podríamos particularizar más y decir “Infraestructura de TI Adaptable”):

• Simplificación. Simplificar hasta dónde sea posible los entornos de SI consolidando aplicaciones e infraestructuras, automatizando y coordinando procesos y virtualizando los recursos. Esto debería permitir reducir el esfuerzo necesario para la gestión de los SI además de permitir una respuesta más rápida ante las necesidades de cambio.
• Estandarización. Las estandarización es otra vía de simplificación. La utilización de estándares, hasta dónde sea posible, reduce costes y facilita el cambio. Permite una integración más fácil y más rápida.
• Modularidad. El “divide y vencerás” es de necesaria aplicación. Eliminar componentes monolíticos descomponiendolos en otros más pequeños, concretos y, por lo tanto; más reutilizables permite reducir el volumen de los SI, incrementar su eficiencia y su flexibilidad. Este concepto es la base de las arquitecturas orientadas a servicios (SOA).
• Integración. La modularidad (numerosos componentes pequeños que trabajan en equipo para soportar un proceso) implica la necesidad de disponer de la capacidad de gestionar de forma sencilla y ágil la integración de estos componentes para componer dichos equipos de trabajo. La estandarización simplifica enormemente esta necesidad de integración, fundamentalmente al permitir “enchufar” (plug-and-play) componentes de forma sencilla dentro del equipo, y definir el modelo de relación entre los componentes. Además la integración debe proporcionar la capacidad de gestionar el funcionamiento de dichos equipos de trabajo optimizando los recursos, monitorizando su rendimiento y aportando fiabilidad.

y, por lo tanto, ¿qué es un Arquitecto de SI Empresariales?.

Vayamos por partes, según el diccionario de la Real Academia Española arquitectura es, en su primera acepción, – “Arte de proyectar y construir edificios” – . La segunda acepción es – “Estructura lógica y física de los componentes de un computador” -.

La Wikipedia la define como – “(sic.) el arte y la ciencia de diseñar volúmenes y espacios que sirvan a las personas”.

Evidentemente es necesario llevar al contexto de los sistemas de información esta definición genérica de arquitectura. Primero, en el caso de la arquitectura de SI el objeto no es diseñar “volúmenes y espacios” sino, precisamente, sistemas de información.

También es muy importante recalcar que el objeto de la arquitectura es el diseño, el resultado de un proceso de arquitectura es un diseño, una descripción detallada de lo que ha de ser construido.

Por otro lado el diccionario de la Real Academia Española define arquitecto como -”Persona que profesa o ejerce la arquitectura” -. Por lo tanto, sumando dos y dos, un arquitecto de sistemas de información es aquel profesional cuyo trabajo consiste en la realización del diseño de sistemas de información.

Vuelvo a subrayar que el resultado del trabajo de un arquitecto de sistemas de información es un diseño, una descripción detallada de lo que ha de ser construido. Y me parece importante incidir en esto porque, estrictamente hablando, el trabajo de un arquitecto de sistemas de información termina antes del inicio de la construcción del sistema de información diseñado.

Si bien es verdad que, al igual que en el caso de los arquitectos “de volúmenes y espacios”, es normal y, en mi opinión, muy recomendable; que el arquitecto de sistemas de información participe en el proceso de construcción con un papel que le permita asegurar el ajuste del sistema construido al diseño realizado (ésto no es ni mucho menos trivial).