"La Lección de Anatomía del Dr. Nicolás Tulp". Óleo sobre lienzo del pintor holandés Rembrandt (1632)

 Dice  el dicho que "los pingos se muestran en la cancha". Y yo espero con este post darte esos pingos para que los puedas mostrar

Porque si a vos te pasó lo que a mí, muchas veces habrás sentido que te veían como un gurú, un capo que se las sabía todas, pero en realidad tu único mérito era que te sabías muchas cosas que la mayoría no sabía. Pero de ahí a sabertelas todas... Ojalá! Quién puede saber de absolutamente todo en esto si es gigante!? Bueno, pero por lo menos que los demás se lo sigan creyendo todo lo que pueda durar...

Cuestión que, a la corta o a la larga, puede saltar una de esas peludas-peludas que te van a quedar grande incluso a vos, y ahí los demás pueden entrar a descubrirte tus límites, tus vulnerabilidades. A mí me pasó, en mis Java days, con cuestiones internas del manejo de memoria de la Java Virtual Machine (la JVM, o el equivalente del Common Language Runtime o CLR en .NET); me volvió a pasar con condiciones de carrera en ejecuciones de multihilos (multithreading); me pasó de nuevo con un bardo que saltó debido al ciclo de vida de clases estáticas y de nuevo me tumbó con otro bolonqui que saltaba con métodos sincronizados en un servidor Apache, que hacía que se encolen los requerimientos HTTP por minutos

Y varios se preguntaban "y éste era el famoso arquitecto!?". Y lógico, uno creía que entendía pero cuando las cosas salían mal, en todas las marañas de código creadas por cincuenta desarrolladores en distintos tiempos, era muy difícil saber en el día qué era lo que pudiera estar fallando. Y lo peor: no había a quién preguntarle. Todos esperaban que uno lo supiera

Bueno, espero con esto evitarte que te pase a vos lo que me pasó a mí con esas cosillas de bajo nivel que tiene .NET, que es ideal que los arquitectos conozcan para alguna eventualidad aunque mucho más ideal es que nunca vayan a necesitar tener que usar este conocimiento. Entro a tirar una serie de situaciones o preguntas

• Qué hace el CLR con el código intermedio que viene en los ensamblados (las .dll)? Qué es el Just-in-time compiling y qué tipo de código se genera? Dónde va a parar?
• Cómo se asigna la memoria para los objetos? Cómo la libera el Garbage Collector y cuándo? Cómo decide qué liberar primero?
• Cómo se maneja la liberación de memoria si hay objetos que se referencian circularmente aunque ningún otro objeto en la aplicación esté referenciando ya a ninguno de ellos?
• Con las clases estáticas? En qué las trata diferente el CLR? Qué tipo de memoria ocupan?
• Cuando se instancia un objeto de una clase, en qué tipo de memoria está la lógica de sus métodos y en qué sus propiedades? La memoria ocupada por la lógica de sus métodos se maneja a nivel de instancia o de clase?

Parecen todas pregus de bajo nivel. Y lo son, en realidad. Ahora, decime. Nunca te tocó enfrentarte a un problema y en ese momento querer conocer la respuesta a alguna de estas preguntas?

Bueno, hay un par de recursos bastante interesantes acá:

• El primero es un artículo que mi buen amigo Hanu Kommalapati (arquitecto de Microsoft, pero grosso en serio eh? No un ladri como yo...) escribió para MSDN Magazine, allá por Mayo del 2005 (mirá si tuvimos tiempo para leerlo eh? La pucha...!): Penetrando en el Interior de la Plataforma .NET para Ver Cómo el CLR Crea los Objetos en Tiempo de Ejecución. Es muy muy bajo nivel pero yo conozco a varios archis que se babean con estas cosas
  http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/
  
• El otro recurso que te paso es una sesión que Jeffrey Richter dio en el TechEd del 2005, llamada justamente .NET Framework: CLR Internals. Re-ve-la-do-rí-si-ma. Llena de demos, desensamblado de componentes, espiadas al código generado, a los algoritmos del Garbage Collector... Desesperantemente buena
  http://www.microsoft.com/seminar/en/DEV424_files/default.htm#nopreload=1

