Por Mark Settle*

Con la ventaja de una retrospectiva 20/20, tengo que preguntarme a mí­ mismo cómo yo – y la gran mayorí­a de los CIO’s – nos engañamos pensando que el hardware fue barato durante mucho tiempo. En los viejos tiempos, hubiéramos permitido que diferentes grupos funcionales en la compañí­a se hubieran enamorado con aplicaciones de negocios individuales, cada una de ellas con propios requerimientos de hardware y arquitecturas de middleware. Debido a que los gastos de hardware fueron siempre la pieza más pequeña parte de cualquier adquisición mayor de sistemas, tuvimos que incrementar el tamaño del hardware para protegernos contra posibles problemas en el desempeño del sistema. Para ser franco, nosotros no desempeñamos la administración de capacidad debido a que no querí­amos conocer la respuesta. Todos nosotros sabí­amos intuitivamente que nuestro servidor y las granjas de almacenamiento eran significativamente utilizadas por debajo de su capacidad.

Cuando los proveedores de cloud públicos comenzaron a proveer infraestructura TI bajo demanda en una base de tipo «pay-as-you-go», todos despertamos de nuestra realidad y nos dimos cuenta de que estas nuevas opciones bajo demanda pronto desplazarí­an nuestras operaciones base con su eficiencia y confiabilidad. Así­ que, comenzamos a actuar como proveedores de cloud públicos dentro de nuestras propias compañí­as. Hemos establecido la ley junto con nuestros clientes de negocio y les hemos indicado que tipo de hardware y arquitecturas de middleware soportarí­amos y cuales no. Les hemos dicho: «Si no es posible que corra en nuestras arquitecturas estándar, no lo pueden comprar».

Luego llego la hora de la verdad con nuestros directores financieros. Tuvimos que entrar y admitir que todo el hardware que nos habí­an permitido adquirir en la ultima década se encontraba solamente estancado en el centro de datos y corriendo a 50 por ciento de su capacidad en cualquier dí­a normal (exceptuando el mainframe por supuesto). Les dijimos que si tan solo nos permitieran invertir en capacidad de anticipación de la demanda en el futuro, y evitar las compras adicionales ligados a la adquisición de los sistemas más importantes, se podrí­an alcanzar tasas mucho más altas de rendimiento en nuestro hardware de TI. Acabamos de tener a un acuerdo para iniciar la presentación de informes sobre la utilización de la capacidad a cambio de la nueva polí­tica de compra de capacidad de anticipación de la demanda.

Es increí­ble el tiempo que perdimos y que nos preocuparon los problemas de seguridad en las nubes públicas de aquel entonces. Ahora, que hemos impulsado a los proveedores de cloud públicos para desempeñar tipos especí­ficos de cargas de trabajos. Reconocemos los requisitos de seguridad de cada carga de trabajo y usamos la encriptación de datos apropiada para asegurar que la seguridad en la información se transmita a proveedores externos. Aunque algunas formas de datos son demasiado sensibles como para del centro de datos de nuestra empresa, las decisiones de asignación de carga de trabajo ahora se manejan a través de nuestros procesos de aprovisionamiento automatizado. No tenemos debates filosóficos sobre lo que puede y no puede pasar fuera de nuestro servidor de seguridad. Hemos resuelto este problema hace mucho tiempo.

Hace diez años, podrí­a haber tomado de tres a seis semanas de reuniones, correos electrónicos, las evaluaciones del hardware, y las negociaciones de precios sólo para obtener un conjunto de servidores provisionados a un grupo de desarrolladores. Para el año 2010, utilizando configuraciones estándar y scripts automatizados en un entorno virtual, los CIO’s pudieron obtener esos mismos servidores en una nube pública o privada en tres o cuatro horas. Hoy en dí­a, lo podemos hacer en cuestión de minutos. Al tener secuencias de scripts automatizados listos para proveer los diferentes tipos de servidores, incluyendo aplicaciones y redes en la nube, y con eso no solamente conseguir enormes ahorros en los esfuerzos del personal técnico sino también mantener el negocio flexible.

En estos dí­as, puedo administrar una plataforma de Cloud Computing hí­bridas que comprendan tanto la infraestructura interna, en las instalaciones y una colección de proveedores externos que utilizo cuando los necesito en una base de autoservicio, para realizar tareas especí­ficas. Ahora que lo pienso, eso no es muy diferente de la forma en la que nosotros hemos utilizado socios estratégicos externos para ayudarnos a desarrollar y mantener muchas de nuestras aplicaciones empresariales.

Tras el susto del Y2K a finales de los 90’s, pasé cinco años aprendiendo a virtualizar mi aplicación y los equipos de desarrollo mediante el aprovechamiento de los recursos de TI situados en Asia y Europa del Este. He pasado los últimos cinco años haciendo lo mismo con mi infraestructura, combinando el uso de los activos informáticos internos y los activos externos para satisfacer las necesidades de los clientes de mi negocio en la forma más rentable posible. Creo que la historia se repite a sí­ misma después de todo.

