martes, 24 de mayo de 2022

De transformación tecnológica en transformación

Hola queridos 3 lectores, hace mucho que dejamos su 3 autores abandonado este blog, pero nunca es tarde  para seguir dejando escrito lo que vamos viendo en este mundo llamado tecnologias de la Información.

Continuo en la Institucion de Salud, la más grande de latinoamerica, con otras responsabilidades, ahora del lado de la operacion que soporta todos los sistemas.

Hace poco tuve la visita de un amigo que platicando con él me decia que como he vivido estos años en esta institución y espontaneamente le dije de ola en ola, y le conte un poco de mi historia.

Aún recuerdo cuando por casualidad de la vida, llegue al mundo de los sistemas, fue por allá de 1994 cuando estudie el bachillerato tecnológico para "Técnico Programador Analista", y ahí empezó la magia con el "Hola Mundo" en COBOL y el 000100 IDENTIFICATION DIVISION.


En esos 3 años, empece a conocer COBOL, PASCAL, C y C++, cada uno con su encanto, en Sistemas Operativos conocí el MS-DOS y hasta programar en ventanas y eventos con clics en Visual Basic.

En poco tiempo me vi envuelto en la magia de una carrera llamada Ing. en Sistemas Computacionales ( en el glorioso Instituto Tecnológico de Pachuca), donde aprendí grandes cosas desde profundizar en matemáticas, estadísticas hasta electrónica, algoritmos, y "nuevas" tecnologias, pero sobre todo aprendí que por mucho que trates de ir al día, la tecnología avanza demasiado rápido y el dificil seguirle el paso.

Eso mismo pasa en la industria, en las empresas que invierten en tecnología para soportar sus procesos de negocio,. En el poco tiempo de experiencia que tengo en este mundo, he visto nacer grandes transformaciones digitales.

Si tratara de resumir lo que he visto de mi experiencia sobre transformaciones y tratando de hacer un escueto roadmap podría resumir algo así:

PROCESAMIENTO BACK OFFICE ---> CLIENTE SERVIDOR ---> SERVIDORES DE APLICACIONES ---> INTEGRACIÓN DE SERVICIOS ----> DIGITALIZACIÓN ---> SERVICIOS EN NUBE ---> CONTENEDORES

En ese pequeño roadmap, muchas tecnologías han emergido como lideres desde los 70's a nuestros días, desde IBM  Mainframe, HP Tandems, SPARCs, X86, Servicios de Nube, Contenedores, Microservicios y sin mencionar los diversos lenguajes de desarrollo.

Como en el mar la vida es mas sabrosa, le he bautizado olas de Transformación Tecnológica, a lo que me ha tocado vivir y por raro que parezca siempre observo que lo de moda es los "LEGADOS" y como usas esa información para REUTILIZARLOS o REEMPLAZARLOS con las "nuevas" tecnologías.

El ritmo con el que avanza la tecnología y los visionarios tecnológicos demandan nuevas cosas es muy rápido, en ciclos promedio en 6 años lo nuevo se vuelve legado y lo legado obsoleto, y sin embargo... se mueve.

El mantener los legados es un tema de alto costo para las empresas, ya que debes de manejar contratos extendidos de soporte y tener demasiados especialistas para atender las necesidades que aun en fechas recientes el negocio te demanda.

En fin, el conclusión, creo que debemos de aprender a vivir con este ritmo y construir en la actualizad soluciones robustas que soporten el paso del tiempo cuando estas se vuelvan un legado... así como  subirse y de ser posible dirigir los ciclos de transformación tecnológica que estamos pasando en cada una de sus empresas o instituciones.

Saludos

lunes, 30 de septiembre de 2013

En el 2013 que ha pasado

Bien, pues este blog fue terriblemente abandonado por todos sus autores , je Aunque les digo, que los tres autores siguen vivos y coleando El Tuzo sigue en la institución de salud que yo deje en julio 2012. Chillicoder sigue pegando duro a Rails ... Técnicamente que ha pasado por mi vida de bytes He aprendido Node.js Me he metido a TOGAF y me he certificado, al igual que Archimate... Me adentre a ver los puntos de arquitectura de software y aterrizarlo con patrones de Fowler y POSA ... Y los MOOC me han ayudado mucho . Gracias a ellos se puede aterrizar el tema de Big Data, Programación funcional, arquitectura empresarial Estoy con deseo de un bocado de implantar una arquitectura empresarial que haga sentido a la organización que decida esa aventura ... No me he metido al asunto de emprendedores, aunque sigo de cerca varias ideas Gamification me inspira para algo así El tema de software factories aun no lo abandono como un concepto viable para implantar DSL, DDD, patrones SOA no reniego de ella, solo veo cuanto falta por rascar en el tema ... Sigo renegando de programadores, arquitectos y similares que son soberbios o que no hacen bien su chamba El Tuzo y otro nuevo amigo, Rafael Cruz, agregaron otra comunidad de arquitectura a la mexicana ...

domingo, 21 de octubre de 2012

No andaba muerto y ni andaba de parranda

