There are only two types of enterprise software:

• Software that buy IT departments, and
• Software that buy people from a Busines s Unit.

In the first group you can find the “usual suspects”: Oracle, Microsoft, IBM, etc… IT departments usually buy something that they can use for more than one project – they don’t buy an Oracle license and setup a different database server for every application.

Usually it is difficult to sell something to an IT department; but there are some opportunities as well: it’s usual to see shrinking IT budgets even in “good” years – price and/or total cost of ownership is an important selling point here. New, disruptive technology (that affects TCO) can also make you sell something; but it’s harder to justify.

Selling to the second group – Business Units – may be easier to sell to an IT department. Usually Business Units don’t manage their own IT (there are some exceptions, but this is he rule); instead BU people consume IT services from the central IT department and they hate it because IT is not flexible enough form them. Remember that word: FLEXIBILITY is your primary selling point.

A Business Unit will buy all hardware, software, or services they need to do the job. They don’t expect their recently purchased 24-core server / great new project management software is able to do more that they initially asked for. They had a problem, figured out a solution, and bought it. Period.

If you’ve grown beard (and gone a bit bald, like me) administering IfTTT software like firewalls, ETL, mail filters, web crawlers, yahoo-pipes, or just IfTTT; I’m sure you have spent a lot of timecleaning old configuration rules.

When you are part of a team that administers – for example – a firewall, you may end up asking why did someone added that rule in your firewall and why. Of course, you can always disable that rule (that’s the GUI equivalent of commenting out some lines fomr a configuration file) and cross your fingers waiting until a) someone complains or b) you remove the rule after a prudential amount of time.

The problem is that most (if not all) rule-based software doesn’t tell you how much times a disabled rule matches. And that’s a problem.

Before coding the next IfTTT rule-based software consider using three states for your rules:

• State 1: Production – Nothing new here. Just apply the rule.
• State 2: Inactive (log only) – The rule is there; but it’s not alive. When this rule matches, you just increment a counter and and keep searching for the next rule that matches (I wish all routers would have had this feature for years).
• State 3: Disabled (not deleted). Just “commented-out” and kept for reference.

Disclaimer: you can mimic this behaviour in some firewalls combining the allow and log actions, and digging in your logs; but it’s not clear and needs a lot of time for analisys.

This is specially usefull in a machine-to-machine (m2m) scenario. Most rules won’t have a person behind that will complain if there’s something wrong. In M2M the robot in the other side will take some decision based on it (limited) pre-programmed actions and you need to know how many times a rule does apply and if there’s a dumb robot trying to hit a rule you are about to remove.

Me llama mucho la atención la caída en picado del año 2007. Supongo que la crisis financiera debió hacer bastante daño a los programadores en Java de la City londinense; sin embargo esa caída no se ve si buscamos “Developer”, ni otras tecnologías como .NET.

En los últimos 8 años Java ha pasado de ser demandado por un 36% de las ofertas de empleo a poco más de un 28%.

Parece que la demanda se ha ido a la plataforma .NET de Microsoft y a lenguajes entornos más sencillos como PHP o Ruby. Mientras tanto lo que tira de la demanda de Java es el mantenimiento de aplicaciones existentes y el desarrollo de Hadoop.

PD: Si la caída de demanda de Java te llama la atención, echa un vistazo a las ofertas de trabajo para UNIX (no Linux: UNIX del de toda la vida como Solaris, IRIX, HP-UX..).

¿Qué está pasando con el consumo de memoria de ese equipo?

La respuesta buena es NADA malo. Sólo estamos mostrando datos de distinta calidad en un mismo gráfico:

En la zona que está marcada con un círculo, tenemos datos disponibles cada 5 minutos.

Fuera de esa zona, tenemos un dato cada 30 minutos… a base de hacer la media de la información que teníamos cada 5 minutos de hace uno días…

El resultado es que el comportamiento del equipo parece que ha pasado de bueno a tener mucha variación. Y todo por mostrar en el mismo gráfico información de calidad distinta.

Espero que VMWare tome nota y lo arregle un día de estos…

De vez en cuando me paso por la carpeta de Spam de mis blogs y me encuentro mensajes como el de arriba: un tipo, que no es capaz de hace pasar sus mensajes de spam por Akismet (un sistema antispam muy sencillito), me quiere vender un servicio de spam en otros blogs para conseguir enlaces. Al menos no intenta vender algo para agrandar ciertas partes de tu cuerpo…

Otras veces te encuentras al spammer que intenta ganar dinero mandando a la gente a una página web que le paga cada vez que se registra alguien:

Algo me dice que el tio que escribió ese comentario no se llama ni Jesús Macías, ni Simón Pérez… pero el hombre lo intenta a ver si hay suerte y se cuela un comentario en el blog.

Pero el mejor es el spammer insistente, que primero te manda un mensaje como éste para que hagas clic como administrador:

Y un rato más tarde te manda éste otro mensaje para que hagas clic haciéndote creer que te están copiando el contenido del blog.

Buen intento; pero se lo habría podido currar un poco más… cambiando la dirección IP desde donde manda el comentario (reiniciando el router ADSL si lo hace desde casa, o cambiando el Proxy si lo hace en automático)…

¿Porqué El Corte Inglés sale etiquetado en Japonés en Google Maps?

Porque varios japoneses han escrito reseñas sobre El Corte Inglés, y Google se fija en eso para poner información en el mapa.