Lo bueno fue que fuimos lo suficientemente inteligentes como para mudarnos a la tecnologí­a cloud computing en el 2010, o de lo contrario nunca habrí­amos tenido la flexibilidad ni los recursos necesarios para aprovechar la explosión de las aplicaciones móviles que se han reproducido en los últimos cinco años. De hecho, aún estarí­amos gastando el 60 por ciento de cada dólar del presupuesto de TI para mantener las luces encendidas para nuestros sistemas de negocios.

De vuelta en el año 2010, tení­a un buen año si era capaz de entregar dos a tres aplicaciones principales de nuevas empresas y la rotación de los comunicados trimestrales y mensuales necesarios para apoyar el centro de datos de los sistemas de legado que tení­a que mantener. Me encontré en competencia con Apple y los desarrolladores de Android, que fueron produciendo aplicaciones de 10.000 nuevos por trimestre! En cierta forma es la misma historia que la tecnologí­a cloud computing. Dejé de tratar de competir con estos desarrolladores móviles y en su lugar me convertí­ en uno de ellos. Mi equipo comenzó a desarrollar de manera significativa cada vez más servicios de negocio que podí­an ser entregados en las plataformas con mucha más frecuencia. En efecto, nuestros equipos de desarrollo de aplicaciones evolucionaron a convertirse en pequeños equipos de ventas internas basados en un modelo de autoservicio, incluyendo servicios para mejorar la productividad de nuestros usuarios finales y responder a las amenazas competitivas para nuestro negocio.
Habí­amos comenzado a utilizar versiones estándar de nuestras aplicaciones comerciales SaaS en el plazo 2005-2010. Nuestros usuarios estaban encantados con la rápida introducción de nuevas funcionalidades proporcionadas por los proveedores de SaaS, y estábamos encantados con los gastos de soporte con respecto a nuestros sistemas de legado. En los últimos cinco años, nos hemos convertido en proveedores de SaaS nosotros mismos. La mayorí­a de las aplicaciones que utilizamos en la empresa hoy en dí­a son en realidad «mash-ups» de los servicios de negocio. La mayorí­a de nuestros usuarios no saben si un determinado servicio se está entregando de nuestro sistema ERP, nuestro sistema de atención al cliente, nuestro sistema de comercio electrónico, etc. Simplemente se suscriben a los servicios que necesitan para desempeñar su trabajo. Nosotros no tratamos de empujar la funcionalidad hacia ellos. Solo toman lo que quieren y necesitan, y luego lo comparten de manera más amplia a través de diferentes equipos funcionales y grupos geográficos de una forma como nunca lo habí­an conseguido.

Uno de los grandes beneficios de la tecnologí­a cloud computing para nuestra organización es que se libera una gran cantidad de tiempo que solí­amos pasar en la administración del hardware. Hemos redireccionado ese tiempo a la administración de datos y la información que se alimentan de nuestras aplicaciones de negocio, y esto ha tenido un gran impacto positivo en nuestras operaciones del dí­a a dí­a.

Vivimos en un mundo que es radicalmente diferente del mundo que existí­a en el año 2010. Ya no gastamos 60 centavos de cada dólar del presupuesto de TI en el mantenimiento de aplicaciones, operaciones de centros de datos, los gastos de instalación, etc. A cambio, gastamos 60 centavos de dólar del presupuesto de TI en la entrega de nuevos servicios de aplicaciones y nuevas formas de datos puros dirigidos a nuestros usuarios finales. El personal de TI en verdad se encuentra satisfecho porque se dan cuenta de que estamos generando un valor real para nuestros socios de negocios y dejamos de preocuparnos frenéticamente tratando de mantener un montón de hardware y software subutilizado. También estamos mucho más cerca de alcanzar el estado mí­tico de «Alineación de las TI y del negocio» que aún aparece en los temas principales de investigación de Gartner para el 2015.

*Mark Settle

Acerca de Mark Settle

CIO en BMC Software

Mark Settle se incorporó a BMC Software en junio del 2008. Se ha desempeñado como CIO en cuatro compañí­as de la lista de las Fortune 300: Corporate Express, Arrow Electronics, Visa International, y Occidental Petroleum. Settle ha trabajado en una variedad de industrias, incluyendo productos de consumo, la distribución de alta tecnologí­a, servicios financieros, petróleo y gas. Durante las primeras etapas de su carrera, él era el director de una unidad de negocio de integración de sistemas dentro de Hughes Aircraft Company. El entrenamiento formal de Settle es en Ciencias Geológicas. Obtuvo tí­tulos de Bachelor y Master por el MIT y un doctorado de la Universidad de Brown. Settle además es un ex oficial de la Fuerza Aérea y cientí­fico del programa NASA.