Mostrando entradas con la etiqueta Mainframe. Mostrar todas las entradas
Mostrando entradas con la etiqueta Mainframe. Mostrar todas las entradas

¿Y si los brokers de Bolsa fueran máquinas?



RSS

Hace unos días, durante una sobremesa con dos colegas y amigos de IBM, uno de ellos planteó la cuestión de qué pasaría si Watson, el ordenador más inteligente y mejor informado jamás diseñado, pudiera trabajar como broker en la nómina de Goldman Sachs, Morgan Stanley o cualquier otro grupo de inversión.

Desde el principio fuimos dos contra uno defendiendo la idea de que más información, mayor capacidad de análisis y menor tiempo de respuesta no eran necesariamente garantía de éxito en la bolsa. Ahí van las tres razones que en ese momento no supimos justificar.


La teoría de los juegos, yo te doy esperando que tú me des

Imaginemos este juego y sus sencillas reglas:
María y Pedro tienen 10 euros cada uno
Si María le da a Pedro una parte de su dinero, Pedro recibirá el doble de lo que María le dé.
A su vez, Pedro podrá 'devolver' a María la cantidad que considere apropiada por su generosidad, incluido 0 euros.

Un razonamiento lógico (tal y como piensa una máquina... o un ingeniero al finalizar sus estudios) haría que María le dé sus 10 euros a Pedro con lo que Pedro pasaría a tener 10 + (10+10) = 30 € y María 0 €. Posteriormente, ambos compartirían el dinero a razón de 15 euros cada uno. Ese sería el intercambio más óptimo, el que maximiza el beneficio.

Pero las personas rara vez pensamos así ya que jugamos con la posibilidad de que María le dé todo su dinero a Pedro y éste opte posteriormente por quedarse con todo. Juegos como éste -de la confianza- u otros como el Dilema del Prisionero hacen que la forma de pensar de una persona y la de una máquina sean, hoy por hoy, radicalmente diferentes. Y la bolsa, en definitiva, es un gran juego.


Si sabes que va a bajar, ya habrá bajado

En un mercado perfecto, todos los brokers tienen la misma información; no existe la información privilegiada. En ese contexto, si un analista tiene información que le sugiere comprar o vender a gran escala, probablemente no podrá hacerlo porque ya habrá ocurrido. Tan pronto como el mercado sepa que una acción es deseada o repudiada alterará su valor de forma que será más caro comprarla o venderla.
Ese ajuste automático del mercado hace que cuando un broker sabe (con certeza, más allá de la intuición) que algo va a pasar, realmente ya haya pasado.

De hecho, los grandes cambios en los mercados, donde se producen las grandes ganancias y pérdidas, ocurren habitualmente ante hechos absolutamente inesperados e impredecibles. Perder los 10 mejores días origina unos beneficios promedio un 50,8% inferiores. Y a su vez, evitar los 10 peores días genera unos beneficios un 150,4% superiores a las estrategias pasivas.

El gráfico adjunto muestra la evolución de los beneficios generados por las empresas del S&P500 desde su inicio (más de 50 años) y la misma curva descontando únicamente los diez días de más actividad. Estos diez días están asociados a sucesos como la caída del muro de Berlín, el 11-S, el tsunami en Japón,... en general eventos impredecibles, inesperados y de gran repercusión.

Y no parece sensato pensar que una máquina tenga ventaja a la hora de obtener esa información. De hecho, si Watson supiese de antemano que el WTC iba a ser atacado, seguro que alguien tendría la genial idea de llevar el equipo entero (incluido tal vez algún técnico de IBM) a unas dulces vacaciones en Guantánamo. Obviamente, eso no es real.


Hasta un mono invierte mejor que muchos brokers

Los movimientos bursátiles en un mercado eficiente son, en gran medida, predecibles. Solo cuando los mercados no son eficientes, por información privilegiada por ejemplo, su proyección se convierte en impredecible. La idea es de Burton Malkiel quien teorizó sobre la idea de comparar la capacidad inversora de los mejores brokers con la de un mono lanzando dardos a las páginas de un diario financiero (y eligiendo las inversiones en base a ello).