Fig. 1 - Ejemplo de la pila de ejecución (stack) y de los
diversos heaps (montículos de memoria)

Si, como yo, sos de los que nunca vas a dejar el chupete de escribir código, acá tenés para entretenerte un rato mirando a la plataforma .NET desfilar en lencería eróstica...

Otras Referencias
Colgándome del comentario que me hizo Hänschen al primer borrador publicado de este post, pongo acá una lista de libros que encontré sobre .NET desde el lado de adentro

	Essential .NET, Volume I: The Common Language Runtime Don Box con Chris Sells (Addison Wesley Professional, 2003)
	CLR via C#, Second Edition Jeffrey Richter (Wintellect) (Microsoft Press, 2006)
	Customizing the Microsoft® .NET Framework Common Language Runtime Steven Pratschner (Microsoft Press, 2005)
	Shared Source CLI Essentials David Stutz, Ted Neward, Geoff Shilling (O'Reilly, 2003)

(Este es el primero de una serie de tres artículos sobre Sistemas de Misión Crítica. En esta ocasión nos vamos a referir a los Acuerdos de Nivel de Servicio entre usuarios de tecnología y proveedores tecnológicos, y de cómo medir el cumplimiento de los mismos)

 Normalmente  las necesidades que llevaron al surgimiento de la "Arquitectura de Software" como disciplina dentro de la Ingeniería de Software tienen que ver más con la continuidad operacional de los negocios soportados por software, que por las Ciencias de la Computación en sí mismas

Ejemplos: la necesidad de abaratar costos de mantenimiento posterior; la necesidad de poder intercambiar mañana piezas sin quedar atado a decisiones previas, tomadas -claro está- en momentos en que el porvernir era difícil de precisar; la necesidad de eficientizar en forma conjunta el consumo de memoria, cómputo de CPU y ancho de banda utilizado en la red; y tantas otras

El hecho es que los negocios existieron desde mucho antes que la Informática fuera creada y comoditizada (es decir, en otras palabras, accesible para una mayoría a costos no privativos). Sin embargo, la irrupción de la tecnología informática en general, y de la industria del software en particular, potenciaron la forma de hacer negocios, llevando a estos a una escala inimaginable en períodos previos al surgimiento. Esto a veces cuesta un poco de entender: si los negocios, las industrias habían sido creados previamente, cómo es posible que la no disponibilidad total o parcial de una determinada tecnología pueda impactar en los resultados de algo que no dependió originalmente de la misma?

Sencillo de explicar: qué hacés hoy si se corta la luz en tu zona y en un radio de 50 kilómetros a la redonda? Te querés matar, no? No podés estar en tu casa ni podés ir a ningún lugar cerca porque estás en la misma. Y sin embargo la luz eléctrica fue aplicada en forma masiva hace menos de 200 años. Cómo hacían antes para no estar de mal humor? Simplemente se vivía distinto. Era otro contexto, otra expectativa y por lo tanto también se ponía otra energía en las cosas, acorde a este "sistema de coordenadas" limitado por aquel contexto

En el mundo de los negocios de hoy, entonces, se habla de misión crítica -o de sistemas de misión crítica- cuando la no disponibilidad, total o parcial, de los mismos afecta seriamente a los resultados de estos negocios. Te pasó ir al banco a querer abrir un depósito a plazo (un "plazo fijo", como se lo llama en Argentina) y que te digan "ahora no, estamos sin sistema"?
Qué hiciste ahí? Te fuiste a otro banco a terminar de hacer la transacción para no andar con la guita encima? Supongamos que sí. Qué le pasó al banco que estaba sin sistema desde el momento en que te fuiste? Se perdió de recibir plata, esa plata que a su vez el banco presta y por la que cobra una renta; renta de la que subsiste con una parte, y usa otra parte para pagarte a vos el interés de haber hecho el depósito a plazo

Al haberte ido sin hacer el depósito, el banco se pierde de prestar tu guita a un tercero, por ende renuncia a cobrar la renta por el servicio de la deuda y, en definitiva, a ganar plata. Eso es, entonces, un "Sistema de Misión Crítica": es un sistema cuya no disponibilidad total o parcial termina afectando negativamente las utilidades de un dado negocio. Y te voy anticipando antes de seguir qué es lo que pasa si en un negocio deja de entrar plata por un problema de los sistemas. Si eso se prolonga en el tiempo lo más probable es que empiece a salir cierta gente del área de Sistemas para desbloquear el paso y posibilitar que la plata vuelva a entrar al negocio. Capisce? Sabía que me ibas a entender: no es que los negocios hoy puedan subsistir sin los sistemas, pero si es claro que el área de Sistemas va a subsistir en la medida en que el negocio lo haga (y si no explicame por qué, si te toca trabajar de 9 a 6 de la tarde, hay días que ya son más de las 9 de la noche y todavía estas dando vueltas ahí adentro) sin una hora estimada de fin de actividades

Pero claro, entendida la definición, aceptada la magnitud del problema viene la pregunta: y a mí arquitecto qué? Qué debo saber / hacer / evitar para que la continuidad del negocio no se vea seriamente afectada -al menos, al punto de poner en riesgo mi pellejo-? En lo que sigue, te paso las claves de supervivencia. El enfoque que voy a tomar va a ir del nivel más alto, desde la perspectiva empresarial, hacia los inferiores (más vinculados con aplicaciones específicas y la infraestructura que soporta a las mismas)

Business are business (Negocios son negocios)
Como la que manda es la misión empresarial primaria de la organización, hay que empezar a abordar el problema desde los principales stakeholders (interesados) de esta función: los gerentes del negocio, analistas y usuarios en general. Es con estos interesados con quienes se debe establecer (y seguramente negociar) un Acuerdo de Nivel de Servicios (Service-Level Agreement o SLA). Y se parte del nivel más alto, menos técnico, ya que estos interesados no conocen demasiado (o no es mandatorio que conozcan) de las intricancias de nuestras tecnologías. Para ponerlo en palabras nuestras, podríamos usar el ámbito de los casos de uso o sus interacciones como marco de referencia. En este contexto, ejemplos típicos de SLAs pueden postular cosas tales como "pedir un estado de cuenta, una vez ingresado el número de cliente, no puede demorar más de 20 segundos" o -en el caso de una telco, por ejemplo- "el alta del servicio de telefonía básica, una vez ingresado al sistema la conformidad del cliente y todos sus datos para la facturación, no puede demorar más de 30 minutos"
Los Acuerdos de Nivel de Servicios, en muchos casos, establecen compromisos mutuos. Por ejemplo, el caso anterior de la telco, quizás hace falta verificar cierta información del cliente para constatar veracidad o historia de morosidad, y esos procesos pueden ser semi automáticos. Si son semi automáticos, quiere decir que el otro lado del semi es manual, y si es semi manual, tené claro que no es la gente de tecnología la que va a ejecutar esa parte manual. El negocio sigue mandando, por lo que acá los mismos stakeholders van a tener que cumplir buena parte del acuerdo, y no reclamar al área de tecnología por esas demoras
Ahora, la parte que les cabe a los operadores del negocio es un problema de ellos. El tema es, nosotros, cómo ir a la mesa de negociaciones con datos claros acerca de lo que somos capaces de proveer (por así decir, hasta dónde nos la bancamos). Y particularmente, para no dejar pintados a los hombres de negocios (lo cual es suicida de nuestra parte), ser claros en lo que necesitamos para, desde la tecnología, brindar el nivel de servicios que ellos esperan para con los clientes
La "precisa" nos la va a dar la Administración de Capacidades (Capacity Management) que es un proceso iterativo y abarcador. Iterativo porque no termina (sino que, en todo caso, se abandona) y abarcador porque para saber hasta dónde la tecnología es capaz de soportar niveles de servicio del negocio, es preciso conocer que niveles de servicio la tecnología misma es capaz de brinda (por ejemplo, accesos a la base de datos cuánto demoran, qué ancho de banda tenemos disponible, cuántos usuarios concurrentes somos capaces de soportar y qué configuración necesitaríamos para soportar más o mejorar los tiempos de respuesta, etc)

Figura 1- Administración de Capacidades
como un proceso contínuo

Ahora bien, ninguna bola de cristal hace falta conseguir acá. Microsoft Operations Framework (MOF) es una guía que aglutina prácticas para llevar desde la Gerencia de Tecnología hacia los níveles inferiores de la misma, impactando en las actividades de todos sus integrantes. MOF se compone de cuadrantes: Optimización, Cambios, Operación y Soporte

 
Figura 2- Cómo se integra Microsoft
Operations Framework (MOF) 

Particularmente el cuadrante de Optimización incluye guías para Administración de Nivel de Servicio (MOF Service Management Functions), entre las que aparece, entre otras, la Administración de Capacidades (Capacity Management) que te comenté. Asimismo, cada producto de la familia Microsoft te ofrece sus propias herramientas para planificación de capacidades; herramientas éstas que deberías usar dentro de un proceso MOF

Monitoreo de Actividades
Ahora, esto es obviamente un proceso. Una vez que las capacidades han sido establecidas, los SLAs han sido negociados... cómo verificar el efectivo cumplimiento en forma automatizada? Cómo saber, en tiempo real, que el alta de un servicio a un cliente lleva atascado más de dos horas? O cómo saber, incluso al lunes siguiente de un fin de semana, que el proceso de altas dejó de funcionar por x tiempo? Cómo conocer esas cosas al momento en que ocurren o incluso llevar la estadística de cuántas veces ocurrieron?
Para esto, lo que se hace es establecer umbrales basados, justamente, en los SLA definidos. Pero estos umbrales se descomponen en dos niveles: nivel de negocio y nivel de infraestructura. Porque no es lo mismo hablar del proceso de negocio que transfiere dinero de una cuenta a otra (y que para eso lleva determinado workflow) que el proceso de más bajo nivel que accede a una base de datos u otro servicio remoto para invocar determinada transacción
En la arquitectura Microsoft, los umbrales de negocio se monitorean mediante una facilidad incluída en Biztalk Server 2006, llamada Business Activity Monitoring (BAM, por Monitoreo de Actividad de Negocio)

Figura 3 - Arquitectura del motor de Monitoreo de Actividad
de Negocio de Biztalk Server 2006

BAM habilita a especificar eventos que se disparan a medida que las actividades van sucediendo. Estos eventos sirven para actualizar indicadores que luego pueden ser analizados desde el portal de BAM o exportados a Excel (o también, mediante SQL Server Notification Services, enviados a aplicaciones externas)
Biztalk 2006 también incluye un monitoreador similar pero para servicios provistos por terceros: me estoy refiriendo a Business Activity Services (BAS). Ambas facilidades, BAM y BAS, están pensadas más desde el punto de vista del usuario que de la gente de tecnología
En gran medida, hablando en términos agnósticos de la plataforma, estas facilidades de monitoreo le son conferidas el Bus de Servicios Empresariales (Enterprise Service Bus o ESB) en una Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA). Al respecto, Lukas Cudridge ofreció una presentación acerca de cómo montar un ESB en la plataforma Microsoft (particularmente en torno de Biztalk Server 2006). Esa sesión está disponible para descarga acá. También, en la pasada conferencia sobre SOA y Procesos de Negocios que Microsoft brindó en Redmond en Octubre pasado, se anunció el lanzamiento del ESB Toolkit, mayormente basado en los conceptos de la sesión que te comento (según averigüé, este ESB Toolkit se encuentra ya en fase de testing)

