Y, por fin, no olvides que, de momento, nadie sabe tanto como tú sobre el sistemas que estás diseñando, así que lo más seguro es que nadie (vale: casi nadie) pueda darte soluciones mágicas que tú no hayas visto antes.

Grande. Un día fui a mi jefe con un problema que no era capaz de resolver, y cuando termino de explicárselo le digo “¿qué hago?”. Y me responde: “¿y yo qué sé? Tú llevas estudiándolo dos días y no tienes solución, ¿por qué crees que voy a encontrarla yo en 5 minutos?”. Me enseñó que ser jefe (al menos en mi sector) no es saber más que tus subordinados, solo saber cosas distintas.

Eso sí, un par de cosas que debes tener en cuenta:

Uno: Diseña el sistema pensando lo que va a pasar cuando falle. En la informática moderna todo el mundo diseña y programa maravillosos sistemas que funcionan estupendamente bien en Powerpoint, incluso en pequeños entornos controlados, y luego explotan sin el menor miramiento cuando se dan de bruces con el proceloso mundo real… Insisto: ten siempre como la regla de oro del diseño responder ante fallos. En eso tienes una ventaja: el mainframe (supongo que z/OS con DB2, por lo que dices) te ayudará mucho. No quiero imaginar lo que debe ser diseñar un sistema 24×7 en una granja de servidores UNIX…

Dos: Consigue involucrar a los técnicos de sistemas de DB2. Vale, ya sé que son tipos muy raros, que hablan una jerga casi incomprensible llena de siglas y términos extraños, pero de DB2 saben un rato. Si les adulas un poco y les das cancha, seguramente conseguirás interesarles y que derramen sus conocimientos para optimizar el diseño del sistema. Hay que comprenderlos, claro: están habituados a que les lleguen para implantar horrorosos sistemas diseñados por desertores del Visual Basic, con multitud de tablas con claves autonuméricas (¿quién demonios habrá inventado semejante barbaridad, olvidando… no, pisoteando todas las técnicas de diseño y modelado de datos que tanto nos ha costado obtener a los informáticos…?) y diseños que podrían haber sido hechos mejor por mi sobrino de siete años, aplicaciones que casi no hay forma de meter en cintura, así que sienten un especial repelús hacia los actuales Analistas de Desarrollo. Sin embargo, tienen su corazoncito, y si les propones el reto y te lo compran, seguramente lo asumirán encantados. ¡Eso espero!

Y, por fin, no olvides que, de momento, nadie sabe tanto como tú sobre el sistemas que estás diseñando, así que lo más seguro es que nadie (vale: casi nadie) pueda darte soluciones mágicas que tú no hayas visto antes.

¡Suerte!

Estoy desarrollando un Diseño de Procesos Batch en 24 x 7 (conviviendo online y batch), por lo que agradecería una colaboración. Cuento lo contemplado:

o Para tratamiento de Batch con gran volumen se realiza lo siguiente: Dividir el fichero de entrada en N ficheros de entrada, la condición puede ser cada 5 o 10 registros cree un fichero. Esto se consigue con un programa que a su vez creara N jcl´s en el momento de ejecución, que ejecutan el programa con la funcionalidad que tenia el JCL con un gran volumen de datos.

o ¿Como se deben tratar las LOAD /UNLOAD en procesos de 24 horas?

¿Que más debería de contemplar?

Muchas gracias

Y los que nos dedicamos al data warehouse tenemos ya callo con estos temas.

Echo de menos un artículo al mejor algoritmo de encriptación jamas realizado: El EBCDIC

Lo que tú quieres decir no es que el software esté en crisis, sino que: el método de concepción y realización del software está en crisis. Completamente de acuerdo, claro que sí. No sé si lo he dicho así de claro en alguna entrada, pero creo que se deduce de mis impresiones y comentarios.

Hace treinta años, nuestro objetivo era escribir aplicaciones que tenían que hacer cosas imposibles en máquinas ineficientes, y conseguir que funcionaran cada día y encima fueran eficientes. Se necesitaba una gran formación, una enorme motivación y olvidarse de los horarios. Y lo logramos. Ahí están los resultados.

Pero, claro, con el tiempo el negocio del software se convirtió en un negocio… y con la llegada del negocio llegaron los contables, los marketinianos y los gestores de recursos. Lo importante ya no fue que las aplicaciones funcionaran perfectamente, sino que se ganara dinero escribiéndolas… Y calidad impica casi siempre, esfuerzo y tiempo. Y esfuerzo y tiempo implican dinero. Utilizar el dinero en aumentar la calidad reduce los beneficios…. ergo la solución es obvia: entre maximizar la calidad y maximizar los beneficios………. no sigo, ¿ok?, que creo que ya queda bastante claro.

Gracias por tus comentarios, colega.

@piluso: ¿El software en crisis? Caramba, no se me había ocurrido… viendo cuáles son las empresas más grandes del mundo mundial, y los tipos más ricos del universo, quién diría que el software está en crisis… Claro que, según como se mire. Los que hacen software pueden estar en crisis, dada la tendencia cada vez mayor de las empresas a comprar SAP’s, Peoplesofts, Oracles Financials (o como rayos se llame ahora) y compañía para resolver los problemas que antes hacíamos unos cuantos piraos tirando líneas de código… en este sentido puede que sí que lo esté, pero yo creo que no: hay software en las cámaras de fotos, los lavaplatos, las cafeteras, las cisternas de los sanitarios, hasta las planchas tienen ya software…

@yomismo: ¿Estás seguro que es una buena idea usar una única tabla para que todos los procesos apunten ahi por dónde van para rearrancar si hay un fallo?? Porque… ¿qué pasa si la que casca es la propia tabla de los rearranques…?

Además, salvo truco que desconozco, varios procesos simultáneos accediendo para actualizar contínuamente pocas filas (cada uno la suya) provocan una contención tremenda… claro que hace algunos añitos que ya no programo y quizá la última versión tenga algún dispositivo mágico para tal cosa… Y es que la informática adelanta que es una barbaridad…