Leyendo a Tanenbaum

Por andar rascando a temas de mainframe y anexas, acabe desenterrando el libro de Tanenbaum, Organización de Computadoras pero la segunda edición, de 1984.

Lo interesante, es que muchas personas del ramo de TI que se presumen arquitectos, deberín de leer este libro como ejemplo.

Sin presunción alguna, Tanenbaum se pone a trabajar en los diferentes niveles de la organización (arquitectura de computadoras) y metódicamente describe cada uno de ellos y explica muchas veces las decisiones que llevaron al diseño y las restricciones que presentan

Pues yo puedo decir, que gracias a que mi profesor de Arquitectura de Computadoras, tuve una visión del concepto de arquitectura. Me acuerdo que su definición de una arquitectura de computadora era la manera como se debe organizar los elementos de procesamiento de símbolos. Elegante definición, por que no se fue al nivel de bytes ni de hardware. Y lo interesante de esa definción, es que no solo cubre los niveles de hardware o firmware; sino de software; y como escribe Tanenbaum en su libro, el hardware y software pueden indiscriminadamente cambiar papeles.

Gracias a esa idea, cuando por primera vez tuve que hacer una arquitectura de solución, y de hecho sin tener precedentes teóricos del tema, salvo el ejemplo de arquitectura de computadoras; define la solución por bloques de procesamiento (como chips de software) que tenían una funcíon específica.

Algún para de años después me tope con que la disciplina de arquitectura en software era un tema extenso; pero por desgracia mal entendido.

Cerrando el tema con dos anécdotas.

En mi última asistencia al taller de Arquitectura Empresarial que impartió Cutter; me senté en una mesa, donde obvio, todos se decían arquitectos. Por un azar, una persona le dí clases en su momento y por cierto su compañero medio chistin (de los que dicen comentarios poco asertivos); y me dicen que trabajan para una sociedad de inversión algo conocida (y que también conozco por sus a veces erroneas percepcions en conceptos de CMMI, desarrollo, pruebas). Le pregunto a la persona en cuestión, estás en desarrollo? y pues hagan de cuenta que le dije una ofensa o la denigre, y también su expresión corporal mostro disgusto a lo que le insinue. Me contesto, como crees! Yo soy arquitecto empresarial! No me quiero imaginar que tipo de arquitecturas diseñaran ese par de personas, pero dudo que le sirva a los equipos de desarrollo. Un arquitecto es alguien que sabe de técnicas de desarrollo, de tecnología.

Otra mas, en el trabajo, se me acerca uno de los ingenieros de un proyecto "super importante" y me realizar preguntas sobre como hacer un tipo publish-suscribe con AJAX. Para no hacerles mas largo el cuento, le comento, pues hagan pruebas de concepto. Y a lo cual me contesta, pues es que el equipo de arquitectura es lógico, ellos no ven cuestiones de desarrollo.

Es decir, parece que mucha gente está tomando el concepto de arquitectura como si fuera la misma visión erronea de la gente de procesos o pruebas; que son gente que no acaban agregando valor y dibujando cajitas bien bonitas en PowerPoint o con herramientas más caras de "arquitectura"

Error muy malo. Lastima que no me aceptaron mi exposición para la Expo de Software Gurú, quería hacer un pequeño manifiesto de independencia hacia los susodichos arquitectos lógicos o de su torre de marfil, que según ellos con mucho estatus se dicen arquitecto, pero acaban no haciendo trabajando y metiendo confusiones

Me gustaría tomar a todos esos falsos arquitectos y sentarlos a estudiar los libros de Tanenbaum, a Date, a Patterson, Design Patterns de GoF, PoSA, EIP, el de compiladores de Aho, los 3 tomos de Knuth, un buen libro de referencia de mainframe; para que realmente tomen en cuenta todos los conceptos subyacentes para hacer una arquitectura sólida y no algo que acaba en papel y no da valor a los equipos de desarrollo.

Mis 2 únicos lectores, ojala me perdonen esta entrada poco objetiva, pero tenía que hacer cartasis escribiendo.

Con esto, me dan ganas de hacer el temario de un tipo diplomado de Arquitectura Empresarial y darlo gratis, como servicio a la comunidad de TI, donde pondría a estudiar a la gente en varios temas, y enseñarles que el título de arquitecto no se obtiene por que te nombren solo así, sino con humildad, experiencia, trabajo y conocimiento técnico.