Monitoreo de Procesos Sistémicos
Las actividades de negocio se apoyan en procesos tecnológicos. Los mismos ya no deben ser monitoreados por usuarios sino por operadores y expertos del área de tecnología. Para ello, hacen falta herramientas que permitan diagnosticar con precisión problemas de seguridad, bajo ancho de banda, de acceso a volúmenes de datos, de denegación de servicio o bajo rendimiento en general. Existe una herramienta capaz de hacer eso? Claro, que existe. Se vino llamando durante años Microsoft Operations Manager (MOM), que actualmente va por su versión MOM 2005, pero en el roadmap está previsto embeberlo definitivamente a la estrategia Microsoft System Center, por lo que su nombre pasará a ser System Center Operations Manager 2007, y ya va por su Release Candidate 2!!

Figura 4 - Consola de Operador de MOM 2005

Querés echar un vistazo rápido a MOM 2005 en acción? No te pierdas esta demo (click acá). Ahí vas a ver que MOM es capaz de suscribirse a eventos tanto del sistema operativo como eventos lanzados por aplicaciones (MS Exchange, SQL Server, etc). Una vez que los recibe, es capaz de lanzar notificaciones vía mail, paging o mecanismos extensivos (claro, al operador que tenga que recibir esos mensajes y actuar en consecuencia no le debe causar ninguna gracia que MOM sea capaz de ubicarlo, pero en términos de la misión crítica y el negocio, enhorabuena)
Lo más interesante de MOM, si sos desarrollador de aplicaciones .NET, es que tenés la posibilidad de dotar a tu aplicación de elementos que la habiliten a ser monitoreadas por MOM (a esto me voy a referir en un post por llegar). Esto quiere decir que desde una única consola de operador es posible monitorear la salud de todo el portfolio de sistemas de la organización