Si alguien quiere promocionar en Google Mapas un negocio en Grecia, Moscú, o en Emiratos Arabes, ya sabe cómo: ponle un nombre español, y pon varios comentarios para atraer turistas españoles

• Desde que lance la compra del servidor hasta que llega al datacenter (en una caja) van a pasar dos semanas (se ha contratado un servicio exprés).
• La empresa que ha contratado Jorge necesita una semana para desarrollar la aplicación.
• Por abaratar costes, la aplicación se desarrolla en el servidor que ha comprado.

Jorge está contento porque el proyecto va a poder empezar en un mes sin vacaciones de por medio. Si la PMO llega a autorizar el proyecto en Marzo, no llegaría a estar a tiempo hasta después de semana santa – me comenta en la máquina del café después de enseñarme el project:

Lo que no te cuenta nadie sobre Cloud Computing es que ese proyecto se puede acortar una semana. ¿Cómo? desacoplando las compras del desarrollo y la puesta en marcha.

Si el equipo de Jorge desarrolla la aplicación sobre una máquina virtual ya existente en nuestra cloud privada, puede empezar a trabajar hoy mismo.

Mientras tanto Jorge le puede pedir el servidor al departamento de compras, y cuando esté disponible, se incorpora a la cloud privada. La planificación queda entonces así:

Este es un caso muy sencillo de un proyecto simple; en un proyecto de mayor envergadura también se gana mucho tiempo utilizando cloud computing. Normalmente las aplicaciones y los desarrollos se pueden hacer con menos requisitos de CPU y memoria de los que van a hacer falta para la aplicación final. Durante la instalación de aplicaciones se necesita también CPU y memoria; pero la demanda es muy puntual (se trata de picos de cpu y memoria casi siempre) y si necesitas comprar hardware siempre puedes integrarlo en tu intraestructura virtual cuando llegue sin tener que parar tu proyecto.

He ido a varios eventos de VMWare sobre virtualización, y te cuentan de forma intuitiva que virtualizando y usando tecnologías de cloud computing puedes conseguir ahorros importantes en tus proyectos; pero nadie me ha enseñado ningún dato que lo demuestre.

Por cierto: hace más de un año, colgué un post con una lista de preguntas que nadie te responde sobre virtualización y cloud computing. A lo mejor te interesa echarle un vistazo.

Por curiosidad, podéis iros a gapminder y comparar cómo vivimos nosotros, y como viven ellos. De paso podemos ver cosas que resultan increíbles como que, por ejemplo, la gráfica de esperanza de vida de vs mortalidad infantil de 2007 en África se parece mucho a la de Europa en los años 40.

Si le das al play desde 1800 puedes ver cómo van detrás de nosotros.

¿Ahora entiendes por que les llaman países emergentes?

Uno de mis profesores en la carrera nos decía son parar que en informática se gana dinero con el mantenimiento, no con el software. Y nos ponía un ejemplo muy curioso:

Un avispado empresario desarrollaba un software para la gestión de ayuntamientos.
El empresario conseguía venderlo porque daba gratis el software a los ayuntamientos.
Así, si salía a concurso la adjudicación del software siempre ganaba por motivos económicos.
¿Y cómo ganaba dinero? con el mantenimiento, que sólo podía dar él porque era un desarrollo propio.

Acuérdate de que en el negocio del software, el dinero está en el mantenimiento: en dar nuevas versiones al cliente, arreglar bugs, y ayudarle cuando tiene problemas con la instalación.

Los casos típicos son la introducción de datos en aplicaciones o en la red (provisión) para hacer que todo funcione.

Lamentablemente, las nuevas tendencias en aplicaciones (como AJAX) hacen cada vez más complicado o más caro automatizar cosas. Para colmo, en un entorno de IT cerrado, tampoco te vas a encontrar con multitud de APIs que te ofrezcan trasvasar datos de un lado a otro (como ocurre en el mundo de internet). Lo normal es que si compras una aplicación enterprise, no soporte servicios web (aunque esto está cambiando poco a poco).

Si quieres tener trabajo en IT aprende a automatizar procesos

Cuando llegó la revolución industrial, a alguien se le ocurrió pensar que eso iba a terminar para siempre con el trabajo de muchos artesanos. Y tenían razón (a medias): casi 100 años después, la artesanía no sólo es cara; sino también muy apreciada por ser algo distinto.

Cuando llegaron las máquinas muchos ayudantes y aprendices símplemente dejaron de hacer falta: las máquinas podían mover materiales de un lado a otro de la fábrica sin tener que pagar a una persona para hacerlo, y además lo hacían más rápido.

En IT está pasando lo mismo: ¿te acuerdas de la burbuja de las puntocom? cuando empezó aquello había muchos informáticos, telecos, y gente con conocimientos técnicos dedicados a mantener las webs y los servidores. Y resultaba carísimo.

Hoy en día la mitad de las tareas que se hacían en el 2000 se han automatizado. Se puede subir un texto a la web desde Word con los botones de “publicar” y “guardar en carpeta web”. Eso antes necesitaba a alguien que lo transformase en HTML y le diese forma.

En los departamentos de sistemas también se están automatizando muchas cosas, como el despliegue de servidores (virtuales, por supuesto), la instalación de puestos de trabajo… cosas que costaban dinero pero que se encargaban a gente con poca cualificación (y poco sueldo).

¿Y quién se queda? el que sabe cómo funciona la maquinaria, y el que diseñó lo que permite que la empresa funcione en automático.