Wall Street Journal quiso verificar la teoría de Malkiel y en el periodo 1988-1998 invitó a los mejores brokers a hacer elecciones de acciones del NYSE, AMEX y NASDAQ. Cada mes cuatro brokers confeccionaban su cartera para los siguientes seis meses. Al final del periodo los dos mejores continuaban y los otros dos eran reemplazados. Con ello, se garantizaba una cierta selección natural que, a primera vista, implicaba una mejora continua.

Al finales de 1998 se presentaron los resultados del estudio. Durante los diez años se habían realizado 100 competiciones y los profesionales ganaron en 61 de ellas. Viéndolo al revés, los monos ganaron en 39 ocasiones, lo que no está nada mal teniendo en cuenta que eran inversiones absolutamente aleatorias.

Y la cosa fue aún peor cuando se comparó a los profesionales con el Dow Jones Industrial Average ya que prácticamente empataron con el valor medio del mercado.

En la mayor parte de las ocasiones en las que ganaron los brokers las razones se debían más a su capacidad como lobby para influir en el mercado (en las acciones por las que previamente habían apostado) o en su capacidad para obtener información privilegiada que en su pericia para analizar los mercados financieros. Y es cuestionable que una máquina, por muy inteligente que sea, tenga más capacidad que una persona para aprovechar esas imperfecciones (la mayor parte de ellas ilegales) de los mercados.


Resumiendo

El 15 de diciembre de 2003 era detenido Sadam Husein. La noticia, de gran importancia a nivel político y económico teniendo en cuenta que era el ex-mandatario de uno de los mayores productores de petróleo, provocó que los Bonos del Tesoro (valores refugio) estuvieran alternando durante todo el día entre subidas y bajadas.

A las 13.01 Bloomberg News decía lo siguiente: «Suben los bonos del Tesoro de Estados Unidos; es posible que la captura de Husein no frene el terrorismo». Apenas media hora después el mismo medio decía «caen los bonos de Tesoro de Estados Unidos; la captura de Husein aumenta el atractivo de los activos de riesgo». La captura de Sadam era a la vez una cosa y la contraria, algo habitual en el mundo financiero, capaz de explicar cualquier cosa, siempre a posteriori, sin tan siquiera despeinarse.

«Voy a repetir lo que sigue hasta que me quede afónico: lo que determina el sino de una teoría en la ciencia social es el contagio, no su validez». Nassim Taleb dixit en referencia a la Teoría de la cartera de valores moderna, aunque bien pensado es válido en muchos otros campos.

Eso es lo que en definitiva hace que la bolsa no sea, ni de lejos, una ciencia exacta. Pobre Watson...


Enlaces relacionados:

     › Javier Estrada (IESE) 2007. Black Swans and Market Timing: How Not to Generate Alpha.
     › Nassim Taleb 2008. El cisne negro: El impacto de lo altamente improbable.





RSS

El mainframe frente a sí mismo



RSS

IBM System z Imaginemos: Una compañía de reciente creación nos ha encargado la tarea de asesorarle respecto a qué tipo de sistemas deberán soportar sus procesos de TI. La elección es basar todo en un mainframe o utilizar un clúster de servidores.

Pero, ¿por qué elegir? Lo mejor, sin duda, un clúster de mainframes; dos o más mainframes sysplex trabajando en modo cooperativo. Por desgracia, la necesidad de elegir viene determinada porque los presupuestos no son infinitos.

Antes de empezar, fijemos un poco la terminología. Por mainframe se entiende una máquina System z de IBM. A su vez, por servidores se entiende servidores -valga la redundancia- x86 o x64 de gama alta de Intel o AMD, familia System p de IBM, Superdome de HP o servidores con tecnología Sparc de Oracle.

Analicemos la elección desde diferentes puntos de vista.


Seguridad