Estimados, voy a parar acá. Esta serie de "Misión Crítica" va a contener una segunda parte explicando estrategias del punto de vista del desarrollo de aplicaciones, para que sean aptas para la misión crítica. En una tercera parte voy a explicar las herramientas que tienen a mano los arquitectos de infraestructura, sea para distribuir carga y hacer a los sistemas escalables, como para prevención y recupero de información ante desastres. Hasta entonces

 Para  mitad de año proyectamos hacer el TechEd 2007 en Orlando, Florida (EEUU) por lo que estamos convocando a speakers expertos para ofrecer sesiones de Arquitectura, así que esperamos que esto te pueda interesar (e inspirar! )

• Desarrollo
• Distribución (deployment)
• Aplicaciones móviles
• Seguridad y
• Administración

 Nos complace invitarte para que envíes una propuesta de sesión no más allá del 24 de Enero de 2007

Querés saber más acerca de en qué consisten estas sesiones (breakout sessions)?

• Tipicamente consisten en 60 minutos de presentación con demos, seguidas de 15 minutos de preguntas y respuestas. Esto totaliza 75 minutos
   
• Debe ser técnica por naturaleza, y aún así considerar la amplitud en las diferentes visiones de arquitectura de los asistentes
   
• Se clasifica de acuerdo a los siguientes niveles:
• Nivel 200: Revisión tecnológica, introducción técnica, se muestra algo de código
• Nivel 300: Intermedio entre Arquitectura y Desarrollo, se expone más código
• Nivel 400: Código avanzado, arquitectura en profundidad, bajada a detalle
• Puede derivar en un "chalk talk", con el orador participando en un panel como experto en el tópico abordado

