10 principios de la vieja escuela de TI que todavía gobiernan

Afortunadamente, gran parte de la sabiduría fundamental de los primeros días de TI sigue siendo aplicable, sólo que de una manera diferente y disfrazada. Aquí les damos diez principios de la vieja escuela que lo guiarán a través de la próxima generación de TI, y las diferencias fundamentales en las formas en las que debe aplicarlos.

La tecnología que se compra es un compromiso a largo plazo de su parte. Sin embargo, también se necesita que sea un compromiso a largo plazo por parte del proveedor.

Para ir a lo seguro, TI solía comprarles a grandes proveedores. ¿Y ahora? El código abierto no es solamente igual de seguro, sino que algunas veces se puede obtener de IBM u otros grandes proveedores.

No todas las tecnologías de código abierto tienen una base de apoyo amplia, pero muchas sí. Si PHP, por ejemplo, hace el trabajo, ¿usted miraría a Java dos veces dado su horrendo historial de seguridad? Y, sin embargo, Java es respaldado (quizás decir “proporcionado” sería más exacto) por Oracle, una de las empresas de software más grandes del mundo.

Esto tampoco es completamente nuevo. Después de todo, la biblioteca SHARE similar al código abierto, data de los años setenta.

La buena seguridad de la información comienza con una buena seguridad física

Versión antigua: “Mantenga el hardware bloqueado”.
Nueva versión: No tiene que ser un cuarto cerrado.

Siempre hemos mantenido el hardware bloqueado, limitando el acceso al centro de datos a un pequeño número de buenos empleados y manteniendo registros automatizados de quién entra y cuándo. No todos los cuartos cerrados son nuestros.

Para las PyMES en particular, hay alternativas que van desde instalaciones internas hasta la nube completa.

Pero no ponga en su bolsillo todos los ahorros de no haber construido su propio centro de datos. Invierta una parte de ellos en una conexión de red de baja latencia y gran ancho de banda a su proveedor externo. Aún mejor: aplique otro principio de antaño nunca tenga solo uno de cada cosa. Haga esas dos conexiones, con puntos de presencia en lados opuestos de su edificio, para que una retroexcavadora no pueda tumbar su negocio cavando un agujero en un lugar inoportuno

Conozca las amenazas

Versión antigua: “Haga un inventario de las amenazas de seguridad e implemente contramedidas.
Versión de mediana edad: Bloquee los escritorios y cuide el perímetro.
Nueva versión: Endurezca los activos y también cuide el perímetro.

Antes, frustrar las amenazas de seguridad significaba agotar el tiempo de las sesiones de CICS para que los hackers no pudieran marcarlos y heredarlos. Luego vinieron las PCs, los sistemas distribuidos, la Internet y muchas más amenazas. Respondimos bloqueando los escritorios y cuidando el perímetro con firewalls cada vez más sofisticados.

Muchos todavía piensan que la mejor contramedida es bloquear todo y no dejar que nadie se ponga creativo. Sin embargo, los negocios viven y mueren por la innovación, y ésta significa más que nuevos productos para vender. Significa pensamiento creativo y la implementación de este en todo el negocio.

En estos días deberíamos pasar más tiempo reforzando los activos que el perímetro, y más tiempo soportando activamente a los usuarios, porque la amenaza más grande es una fuerza de trabajo a la que no se le permite innovar.

Probar el software significa más que simplemente poner un código en producción y ver qué pasa

Versión antigua: Mantenga tres entornos -dev, test, prod.
Nueva versión: Mueva muchas de las pruebas a la nube.

Las pruebas de regresión y de estrés diferencian a los profesionales de los aficionados. Siempre lo han hecho y lo seguirán haciendo. Por un lado, las pruebas de regresión aseguran que las cosas nuevas no rompan a las viejas. Por otro lado, las pruebas de estrés aseguran que todo funcione bien cuando todo el mundo comience a trabajar con determinación.

TI, siendo profesional, mantuvo al menos tres entornos desarrollo, pruebas y producción. Eso significó comprar tres de cada cosa y mantenerlas.

Ahora, incluso cuando mantiene su propio centro de datos, ejecutar un entorno de prueba en la nube tiene más sentido porque solo paga por él mientras lo necesite. Dependiendo de su entorno de producción, puede funcionar bastante bien para las pruebas de regresión también.

Cambios de control en el entorno de producción

Versión antigua: Un proceso formal de cambios de control.
Nueva versión: Un proceso formal de cambios de control.

Ya pasaron los días en los que los desarrolladores podían mandar su nuevo código a producción. Hay un proceso por el que tiene que pasar. En realidad, a nadie le gusta el proceso, pero no se trata de eso, sino de asegurarse que el cambio no interrumpa la producción; y si lo hace, se trata de asegurarse de que haya un plan b.

¿Usted piensa que la nube cambia las cosas? Lo hace. Hace que el control de cambios sea más complicado por ahora, si no se tiene cuidado con la forma en la que se administra a los proveedores de nube, es probable que manden sus cambios a producción sin pasar por su proceso.

Waterfall debería funcionar, pero agile sí funciona