Todo debe seguir en pie
Si le preguntásemos a un director de TI de una entidad financiera o de una gran superficie probablemente diría que lo más importante en su terminal financiero o en su terminal de punto de venta es la confiabilidad del sistema; la resiliencia que dicen los psicólogos. Y hablando de resiliencia, la capacidad para sobreponerse a problemas de un mainframe no tiene parangón. Los técnicos de sistemas de mainframe habitualmente presumen de que casi la mitad del código de zOS está destinado a recuperarse de forma automática ante errores o situaciones no previstas, algo muy diferente de lo que ocurre en cualquiera de los sistemas operativos habituales en servidores.

Pero ¿qué ocurre si le hacemos la misma pregunta a un pasajero de un avión? ¿Preferirá volar en un avión con un único sistema altamente tolerante a fallos o preferirá dos o tres sistemas un 1% menos tolerantes individualmente trabajando en paralelo y dándose cobertura de fallo entre ellos? Antes de contestar, analicemos las disponibilidades.

Cuando se habla de que un sistema es más seguro que otro se manejan porcentajes pírricos de diferencia que en ocasiones no llegan ni al 1%. Un mainframe puede presumir de cinco '9' de disponibilidad. Es decir, en el caso del quinto '9' (disponibilidad del 99,999%), el tiempo máximo de parada es de 5 minutos y 26 segundos al año. Todo ello, lógicamente, sin contar los problemas asociados a los problemas generados por los técnicos que son habitualmente mucho mayores, bien por fallos o bien por paradas planificadas.

Cuadro de mandos de un avión. Todo está duplicado
Obsérvese el eje de simetría vertical,
es decir, el clúster de sistemas
Contestemos ahora a la cuestión que dejamos pendiente. ¿Alguien se subiría a un avión sabiendo que todo depende de un único sistema que tiene una tasa de fallo de cinco minutos al año? La mayor parte preferirán pensar que hay al menos dos sistemas que, aún teniendo una tasa de error mayor  (por ejemplo, un '9' menos), combinados, dan una probabilidad de fallo muy inferior. De ahí, que todos los sistemas de un avión tengan siempre al menos un mecanismo electrónico doble, unido casi siempre a la posibilidad de hacer lo mismo de forma manual.

Lo sé, aún falta añadir la Ley de Murphy al cóctel (todo lo que pueda fallar, indefectiblemente fallará y si puede hacerlo a la vez, lo hará) pero esta Ley aplica por igual para todos los modelos que podamos plantear.



El ecosistema

Un aspecto enormemente importante, tanto o más que la resiliencia de la máquina, es la capacidad de sobreponerse a fallos del ecosistema. Y por ecosistema se entiende todo lo que rodea a las máquinas y que tiene que ver con su funcionamiento. En definitiva, todo aquello en lo que su no existencia implique pérdida de servicio.

Hay elementos vitales como el suministro eléctrico o la refrigeración, la ubicación del CPD, la probabilidad de desastres naturales en función del emplazamiento, el sabotaje,... Muchas de las grandes compañías del entorno comenzaron a percibir este hecho y a proteger su ecosistema a raíz de las inundaciones de Donostia afectando al Banco Guipuzcoano o el incendio eléctrico en Barajas dejando sin servicio todo el CPD de Iberia.

Por tanto desde el punto de vista de ecosistema parece más razonable pensar que es mejor tener un clúster con nodos geográficamente distantes y diferentes proveedores de energía a tener todo en una única ubicación.


Rendimiento

Mare Nostrum de IBM
Supercomputador Mare Nostrum de IBM
Barcelona Supercomputing Center
El rendimiento es, sin lugar a dudas, muy superior en los clústeres que en los grandes mainframes. Para ello únicamente hay que atender a dos hechos.

El primero es que la lista Top 500, en la que se sitúan los 500 súper-computadores más potentes del mundo, está basada al 100% en mega-clústeres. Estos clústeres funcionan haciendo creer al software que todos los servidores que lo integran conforman una única máquina aunque realmente no es así. Por ejemplo, el número uno actual, el súper-computador chino Tianhe-1A, está basado en procesadores Intel x64, pero en cantidades ingentes (14.336 procesadores). Por cierto, es la primera vez que China dispone de un súper-ordenador en la primera posición de la lista.