Si tu propuesta es seleccionada, Microsoft te paga el viaje, alojamiento y comida, el pase a la conferencia, y también te da una remuneración (esto último aplica sólo si no sos empleado de Microsoft)

Si estás interesado en postular un tema para considerar, por favor seguí los pasos de acá abajo

Pasos para Postular

1. Ir al sitio de postulantes: https://2007.msteched.com/cft/
2. Vas a encontrar un campo para ingresar un código de acceso (access code), poné ARC_432
3. Vas a pasar a una pantalla donde vas a tener que crear un perfil personal, el que te va a habilitar a volver siempre que quieras editar tus postulaciones
4. Completá (en inglés, claro) tu propuesta llenando el formulario y presioná el botón de SUBMIT. Te va a hacer pasar a una pantalla de confirmación. Revisá que esté todo, que no falte nada porque lo que quede ahí es lo que nos va a llegar a nosotros
5. Las propuestas deben ser ingresadas hasta el día 24 de Enero de 2007
6. El día 15 de Abril de 2007 se te va a notificar si tu sesión fue aceptada o no

Espero que estés dispuesto a compartir tu sabiduría en TechEd 2007 y quedo a la espera de tu postulación!

Fechas para Agendar

• 24 de Enero: último día de recepción de propuestas
• 15 de Abril: comunicación de aprobación o rechazo
• 4 al 8 de Junio: TechEd 2007 en Orlando, Florida (EEUU)