Versión antigua: Una ida y vuelta informal entre los administradores y programadores de biz.
Nueva versión: Scrum: Una ida y vuelta informal entre los administradores y programadores de biz, solo con un libro de reglas a seguir.

Mucho antes de que las metodologías formales de desarrollo agotaran la diversión de TI, los gerentes de negocio solían preguntar, “¿Puedes hacer que la computadora haga esto?” El programador trataría de hacer algo, se lo mostraría al usuario de negocios y lo repetirían hasta que esté bien.

No lo llamaban agile, sino “tener una conversa sobre lo que la computadora debería hacer”, pero aun así era agile.

Luego llegaron las metodologías waterfall. También funcionarían si los gerentes de negocios pudieran imaginar un sistema de trabajo completo y describirlo con precisión. Sin embargo, no pueden, así que perdimos treinta años de productividad.

Ingrese a Scrum, que toma la iteración y la interacción, y añade suficiente metodología para agotar la mayor parte de la diversión de TI que otras versiones de agile le habían vuelto a poner.

Las relaciones preceden al proceso, y las relaciones sobreviven a las transacciones

Versión antigua: Gestionar las relaciones con otros ejecutivos de alto nivel es una parte clave del trabajo del CIO.
Nueva versión: Gestionar las relaciones con el resto de la empresa es una parte clave del trabajo de todos.

Los negocios son colecciones de relaciones antes que cualquier otra cosa. Con buenas relaciones todo puede funcionar; y sin ellas, nada puede.

Antes, cuando las empresas eran jerarquías estrictas, el CIO gestionaba las relaciones con los otros ejecutivos de alto nivel y eso era suficiente. Si los otros ejecutivos de alto mando no confiaban en el CIO, era imposible que TI tuviera éxito. Era tan simple como eso.

Sin embargo, cada vez que cualquier miembro del departamento de TI interactúa con cualquiera de la empresa, afecta la relación empresa/TI. No solo se trata del CIO y de los otros ejecutivos. Si el resto de la empresa no confía en TI, éste no puede tener éxito; y si sí lo hace, todo lo relacionado con TI es más fácil.

No es fácil, pero sí más fácil.

Integre, porque interconectar las ‘islas de automatización’ involucra un montón de procesos estúpidos fuera del negocio

Versión antigua: La acumulación gradual de interfaces de lote preprogramadas.
Nueva versión: El service bus o el equivalente con interfaces diseñadas en tiempo real.
Versión aún más nueva: Integrar también con soluciones SaaS no basadas en TI.

Cuando los seres humanos re introdujeron información de los informes generados por computadora en pantallas de entrada de datos, TI se dio cuenta que una de sus principales responsabilidades era la de integrar sistemas dispares para mantener los datos sincronizados.

Así que construyó interfaces. Muchas. Todas ETL de lote personalizado.

Ahora hay tantas que es un desorden difícil de mantener. Por ello, inteligentemente, TI invierte en un service bus, o algo parecido, y diseña sus interfaces, porque acumular uno encima del otro significa que la nueva y brillante tecnología está recreando el mismo enredo antiguo.

Actualmente, mucho de TI pasa fuera del departamento de TI, mayormente en la forma de SaaS introducido por los gerentes de negocio como islas de automatización. Eventualmente, se cansarán de tener a su personal re introduciendo datos en él. Esté preparado para ello.

TI existe para apoyar el negocio

Versión tan antigua que es un cliché: No tecnología por el bien de la tecnología.
Nueva versión: Proporcione liderazgo tecnológico.

La tecnología por el bien de la tecnología es algo malo. Eso no significa que TI debería limitar su rol al procesamiento de órdenes de trabajo. Tiene que ir mucho más allá de eso para probar su liderazgo tecnológico.

Cualquier departamento de TI que falle al proporcionar el liderazgo tecnológico -para sugerir y discutir, no solo aceptar y entregar- está fallando a un nivel básico.

El liderazgo tecnológico también significa apoyar a los administradores y usuarios que están listos para comprar o construir su propia tecnología. Es momento de reconocer que la shadow TI es algo bueno, porque aumenta el ancho de banda de TI.

Por supuesto que hay riesgos. Todo lo que valga la pena tiene riesgos.

TI debe ayudar a todos en la empresa a tener éxito con toda su tecnología, no cortar nada que “no se inventó aquí”.

Se trata del cambio empresarial, o sino ¿cuál es el punto?

Versión antigua: “TI es el principal impulsor de posibilidades en toda la empresa”.
Versión de mediana edad: TI es la mayor barrera para el cambio en la empresa.
Nueva versión: TI es el principal impulsor de posibilidades en toda la empresa.

Cuando las computadoras eran nuevas, los ejecutivos de negocios contaban con ellos para impulsar el cambio en todas partes, haciendo que los procesos de negocio sean más rápidos y baratos, reduciendo los errores manuales.

Eso duró hasta que TI tuvo que soportar tantos sistemas interconectados que hacer algo nuevo requería mucho tiempo, era caro y riesgoso. Su dependencia en las metodologías de waterfall tampoco ayudó.

Finalmente, nos estamos desprendiendo de nuevo.

MexicoCIO.10 principios de la vieja escuela de TI que todavía gobiernan. https://goo.gl/w9Aujr