Habrá quien piense que estos súper-computadores solo sirven en el ámbito científico, que suele ser muy diferente del mundo real. Pues el otro aspecto que invita a creer que el rendimiento es superior en los clústeres es que la mayor parte, por no decir todos, los sitios Web de Internet situados en el Top 20 respecto a visitas basan su infraestructura en clústeres hadoop. Estos clústeres basan su potencia de cálculo no en dos, tres o diez nodos sobre servidores sino en cientos o miles de nodos basados en hardware, habitualmente, más cercano al entorno doméstico; en muchos casos simples PCs. Da igual que se rompan los discos de 50 PCs al día, siempre habrá otros cien mil funcionando. El número de compañías que apoyan esta tecnología va en aumento porque parece que les salen las cuentas de coste-rendimiento. Ahí va la lista, aunque la verdad, me parece que a medio plazo no es la solución.


Coste

El coste es, probablemente, la clave de todo. Durante años el gasto en TI ha estado aumentando el doble que el PIB mundial. Este desfase puede justificarse en cierto modo desde la óptica de aportación al negocio, y desde ese punto de vista es posible encontrar una explicación razonable a ese incremento durante los 20 últimos años. Pero esta justificación es aplicable únicamente a las aplicaciones dado que, salvo honrosísimas excepciones, las inversiones en infraestructura de TI raramente aportan valor al negocio.

Gasto en TI frente al PIB mundial

Es decir, la obligación de cualquier responsable de TI es intentar reducir al máximo las inversiones y el gasto corriente en infraestructuras para dedicar el máximo esfuerzo inversor al desarrollo de aplicaciones que se ajusten y potencien al máximo el modelo de negocio. Eso sí es crear valor.

Y en este punto es donde los mainframes están encontrando mayores dificultades. Los costes de bajada de bandera son significativamente más altos que los que se dan en los modelos basados en clústeres de servidores.

La mejor defensa es un buen ataque. Y quizá por ello, dado que los servidores están amenazando la hegemonía del mainframe, lo mejor es atacar donde les duele. IBM ha planteado su nuevo mainframe z196 de forma que, gracias al virtualizador de hardware KVM, puede ejecutar máquinas virtuales x86 basadas en Linux (ya disponible) y próximamente también Windows (previsto para finales de 2011). Es un paso lógico y muy acertado en el que únicamente falta saber qué éxito tendrá en un mercado dominado por VMWare con Hyper-V a cierta distancia.
Nunca es tarde, pero es increíble que IBM haya tardado tantos años -incluso décadas- en acercar la virtualización de hardware a la plataforma x86 teniendo en cuenta que fue ella quien inventó y desarrollo esta tecnología hace casi cuarenta años con el sistema operativo MVS (1974) en sus mainframes.


Tecnología

En relación a la tecnología, centrando la tecnología en el microprocesador, no parece haber diferencias significativas. El rendimiento de cada procesador se sitúa a la cabeza en función del mes en que se mida y dependiendo del tiempo que haya pasado desde el último lanzamiento de producto de cada fabricante.

Respecto a la proyección a futuro, los equipos basados en Intel y AMD parecen tener el futuro garantizado dada la enorme cuota de mercado y, con ello, la gran capacidad de inversión en I+D. Por su parte, IBM, a sabiendas de que el mercado de mainframes no era suficiente para mantener la masa crítica necesaria para fabricar procesadores, ha sabido llegar a acuerdos en un mercado de consumo, el de los fabricantes de consolas. Así, tanto la PlayStation 3 de Sony como la Xbox 360 de Microsoft incorporan exactamente los mismos chips con tecnología Cell que lleva el mejor y más avanzado de los mainframes. Por eso no debería sorprender que el Departamento de Defensa de EEUU haya creado un súper-computador (ocupa el puesto 33 en el ranking Top500) a base de interconectar 1.700 PlayStation 3.

Sin embargo, el futuro de HP Integrity con sus procesadores Itanium no parece estar tan claro dado que HP se ha quedado solo en su utilización. Itanium se desarrolló con la mente centrada en la sustitución de x86 y x64 pero la realidad ha sido otra bien diferente. Y lo mismo le ocurre a Oracle con su tecnología Sparc dado que tendrá que recuperar los últimos años de declive tecnológico de Sun.