"Nunca la vida es tan precisa
Nadie tiene esa fija
Que te saca del montón
Y te muestra algo mejor"
(Fragmento de "Desconexión sideral",
Bersuit Vergarabat, 2001)

 Supongamos  que hiciste un generador de código que, dado como input el string de conexión a una base de datos, es capaz de generarte clases que mapean las tablas relacionales y contienen ya toda la lógica CRUD (por create, retrieve, update, delete) incluyendo ciertas validaciones basadas en los constraints (condicionamientos) del RDBMS (manejador de base de datos) que tu generador es capaz de detectar. Siempre suponiendo, imaginémonos que incluyendo accesos específicos a la base de datos para recuperar esos constraints y generar código que contemple los mismos (y enmascare errores o evite round-trips innecesarios a la base), el generador crea y compila una clase basada en una tabla en 1'23'' (un minuto veintitrés segundos)

Si tu base de datos tiene sesenta (60) tablas y el generador va a generar lógica para todas ellas, una atrás de la otra en forma secuencial, en cuánto tiempo generó las sesenta clases?

Acostumbrados, como nos enseñaron desde chicos, a razonar en forma aritmética y lógica, para responder a la pregunta de recién la mayoría de nosotros va a querer aplicar la regla de tres simple que nos enseñaban al terminar la primaria:

"Si x me cuesta k, y me costará yk/x"

Especializando la regla de tres a este caso,

x = 1, k = 1'23'', y = 60

Por consiguiente, la respuesta es 60x1'23'', igual a... igual a... dejame pensar... un minuto por sesenta da una hora, y veintitrés segundos por sesenta... ché, nadie tiene una maquinita!? A ver, vos, fijate si con el Excel ahí me podés hacer esta cuenta... Pero mirá que tenés que redondear, eh? Porque es una cuenta de tiempo, y si te pasás de sesenta tenés que convertir eso a minutos y agregarselo a los minutos... un bardo...

No, el bardo no es la cuenta redondeando tiempos. El bardo es no apiolarte que estás multiplicando justo por 60: la base del sistema sexagesimal que se usa para medir el tiempo. Entonces, sin calculadora ni Excel ni redondeos ni nada te digo