Hola! Del grupo Tuzo, Martín, yo Gus me desaparecí por un rato muy prolongado. Por fin decidí plasmar algunas ideas ... En julio di mi brinco ya tan necesario y cambie de trabajo. Mi tiempo ya había acabado y a pesar de que mucho trabajo había por hacer aún, fue lo sano. Tuve muchos sentimientos encontrados pero ya estaba yo en una situación de agotamiento y estrés fuerte. Por un mes, en donde estuve explorando opciones, desde trabajar con un proveedor muy grande de software y patrocinador de los Avengers, en una farmaceutica, con una empresa de consultoría de procesos al final opté ingresara IT Era, para trabajar en temas de Arquitectura Empresarial. Ingresé el 16 de septiembre, no fue para mí desconocido el ambiente de trabajo. Me ha dado la oportunidad de ver TOGAF con mas detalle y explorar como aplicarlo. De hecho, regrese este viernes 19 de octubre de Quito, donde impartí el curso de TOGAF a un Banco de la región Pichincha. Fue una experiencia muy agradable, donde mi conocimiento fue útil. Tengo muchas ideas en mi cabeza sobre Arquitectura Empresarial. De hecho, me lleva a nuevas experiencias sobre integración a la Mexicana. Espero ser constante en escribir mis ideas en este blog

martes, 25 de septiembre de 2012

De vuelta a la actividad

Hola queridos 3 lectores,

Hasta hace unos meses me daba a la tarea de empaparme de conceptos de arquitectura empresarial, estudiando y leyendo con el fin de reforzar algunos proyectos que llevo a cabo, en esta ardua vida de búsqueda de oportunidades.

Me he topado en los últimos meses a diferentes retos tanto técnicos como laborales y de cada uno de ellos voy aprendiendo.

No había tenido oportunidad de agradecer a gusdelact por todo el apoyo que me brindo durante casi 8 anios de convivir juntos y enfrentar varias responsabilidades, he aprendido mucho de el, ha sido mi guru. En este largo camino de lo profesional te deseo mucha suerte mi estimado.

Ahora he quedado al mando por decirlo de una manera de un equipo de trabajo que sigue con la filosofia de este grupo de locos y eso me hace ser mucho mas responsable y cuidar al equipo. Sigo aprendiendo día con día que lo valioso que es el crecer tanto humanamente como profesionalmente para alimentarte de los buenos resultados.

Sigo aprendiendo que por mas que digas ser "algo" o saber de "algo" no vale mas que los hechos y el trabajo. Aprendo que a veces tienes que ver el traje del emperador aunque sea un poquito con tal de que te dejen trabajar. Aprendo que los "Pseudo Arquitectos"siguen siendo arrogantes y hasta tontos, pero que hay que lidiar con ellos. Creo en el trabajo y la honestidad de la gente que en verdad desea aprender por el deseo de hacerlo o no por el ego del saber.

Actualmente me encuentro con varios retos profesionales en mi institucion y fuera de ella cosas interesantes de TOGAF, de ALM, de SOA Reference, etc que les ire platicando poco a poco.

Espero nos vuelvan a leer y como dice un clásico ....

Por una integración mejor.

Hasta la vista

Tuzo



viernes, 19 de agosto de 2011

Primera fase de Arquitectura Empresarial, lista

Acabo mi día, reflexionando sobre el logro que tuvimos en mi equipo de trabajo

Gracias al entendimiento de modelos como TOGAF y Archimate, las diversas opiniones de los integrantes del equipo; logramos una versión de un repositorio de Arquitectura empresarial con un empuje inicial muy bueno.

Representa el salir de la teoría a la práctica

El demostrar que un "arquitecto" no es titulo nobiliario, sino se gana con trabajo

Acabamos celebrando, comiendo pizza, como una fraternidad, que nos une un interés común. Mejorar nuestro ámbito

Me daré tiempo para platicar los detalles técnicos

domingo, 31 de julio de 2011

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.

jueves, 28 de julio de 2011

Domain Specific Languages (DSL) primer comentario

Para mi el concepto de DSL no fue dificil de entender, ya que desde hace casi 2 decadas me tope con ese concepto con un libro de Bertrand Meyer, llamado Introduction to the Theory of Programming Languages

En ese libro, Meyer expone los conceptos "básicos" para diseñar un lenguaje de programación, no se enfoca a decir como definir la sintáxis o los algoritmos de anális sintáctico. Se enfoca a explicar que un lenguaje de programación es una manera abstracta de manipular una máquina. De hecho, define una modelo simple de una máquina y un lenguaje de programación de alto nivel para dicha máquina

Recuerdo que una idea muy importante de este libro, es como explica que una plataforma de computación es completa si existen diversas maneras para manejarla. Es decir, como UNIX, donde existe un API para invocar al núcleo, o un shell para manejar comandos simples para crear nuevos comandos o interfaces gráficas como X Windows. Es decir, una plataforma de cómputo con una arquitectura que se puede extender y proporcionar herramientas mas orientadas a un problema de un DOMINIO en particular.

Cuando leí eso, me di cuenta que al definir un API de programación, hay que pensarlo como si definiera un lenguaje de programación, con su sintáxis, sus acciones semánticas. Y que también, para simplificar el uso del API, puede definirse un nuevo lenguaje que genere código sobre ese API.

Ahora, incios de siglo XXI, ese concepto se llama DSL y es una manera para lograr la extensión de plataformas de computo.

Me encontre esta referencia en la Dr. Dobss de Julio, Xtext