Complejidad

Hay un aspecto diferenciado del coste pero que repercute directamente en él y es la complejidad en el manejo de las infraestructuras de TI. Lógicamente, repercute en el coste dado que a mayor complejidad mayor número de personas para gestionar los sistemas y, no olvidemos, el coste de personal de TI es una de las partidas más importantes -y necesarias- de gasto en la gestión de un CPD.

El siguiente gráfico muestra la previsión realizada en 2007 por IDC respecto a cómo aumentan los gastos de TI a medida que aumenta la base instalada, es decir, el número de servidores. Se observa que tanto el gasto en servidores como el gasto en energía permanecen relativamente constantes mientras que el gasto de gestión y administración (personal, básicamente) aumentan de forma muy importante.

Consumo de energía en sistemas de TI

Sin embargo, la previsión de IDC no era del todo acertada dado que la virtualización de hardware ha conseguido contener esos incrementos de forma muy notable.

Del mismo modo, el buen hacer de los responsables de infraestructuras han hecho que los servidores, lejos de proliferar, hayan reducido su número de forma drástica en los CPDs. Es muy habitual hoy en día tener entornos de base de datos o servidores de aplicaciones totalmente centralizados sobre una única infraestructura para toda la organización.

Un ejemplo muy evidente del cambio hacia la centralización en el entorno de servidores es el paso dado por Oracle con su Database Machine (Exadata). Oracle centró su estrategia durante años en los sistemas basados en grid. Todo debía estar en muchos nodos, pequeños, pero abundantes en número. Ahora propugna un cambio de paradigma con Exadata según el cual toda la gestión de BBDD debe estar centralizada en una única máquina en la que la propia Oracle provee el software, capacidad de procesamiento, almacenamiento y comunicaciones. Cualquiera diría que Oracle está intentando reinventar el mainframe sobre hardware de servidores.


Corolario

Aunque a IBM no le gusta demasiado dar las cifras del número de mainframes que están en línea, algunos estudios apuntan a que el número de máquinas se sitúa en torno a las 10.000 a nivel mundial. Nunca hubo tantas como ahora..., ni tan pocas como ahora. Básicamente, porque el número está estancado desde hace casi dos décadas.

El concepto de resiliencia unido a los enormes costes de arrastre en forma de migraciones masivas de aplicaciones hace que los proyectos de migración de los mainframes se encuentren en muchos casos en lo que un físico denominaría equilibrio inestable.

Los servidores son cada vez más estables y seguros. Es cierto, los mainframes lo son aún más pero cualquier organización mide los riesgos y después elige la posición más óptima respecto a ellos. Y en esa elección los costes son una de las piezas clave a la hora de determinar qué riesgos se pueden asumir y cuáles no.

Los mainframes no van a desaparecer. Todos los profetas (IDG, Gartner, Forrester, ...) anunciaron su muerte durante años y, obviamente, se equivocaron. Pero creo que a día de hoy hay hardware y software que puede competir de igual a igual con la seguridad y resiliencia de los mainframes igualando o superándoles en el resto de valoraciones. La batalla por el mercado de los mainframes menores de 2.000 MIPS, donde están probablemente más del 50%, ya ha comenzado.


www.tonsofit.com


RSS

El técnico de sistemas perfecto



RSS

No hay que fijarse demasiado para distinguir con claridad dos tipos de técnicos de sistemas radicalmente diferentes: los técnicos de sistemas host o mainframe IBM y los técnicos de sistemas Windows y Linux. Veamos sus características principales.

Los técnicos de sistemas host son personas altamente reflexivas que analizan cualquier detalle, por mínimo que sea, antes de llevar a cabo cualquier operación. Pueden estar trabajando en el diseño de un proceso durante días sin llegar a tocar máquina, no aceptan fallos de máquina que no tengan una explicación lógica y descartan la improvisación como un modo válido de realizar las cosas. Como contrapartida, no son personas demasiado dinámicas y, en general, prefieren trabajar en serie atacando los problemas de uno en uno.