Rta: tu generador de código va a generar lógica para las sesenta tablas en una hora veintitrés minutos (1h 23', es decir, queda todo como está excepto que los minutos ahora son horas y, los segundos, minutos)

Estaba mal hacer la cuenta en serio? No, no estaba mal pero como en muchos casos se suele dar, te lleva a la solución por un camino predecible, de final conocido, aunque más largo que caminos alternativos que simplemente desechamos por falta de creatividad. Y no es que no seamos creativos! Seguro que varios de los que nos mandamos a contestar por el camino largo, solemos ser creativos ante aquellos problemas que claramente requieren de una solución original

En cambio, frente a situaciones donde una solución conocida es aplicable, echamos mano a la misma sin complicarnos la vida con divagaciones metafísicas, aunque -como en este caso- el camino optado era indudablemente más complejo que el que consideraba que se estaba multiplicando por la base del sistema de medición

Y es que la gran pregunta que todos nos debemos hacer es... si aplicar una solución creativa puede salir más barato que una solución aritmético/lógica conocida... cuánto más caro pueda ser encontrar rápido esa solución creativa?

Y es verdad. Ser original es ante todo una manifestación de deseo, todos nosotros por momentos nos creémos que somos innovadores, creativos -o te lo terminan haciendo creer quienes admiran lo que hacés-, hasta que te enfrentan a una situación donde se te explicita "dale, ahora usá tu creatividad y resolvé este balurdo". Y zás... te bloqueás. Te tarás. No se te ocurre un soto, una porque están todos mirandote y otra porque te da miedo de decir una ganzada bajo presión y que a partir de ahí empiecen a desconfiar de tus habilidades

Pero la buena noticia que te vengo a traer, es que hay alguien que estudio el orígen de la conducta creativa y concluyó que es posible laburar la croqueta para ser naturalmente creativo (y a la vez productivo) en todos los ámbitos (en el laburo, en la pareja, la familia, en la calle, el colectivo, etc)

El buena onda que nos dice "vamos que tú puedes!" se llama Edward de Bono (psicólogo maltés nacido en 1933). De Bono acuñó en 1967 el término "Pensamiento Lateral" ("Lateral Thinking") para referirse a un tipo de pensamiento alternativo a los paradigmas de razonamiento aritméticos y lógicos que nos enseñan desde chicos (de Bono los llama "pensamiento vertical"). Su objetivo no es abolir las formas de pensar tradicionales sino complementar y enriquecer a estas con nuevos estilos de pensamiento que, por no desarrollarlos, los tenemos atrofiados

El libro base en que enuncia todo esto se llama, sin romperse mucho el mate, "El Pensamiento Lateral" ("The Lateral Thinking") y es hasta el día de hoy un best-seller (el año 2010, o sea dentro de tres años, va a cumplir 40 años dicho material). En sus propias palabras

"En el pensamiento lateral se busca a veces información que nada tiene en común con el problema que se estudia; en el pensamiento vertical sólo se busca lo que está relacionado con dicho problema. (...) El pensamiento lateral no pretende sustituir al pensamiento vertical: ambos son necesarios en sus respectivos ámbitos y se complementan mutuamente; el primero es creativo, el segundo es selectivo"

En el libro destaca las actitudes hacia un desarrollo del pensamiento lateral y ofrece ciertas técnicas para comenzar a pensar de costado sin caerse. Estas técnicas, como contaba antes, hoy son seguidas por legiones de personas, en forma individual, o incluso a nivel organizacional, para mejorar la productividad de los resultados basados en la toma de decisiones

Existen, asimismo, infinidad de libros para ejercitar, fortalecer o al menos testear qué nivel de creatividad aplicamos para resolver problemas. En Argentina, particularmente, Ediciones de Mente lleva editados varios de estos libros que se suelen dividir en tres secciones

• Los acertijos a resolver
• Claves para orientar a los que, como yo, al principio no sabemos para dónde disparar
• Las soluciones (al fin)

De Bono escribió otro best-seller llamado "Seis Sombreros para Pensar" ("Six Thinking Hats", 1985), que merece la pena referirme en otro post. Lo único que voy a anticipar es que, para los que quieren ir de lleno y a full con el pensamiento lateral, se les sugiere comenzar entendiendo los mecanismos de pensamiento paralelo (los seis sombreros) con los que la mente opera

Quiero mostrar con otro ejemplo cómo el pensamiento lógico a veces nos lleva a pisar el palito (en realidad no es culpa del pensamiento vertical sino nuestra en cuanto al uso limitado que le damos): se nos pregunta si existiran dos números enteros que multiplicados entre sí den por resultado 11 (once). La primera reacción que yo tuve, desempolvando inmediatamente recuerdos de Álgebra de la facu, es que por ser 11 un número primo, no existen dos enteros diferentes de 1 y de sí mismo, (o sea 11) que sirvan de divisores del número. Con lo cual mi conclusión atolondrada fue "no, no existen". Y al revisar la respuesta me encontré "sí existen: 1 y 11 multiplicados entre sí dan por resultado 11". Gajes del oficio

En cambio está anécdota que te voy a contar ahora como cierre del post es mucho más impactante: al final de la Segunda Guerra Mundial, un equipo de técnicos de la aviación norteamericana estaba revisando aquellos aviones que habían logrado volver, con el fin de brindar recomendaciones para bajar la vulnerabilidad de los mismos en los futuros modelos. Casi todos ellos presentaban daños sustanciales en varias partes, y curiosamente había partes que no presentaban daños en ninguno de ellos. Todos los técnicos recomendaban reforzar aquellas partes que al menos en algún avión aparecían dañadas, comenzando antes por las que estaban dañadas en más aviones. Excepto uno sólo de ellos, que sugería reforzar aquellas partes que no presentaban daños en ninguno de los aviones, quizás también usando parte del presupuesto para reforzar esas partes que estaban averiadas en un número bajo de aviones

Su explicación? Lo que ellos estaban analizando no era el universo completo de la flota norteamericana, sino tan sólo aquellos aviones que consiguieron regresar. Por ende, existía evidencia en los mismos de que, aún con ciertas partes dañadas, esos aviones habían logrado volver. Esto le daba a pensar que aquellos aviones que sufrieron daños en las partes que estaban sanas en todos los que volvieron, fueron los que quedaron fuera de combate

PD: querés empezar ya a cebarte las neuronas con acertijos de ese estilo? Metete por acá, http://www.geocities.com/siliconvalley/pines/7894/acertijos.html, y dale las gracias a mi amiga Silvia (la ninjutsista Deianeira) que me arrimó ese link valiosísimo