A su vez, los técnicos de sistemas Windows y Linux son personas muy dinámicas, en ocasiones impacientes, tienen la capacidad de trabajar en varios proyectos en paralelo y a menudo utilizando la técnica del ensayo-error. En ocasiones sus planteamientos no son excesivamente reflexivos aunque lo compensan con una enorme capacidad de improvisación.

¿Quiere esto decir que los técnicos de Windows y Linux son irreflexivos o que los técnicos de host son pasivos? En absoluto, simplemente se describe la característica principal que segmenta e identifica a cada colectivo, lo que no implica que las demás características no se den.


Puede que la genética tenga algo que ver

Enlaces y secuencias genéticas
Los genetistas, bioquímicos y neurólogos parecen coincidir en que nuestra forma de ser y nuestras emociones están determinadas por nuestras hormonas.

Nuestra cantidad de cuatro hormonas, estrógeno, testosterona, dopamina y serotonina, determinan si seremos intuitivos y sociales, analíticos y lógicos, inquietos y optimistas o serenos y organizados respectivamente.

Este planteamiento induce a pensar que los técnicos de sistemas de host han desarrollado su carrera profesional en un ambiente en el que se fomentaba la testosterona y la serotonina, mientras que los técnicos de sistemas Windows y Linux han crecido profesionalmente fomentando mayores dosis de estrógeno y dopamina.

Porque pese a que todos nacemos con una carga genética que nos 'condena' a un determinado ratio de cada hormona, no es menos cierto que la plasticidad del cerebro nos permite aprender y educar nuestra forma de ser lo que, en definitiva, implica variar la preponderancia de una u otra hormona. Y ahí la cultura de la empresa en la que se trabaja tiene mucho que decir.


La cultura de empresa. Los técnicos de sistemas de mainframe

Técnicos de sistemas de IBM
Primera foto que aparece al buscar "técnico de IBM" en Google
Vayamos a los extremos. En un extremo está la división de mainframe de IBM y sus técnicos de bata blanca.

Su principal objetivo era, y sigue siendo, la estabilidad de los sistemas. Analizan cualquier detalle de la operatoria de la máquina y no dudan ni un segundo en reportar al laboratorio cualquier comportamiento no correcto.

Cualquier trap de la máquina es inmediatamente volcado para que los especialistas analicen el problema y den una solución.

Y eso ocurre incluso teniendo en cuenta que casi la mitad del código del sistema operativo zOS tiene como única misión recuperarse de forma autónoma de situaciones no previstas (probablemente, el código destinado a estas funciones en Windows o Linux no llegue ni al uno por ciento).

IBM colaboraba con esta cultura al mantener un cierto estatus de distanciamiento. Los técnicos de System z (antes 390) trabajaban, o eso se hacía creer, en tareas cuasi-esotéricas muy alejadas del entendimiento del resto de los mortales.

Curiosamente, este mismo efecto no se da en el resto de familias de IBM como xSeries, pSeries o iSeries (en este último caso en parte) que son muchos más similares al extremo contrario.


El otro extremo. Los técnicos de sistemas Windows y Linux

Siguiente, siguiente, siguiente
En el lado contrario está Microsoft y su filosofía de "Instalar - Siguiente - Siguiente - Siguiente": Se puede instalar cualquier software en la máquina y si no va bien se desinstala y listo. Si se produce un trap no se duda en reiniciar de forma inmediata en la confianza de que no hay nada mejor que un buen reinicio de vez en cuando: se auto convencen de ello.

De hecho, no conozco a ningún técnico de sistemas Windows o Linux que haya enviado un volcado de memoria para su análisis y consiguiente solución (no digo que no exista, digo que no le conozco).


La cultura de empresa fomenta la posición

Durante la conferencia 2009 de grandes clientes, Microsoft proyectó un vídeo en el que un niño de no más de diez años administraba el Directorio Activo de una compañía. Microsoft, probablemente, quería enviar el mensaje de la sencillez, algo que no es necesario al estar ya posicionado como una empresa que hace productos con una gran usabilidad. Como 'daño colateral', sin darse cuenta, la propia Microsoft colabora a esa cultura del todo vale dado que ¿hay algo más irreflexivo que permitir que un niño administre una infraestructura crítica como es el LDAP?

Estas diferencias entre unos y otros técnicos de sistemas fueron y son quizá la causa del escaso éxito comercial de Windows Datacenter, un sistema operativo hecho con tecnología Windows pero con procedimientos de uso propios de sistemas mainframe. A los técnicos de sistemas Windows no les subyuga la idea de tener que solicitar autorización a Microsoft antes de instalar un nuevo producto o versión de software. Algo está cambiando en Microsoft en este sentido pero no les será fácil deshacerse de una mochila tan pesada arrastrada durante tantos años.

Gadgeto-técnico de sistemas
La comunidad de administradores de sistemas Linux ha heredado e incluso fomentado esta forma de hacer de Microsoft hasta tal punto que es muy complejo distinguir a unos de otros (más allá de los evidentes rasgos físicos que en ocasiones parecen casi étnicos).

En el punto central de la balanza están empresas como Oracle que, centrada tradicionalmente en el mercado de las bases de datos donde la estabilidad es uno de los pilares fundamentales, ha sabido crear una cultura de gran dinamismo. Es decir, ha sabido conjugar ambas posturas de una forma muy acertada. Ahora tiene por delante el gran reto de absorber al personal de Sun, probablemente más cercano 'socialmente' a la forma de hacer de Windows y Linux (que le pregunten a los programadores sobre la estabilidad de las máquinas virtuales Java...).

Otra compañía que ha sabido conjugar excelentemente ambos roles ha sido HP tras su fusión con Compaq. En este caso, Compaq, que traía la carga de serotonina de Digital, ha tenido una gran simbiosis con la dopamina de la HP original. Todo ello, a costa de algunas fricciones internas tras unir dos formas de hacer tan diferentes.


Las características del futuro técnico de sistemas

Ambos tipos de perfiles son necesarios y la obligación de cualquier responsable de sistemas será la de llegar a un punto de equilibrio entre ambos tipos de profesionales. Bien sea por razones genéticas, bien sea por la nefasta gestión de la división mainframe de IBM en la relación con las universidades (¿alguien conocen alguna universidad que incluya en sus temarios el estudio de la tecnología hardware o software del mainframe IBM?), todo apunta a que en el futuro no será el modelo IBM mainframe el que prevalezca o no al menos el que 'venga de fábrica'.

Las nuevas generaciones llegan con una gran experiencia en la forma de hacer de Windows y Linux y el principal objetivo al incorporarlos al mercado laboral será el de conseguir que interioricen la disponibilidad de los sistemas como un valor indispensable de su trabajo. Algo que en los técnicos de mainframe venía de serie.

El técnico de sistemas perfecto, al margen de los conocimientos técnicos, será aquel que tenga una mezcla apropiada de estrógenos, serotonina, dopamina y testosterona y que, por tanto, interiorice la disponibilidad y la seguridad como valores fundamentales al tiempo que mantenga un grado de dinamismo, capacidad para la innovación e incluso en ocasiones para la improvisación.

Los genetistas tal vez piensen que hay poco que hacer dado que ese código está escrito es nuestras secuencias de ADN. Pero los evolucionistas nos dicen que es más que probable que con una buena cultura de empresa las disfunciones iniciales se corrijan en la mayor parte de los casos. A fin de cuentas, los genetistas también aseguran que hay relación entre la masculinidad (o feminidad) y la diferencia de tamaño entre los dedos anular e índice... pero eso es otra historia.

Nota: Léase con una buena dosis de humor. Cualquier intento de identificar y relacionar personas concretas con los ratios de hormonas expresadas es mera casualidad. Y no lleve a cabo esa correlación si no quiere que nadie lo haga con usted. ;-)


www.tonsofit.com


RSS

Los contenidos de Tons of IT están sujetos a licencia Creative Commons Reconocimiento 3.0 salvo donde se indique lo contrario.