Archive for the ‘Informática e Internet’ Category

h1

Los 11 países (y un par de colados) con mejor paga para un profesional en Java

12/12/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

Atribuyo mi éxito a esto: nunca me rendí, ni di excusa alguna.

Florence Nightingale (1820 – 1910). Enfermera, escritora y estadística británica, considerada como la precursora de la enfermería profesional moderna.

Este 2016 ya casi termina, por lo que muchos de nosotros estamos saliendo de vacaciones o finalizando los últimos encargos antes de “cerrar la cortina” debido a las fiestas. Otros tantos, ya empezamos a planear los proyectos del próximo año, ya que durante los primeros meses del 2017, si bien el mundo no se acabará, sufriremos de una fuerte incertidumbre y por consiguiente, el entorno económico se tornará bastante pesimista. Por ello, en vez de preocuparnos, es necesario ocuparnos en soluciones concretas para evitar “marearnos” debido a la montaña rusa que estamos a punto de experimentar.

Es así como encontré la siguiente infografía, que detalla algunos de los países donde el conocimiento en Java es mejor pagado; desde entry-levels, hasta desarrolladores expertos con más de 10 años de experiencia:

Pic: 12 Best Paying Countries for Java Professionals
Los 11 Mejores Países para un Profesional en Java. También se incluye a la India, cuyos sueldos se encuentran entre los 6,000 y 15,000 dólares anuales; una cifra bastante más baja que el ingreso percibido por un desarrollador Mexicano (USD 15,500 – 20,200) (Fuente: DZone.com)


Lo interesante de la gráfica es que no necesariamente los Estados Unidos son los que mejor pagan; para desarrolladores expertos, el país que cuenta con el mejor sueldo es Suiza, con el equivalente a casi USD 99,000 anuales. Sin embargo, por lo remoto de aquella nación Europea y el “detalle” de tener que ser multilingüe (los idiomas oficiales son el Alemán, Francés, Italiano y Romanche) es comprensible que sus sueldos sean bastante altos. Por otro lado, países que difícilmente serían considerados como la primera opción de un desarrollador en Java, como Nueva Zelanda, Australia y el Reino Unido, también son muy atractivos. A continuación, una tabla con estos sueldos convertidos a dólares Americanos, incluyendo a México como referencia:

País Principiante
(USD)
Intermedio
(USD)
Experto
(USD)
Suiza 39,865.32 85,821.12 99,000.00
E.E.U.U. 48,735.00 72,760.00 87,000.00
Noruega 48,069.84 65,485.80 78,476.64
Dinamarca 28,105.56 64,273.58 76,821.78
Israel 25,480.00 61,949.94 72,800.00
Australia 37,008.75 56,748.75 68,250.00
Suecia 29,869.18 53,184.67 60,750.47
Alemania 28,721.76 48,364.62 56,180.00
Canadá 32,827.44 47,977.28 56,240.00
Nueva Zelanda 32,384.88 45,932.40 56,160.00
Reino Unido 29,909.77 44,140.12 55,880.00
México 15,421.48 19,770.32 20,094.31
India 6,209.34 11,970.72 15,000.00
Sueldos anuales por país, en dólares Americanos, ordenados de mayor a menor por Nivel Intermedio de experiencia.


La gráfica también expone lo que ya sabíamos: la tecnologías que están de moda son Hibernate, Spring y Struts, y las que ya van de salida, debido a la negligencia de Oracle, como los JSPs y Servlets. También nos muestra que vale la pena obtener certificaciones como programador o desarrollador, para refinar nuestras habilidades y tener un currículo con un mayor impacto.

Ahora, ya que para el próximo año tanto los Estados Unidos como Europa serán más propensos a aumentar las restricciones sobre el movimiento de los trabajadores, no todos seremos capaces de empacar y salir de nuestros respectivos países para lanzarnos a la aventura. Entonces, ¿por qué no buscar trabajo remoto? En la web podemos encontrar buenas opciones para encontrar tales oportunidades, lo que nos permitiría ganar un par de dólares desde la comodidad de nuestro propio hogar. ¿El único obstáculo? La maestría del idioma Inglés y, por supuesto, nuestras habilidades para usar las tecnologías del oficio.

h1

El Javapocalipsis o cómo nos estamos quedando sin Java EE

07/15/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

No se trata de bits, bytes y protocolos, sino de beneficios, pérdidas y márgenes.

Louis Gerstner, Jr. (n. 1942). Empresario estadounidense, mejor conocido por su rol como director general de IBM entre 1993 y 2002.

Una tendencia aparentemente irreversible, es la lenta pero inexorable muerte de Java Enterprise Edition (Java EE). No me refiero al lenguaje de programación Java (también conocido como Java Standard Edition o Java SE), el cual está teniendo un enorme impulso gracias a su facilidad de aprendizaje e implementación, sino a todas aquellas tecnologías/librerías basadas en Java, que en su momento eran consideradas el non plus ultra para desarrollar aplicaciones multi-capa y empresariales: Servlets, Java Server Pages (JSP), Enterprise Java Beans (EJB), Java Persistence Architecture (JPA), así como Java Server Faces (JSF).

Cómo llegamos hasta aquí

En 1999, Sun Microsystems publicó Java EE, con la finalidad de desarrollar aplicaciones “de nivel empresarial”, que en su forma más simple, son aplicaciones web con alta disponibilidad, escalabilidad y mantenibilidad. Así, dicha versión de Java incluía los EJBs, Servlets y JSPs; tecnologías bastante complejas que requerían de al menos un día para mostrar el proverbial “Hola Mundo”. Debido a esta dificultad de implementación, la comunidad open-source respondió casi de inmediato, desarrollando y liberando en el año 2000 ciertos frameworks como Struts e iBATIS, los que disminuían enormemente el tiempo para terminar un delivery. Eventualmente, surgieron algunos frameworks más ligeros y ergonómicos que el propio Java EE, como Hibernate y Spring, los que forzarían a Sun adoptar su filosofía, en la sexta versión de Java EE, liberada en 2009.

Sin embargo, a raíz de la adquisición de Sun por Oracle, completada en 2010, la empresa dirigida por Larry Ellison ha dejado de apostar a esta plataforma, relegándola poco a poco al olvido. ¿La razón? Que Oracle es un conocido mercenario en la industria, y Java EE no está generando los suficientes ingresos como para asegurarle un presupuesto. Lo peor de todo es la poca transparencia y falta de un pronunciamiento claro al respecto, lo que está poniendo nerviosos a programadores, integradores y clientes por igual. Y no es para menos, pues considerando el historial de Oracle con los desarrollos open-source, existen muchas razones para preocuparse por el bienestar de esta plataforma; especialmente desde que Oracle perdió una batalla legal contra Google en Mayo pasado por el uso de Java en Android, la que ha desembocado en la demora de Java SE 9, cuya fecha de liberación se moverá hasta 2017, y la paralización de cualquier trabajo relacionado a Java EE.

Pic: Is Java dead?


Si bien la plataforma Java EE se encuentra en franca decadencia, el lenguaje de programación Java es parte de una era dorada empujada principalmente, por el explosivo crecimiento de los smartphones y tablets:

• Los applets de Java ya son cosa del pasado debido a que inicialmente apareció Flash; en última instancia, fueron liquidados por HTML5.

• La popularidad de Java en desktop siempre ha sido relativamente baja, debido sobre todo a otras opciones como C++ y Python. Sin embargo, definitivamente no está acabada y todavía se mantiene en evolución constante.

• Muchas empresas tienen enormes cantidades de código escrito en Java. Y si algo hemos aprendido de lenguajes legados como COBOL, es que frecuentemente, se niegan a morir – aunque ya no representaría una ventaja curricular conocerlo, a menos que seamos especialistas en alguna de sus tecnologías, como digamos, EJB 2.1.

• Java es el principal lenguaje de programación de los dispositivos Android, que son muy populares: en Otoño de 2015 existían alrededor de 1,400 millones de dispositivos activos alrededor del mundo.

En resumen, Java no va a desaparecer, incluso si Oracle se lo propusiera.


(Fuente de la imagen: ExtremeTech.com)


La cuestión es que al detener el soporte a Java EE, Oracle está poniendo en riesgo 15 años de desarrollo aplicativo y literalmente, millones de empleos alrededor del mundo. Hoy en día, ya hay competidores de Oracle que estarían dispuestos a tomar el relevo para continuar con el proyecto, como IBM y RedHat, quienes ciertamente tienen los recursos para soportar la plataforma, además de tener la capacidad de agregarle funcionalidad de acuerdo al actual entorno tecnológico, como los microservicios. Claro que Oracle siendo Oracle, puede comportarse como el siniestro Guasón de The Dark Knight (2008): esta compañía preferiría convertirse en un agente del caos, antes de permitir que las joyas de la corona caigan en manos de la competencia. Esto podría desestabilizar la industria, ya que daría lugar a una situación extrema en la que decenas de proveedores de TI, que dirigidos por Google, IBM y RedHat, se unan para generar su propia versión de Java EE, dejando a Oracle fuera de la jugada.

¿Qué pasará?

Lamentablemente, Oracle no ha sabido cómo capitalizar la ventaja competitiva que tiene al haber adquirido Java EE. Por el contrario, se puso un balazo en el pie, eliminando o echando a perder algunas de sus mejores adquisiciones, como WebLogic, GlassFish, OpenOffice ó Hudson. Y es que este siempre ha sido el modus operandi de Oracle: en vez de tomar un producto para hacerlo el líder de su respectivo nicho de mercado, se la ha pasado coleccionando buenos desarrollos, para poco a poco, retirarles el financiamiento. Eventualmente, los deja morir o los “tira a la basura”, al donarlos a la comunidad open-source cuando ya no representan un riesgo para su negocio central.

Si Ellison y su equipo tiene un mínimo de visión, en algún punto se darán cuenta que su verdadero negocio central son las bases de datos; no los servidores de aplicaciones y por supuesto, tampoco Java EE. En ese momento, darán las gracias y dirán adiós, permitiendo que el Java Community Process tome las riendas de la plataforma, dejando que algunos de sus miembros más fuertes se hagan cargo de su evolución. Sin embargo, si Oracle no hace absolutamente nada, tan sólo se necesitan un par de años más para que la entropía se haga tan evidente, que nadie querrá adoptar su funcionalidad, convirtiéndola en tan sólo algunas librerías de uso común en los productos de Oracle. Esto de hecho, ya está pasando en la actualidad: algunos de los clientes con los que he trabajado, están reemplazando sus servidores de aplicaciones empresariales (RedHat JBoss o IBM WebSphere) por simples Tomcats con Spring debido a que “Nos han pedido diversificar nuestro stack tecnológico, porque nuestra dependencia [en Java EE] se ha vuelto potencialmente peligrosa.” Siendo así las cosas, ya no habrá nada que hacer, dando el paso libre para otras tecnologías como MEAN (MongoDB + Express.js + AngularJS + Node.js”).

En fin, el único consuelo de tontos en este caso, es que Oracle se está disparando en el pie una y otra vez, repetidamente. Entonces, después de haber generado suficiente antagonismo con socios y clientes por igual, tal vez finalmente sangre lo suficiente como para que muera y sea comprada por alguien que sí tiene la visión necesaria para llevar esta plataforma hacia el futuro.

h1

Cómo hacer Pruebas de Concepto (POC): un enfoque formal

04/29/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

El verdadero viaje del descubrimiento no consiste en buscar nuevos paisajes, sino en tener nuevos ojos.

Marcel Proust (1871 – 1922). Novelista, ensayista y crítico francés.

Supongamos que nuestro equipo ha estado trabajando durante varias semanas / iteraciones / sprints y todo se ve bastante bien. Sin embargo, el cliente nos pide desarrollar un tipo de requerimiento que nunca hemos hecho anteriormente o del que no estamos seguros cómo implementarlo. ¿Qué hacer cuando el equipo debe enfrentarse a una cuestión técnica o funcional desconocida?

Con frecuencia, los proyectos TI se desenvuelven en un ambiente caótico, para el que es necesario resolver una serie de requerimientos funcionales a través de soluciones tecnológicas que conllevan un cierto riesgo durante su implementación. Para minimizar este riesgo, es necesario llevar a cabo lo que comúnmente conocemos como prueba de concepto (Proof of Concept – POC) o spike – este último, surgido del desarrollo de software ágil. Esta actividad consiste en la construcción de una maqueta o demo con la finalidad de evaluar la factibilidad de un requerimiento funcional vagamente especificado, el desarrollo de un componente de software, la adquisición de un producto, o una combinación de todos ellos. En resumen, cada vez que encontremos requerimientos que posean demasiada complejidad técnica o un fuerte grado de incertidumbre, es necesaria una POC para determinar su factibilidad e impacto. Sin embargo, es necesario recordar que todo requerimiento posee un cierto grado de incertidumbre y riesgo, por lo que las pruebas de concepto deben ser una excepción, no la regla: para los riesgos e incertidumbres “menores”, el equipo debe descubrir la solución mediante el debate, la colaboración, la experimentación y la negociación. Una POC o spike por el contrario, debe reservarse para problemas importantes y complicados de responder. Por ello:

• La prueba debe evaluarse de acuerdo a objetivos claramente definidos entre todos los stakeholders, incluyendo mínimamente, qué medir (funcionalidad de negocio, funcionalidad TI, funcionalidad de sistemas), cómo medirlo (costo, facilidad de uso, escalabilidad) y cómo se realizará la evaluación (a través de un scorecard, escenarios de uso).

• Asimismo, debe tener un tiempo definido (timebox), para hacer el suficiente trabajo como para obtener el valor requerido.

• Finalmente, la prueba debe ser parte integral de la estrategia de implementación del proyecto, habiendo sido debidamente planeada y documentada, incluyendo el tiempo y esfuerzo necesarios para su análisis, diseño e implementación.

Pic: Wright Brothers' Prototype Designs


Cuando Wilbur y Orville Wright perfeccionaron su aeroplano, decidieron probar sus teorías antes de sujetarse a sí mismos sobre el ala de una máquina voladora. Usando modelos a escala en túneles de viento, hicieron pruebas sobre la factibilidad del vuelo tripulado.

Iniciando en 1900, éste fue su primer prototipo, que básicamente era un papalote o cometa. Con él, probaron la idea de deformar la parte superior del ala para controlar el balanceo de la aeronave. Entonces construyeron un planeador en 1901. Este avión volaba como una cometa, pero también podía desempeñarse como un planeador pilotado. Los hermanos Wright ganaron experiencia de vuelo con este avión, descubriendo a la vez varios problemas que tuvieron que superar más tarde, como mayor resistencia al aire y la tendencia a voltearse en pleno vuelo. Después vino el aeroplano de 1902, que fue el primer avión en el mundo que podía ser controlado sobre sus tres ejes (transversal, horizontal y longitudinal). Finalmente, en 1903 construyeron su Wright Flyer: una aeronave pilotada que podía despegar y volar por sus propios medios.

Así, sucesivas pruebas de concepto cumplieron su propósito, dando a los hermanos Wright los datos necesarios para validar que sus objetivos e ideas tenían suficiente mérito como para continuar. Se demostró que la teoría podría funcionar en conjunto con otros factores integrales, como la experiencia necesaria para controlar un avión, materiales de construcción y requerimientos climatológicos.

(Fuente: NASA)

Mejores Prácticas

Una prueba de concepto no debe ejecutarse de manera aislada del resto de la organización TI; ésta debe contar con el apoyo de las áreas relacionadas a su implementación, tales como los usuarios de negocio, proveedores, infraestructura y soporte técnico. Esto porque cualquier retraso durante la ejecución puede volverse crítico. Adicionalmente, es buena idea seguir las siguientes mejores prácticas:

• Limitar el alcance. La solución debe evaluarse contra escenarios representativos; no todos los escenarios de uso. En caso de estar evaluando la adopción de un producto, debemos indicar al cliente de que ésta correrá en las plataformas estándar y usadas por clientes existentes. Asimismo, es muy importante no añadir alcance adicional a la POC, a menos que éste sea obligatorio para el éxito de ésta, y haya sido acordado por todos los stakeholders, incluyéndonos a nosotros.

• Planear con anticipación. A menudo, esta será la primera vez que varias organizaciones, incluyendo terceros, estarán trabajando juntos. Es indispensable asegurar que todos puedan comprometerse a los plazos definidos por la POC. También es importante alinear las reuniones de avance antes de tiempo. Los usuarios usualmente tienen sus actividades del día a día, y los cierres trimestrales o anuales pueden comprometer su disponibilidad para revisión o apoyo.

• Ejecutar la prueba de manera aislada al resto del ambiente productivo. A menos que la integración sea crítica, la conectividad con otros sistemas debe ser simulada. Esto porque casi siempre, obtener los permisos necesarios para integrar la maqueta a otros sistemas informáticos se convierte en todo un reto.

• Mantener a los stakeholders informados con regularidad sobre el progreso de la prueba. Cuando llega el momento de selección y/o evaluación, todos los interesados deben estar alineados a los resultados. Esta alineación es crítica para obtener la aprobación por parte de la dirección TI. El concepto clave aquí es “sin sorpresas”.

• Reuniones diarias de seguimiento. La prueba se llevará a cabo en un lapso de 2 a 8 semanas, por lo que un retraso de uno o dos días puede poner la fecha de entrega en riesgo. Una llamada o reunión de carácter informal al final de cada día asegurará que los retrasos, riesgos y problemas sean abordados y resueltos de forma rápida, minimizando el impacto sobre el resultado final.

Fases de implementación

Una POC consiste generalmente de seis fases que pueden variar en tiempo y esfuerzo de acuerdo a la complejidad, alcance y objetivos de la solución:

Fase
Descripción
Pre-Planificación
Prerrequisitos de la prueba.
Kick-off / Formación
Instalación de software, planificación detallada de la prueba de concepto y diseño de alto nivel de la solución.
Implementación
Diseño e implementación de la solución, en conjunto con retroalimentación del usuario y capacitación en los productos comerciales.
Pruebas / Capacitación a usuario
Verificación de que los escenarios de evaluación y todos los componentes están integrados correctamente. Creación de datos para la evaluación. Los usuarios son capacitados en la solución.
Evaluación
Los usuarios y la organización TI llevan a cabo la evaluación y retroalimentación de la POC.
Conclusión
Crear una presentación de resultados, incluyendo una recomendación.
Fases de ejecución de una prueba de concepto.

La fase de pre-planificación asegura que la prueba esté configurada de forma correcta, y que las dependencias hayan sido identificadas adecuadamente para que no haya retrasos durante su ejecución. Si ésta es la primera vez que se realiza un ejercicio de esta clase, es recomendable iniciar la fase de pre-planificación con al menos un mes de anticipación al kick-off. Si ya se han realizado dos o tres pruebas de concepto, la pre-planificación puede comenzar dos semanas antes del kick-off formal.

Por otro lado, el kick-off es una combinación de inicio formal de la prueba de concepto, así como el período durante el que ésta será planeada a detalle, mientras los compromisos por parte del equipo y proveedores son acordados, para llevar a cabo los escenarios de ejecución: instalación y configuración del o los productos, revisión de requerimientos, planeación y governance, diseño detallado, revisión funcional y arquitectónica, modelo de datos y posiblemente, hitos dentro de la construcción de la POC.

La implementación incluye no sólo la codificación o configuración de la solución, sino también reuniones de seguimiento. Los stakeholders deben ser informados acerca de entregables en tiempo y forma, y qué problemas y riesgos tienen que ser abordados. Esta es también una oportunidad para dar la primera respuesta oficial al o los proveedores acerca de sus fortalezas y debilidades percibidas, dándoles la posibilidad de ajustar su desempeño. Estas reuniones también ayudarán a reducir las desconexiones y posibles fallas de comunicación dentro del equipo.

La fase de pruebas se enfoca en las pruebas funcionales básicas de la solución, que frecuentemente incluyen la capacitación de los usuarios que estarán participando en la prueba de concepto. Es importante establecer las sesiones de capacitación y evaluación antes del inicio de la ejecución, para asegurar la disponibilidad de los stakeholders.

La fase de evaluación es aquella en la que los usuarios y el departamento IT recorren la solución y aplican los criterios para su selección. Se asume que, tanto la funcionalidad de la solución así como los escenarios implementados, serán utilizados para determinar el resultado final de la solución propuesta (aceptación y adopción, o rechazo y búsqueda de nuevas opciones).

Finalmente, la conclusión incluye los entregables de la POC (requerimientos, escenarios, scorecard, evaluación), así como las recomendaciones planteadas, que pueden incluir requerimientos presupuestarios, plan de capacitación, aprovisionamiento de personal y definición y/o cambio en requerimientos para los que se implementó esta prueba. En la siguiente liga se encuentra un ejemplo de dichos entregables.

Recomendaciones adicionales

Nótese que una prueba de concepto puede también formar parte del set de herramientas del desarrollo ágil, pero bajo el entendido que su duración será de un sólo sprint o iteración (2 a 4 semanas). Cuando la solución no pueda implementarse dentro de este periodo de tiempo, primero es necesario desmenuzar el requerimiento (comúnmente denominado como “historia épica”), para posteriormente desarrollar una o varias pruebas de concepto dentro de los límites de tiempo establecidos por el sprint.

También, es importante recordar que una prueba de concepto no nos dice si lo que vamos a hacer es la mejor opción; ésta solamente nos dice si la manera en que abordamos el problema es factible: las POCs tienden a ser muy específicas y concretas; dejando fuera muchas áreas críticas que pueden requerir validación también. Por ejemplo, si estamos evaluando una herramienta de reporteo, una prueba de concepto puede estar enfocada en la generación de algún tipo particular de informe, pero su implementación puede ignorar otra funcionalidad, como la integración de la herramienta con otras aplicaciones, o qué tan personalizables son los reportes generados.

Finalmente, es necesario tomar en cuenta que el diseño de una buena prueba de concepto requeriría una comprensión completa del dominio, ya que es importante identificar por adelantado las diferentes áreas de riesgo, para que éstas sean validadas; en la mayoría de las situaciones esto es imposible, por lo que es muy probable que después de la adopción de alguna solución, el equipo (o peor aún, el cliente) descubra deficiencias en la solución adoptada. Por ello, es necesario sensibilizar al cliente sobre las limitaciones de una prueba de esta naturaleza.

Conclusiones

En el sentido más general, una POC es un prototipo que representa las capacidades o posibilidades técnicas y funcionales de un producto final. Es un modelo a escala que intenta probar que una teoría se puede transformar en una realidad, pero ni nosotros ni el cliente deberíamos esperar a tener la funcionalidad completa. Si bien una prueba de concepto puede ser útil y a veces indispensable, ésta rara vez debe ser vista como la única manera de seleccionar el producto final propuesto: ésta tiene limitaciones y sólo puede proporcionar información que debe ser considerada en combinación con otros factores; así, el propósito principal de la prueba de concepto consiste en proveer certidumbre al respecto de los aspectos básicos de rendimiento y características de un entregable.

h1

De análisis de redes y el Juego de Tronos

04/08/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

El floreciente campo de la informática ha cambiado nuestra visión del mundo físico: de una colección de partículas que interactúan unas con otras, a la de una agitada red de información. Bajo esta manera de ver la naturaleza, las leyes de la física forman parte de un software o algoritmo, mientras el mundo material – el hardware – desempeña el papel de una computadora gigantesca.

Paul Davies (n. 1946). Físico, escritor y locutor británico.

A tan sólo tres semanas para que se estrene la sexta temporada de la serie de televisión, y de manera optimista, un par de meses para que el sexto de siete libros que conforman la odisea completa sea publicado, los fans de la saga del Juego de Tronos de George R.R. Martin estamos esperando con ansia la resolución de varios cliffhangers que involucran a los protagonistas principales de la serie.

Sin embargo, ¿Quiénes son los verdaderos protagonistas de esta historia? Porque si algo hemos aprendido de Mr. R.R. Martin, es que aparentemente, cada vez que un personaje tiende a transformarse en un protagonista central, él o ella es asesinado, usualmente en formas brutales y despiadadas. Esto es exacerbado por el hecho de que el propio autor es todo un troll, quien si bien ofrece algunas pistas, jamás ha divulgado quiénes serán los ganadores del Juego de Tronos. Sin embargo, existen algunos personajes apareciendo constantemente en los libros y la serie de televisión, y que probablemente logren llegar sin tantos raspones al final de esta extraordinaria historia.

Es así como Andrew J. Beveridge, profesor en matemáticas del Colegio Macalester en Saint Paul, Minnesota, realizó un pequeño trabajo de investigación, modelando al mundo de Juego de Tronos como una red social, para después aplicarle el así llamado análisis de redes: una rama de la teoría de grafos que se alimenta de varias disciplinas, incluyendo la economía, la sociología y la informática, para examinar cómo fluye la información entre varios “nodos”. En este caso, se busca encontrar un patrón de comunicación entre los diversos personajes, para identificar los que mayor interacción e influencia tienen sobre otros. Así, usando el tercer libro de la serie como referencia (A Storm of Swords, más o menos equivalente a la tercera temporada de la serie de televisión), cada que dos personajes interactúan dentro de un espacio de 15 palabras, un enlace (o “borde”) se añade entre ambos. Los enlaces se ponderan según la frecuencia de proximidad mutua entre ambos personajes. El resultado habla por sí mismo:

Graph representing the GOT characters

La red social generada para A Storm of Swords. El color de un vértice indica la comunidad inmediata a la que pertenece el personaje. El tamaño del vértice corresponde al valor del PageRank dentro de toda la red, y el tamaño de la etiqueta corresponde a la importancia de intermediación hacia otros personajes. El grosor de un enlace representa su peso.

(Fuente de imagen y pie de página: Mathematical Association of America)

El personaje que obtuvo el primer lugar en casi todos los aspectos es Tyrion Lannister, héroe Byroniano por excelencia quien de hecho, es el favorito de Mr. Martin. Así, Tyrion es el personaje matemáticamente más importante en el Juego de Tronos, y sin el cual, la saga se vería muy limitada en todos sus aspectos. Claro que, Tyrion es seguido por Jon Snow, el 998o. Lord Comandante de la Guardia Nocturna y presunto hijo bastardo de Eddard Stark. Finalmente, tenemos a Sansa Stark, la hija mayor de Eddard, quien se encuentra involucrada en una multitud de difíciles situaciones a lo largo de esta historia.

Por otro lado, Daenerys Targaryen, la aparente legítima heredera al Trono de Hierro, también es muy importante. Sin embargo, en el grafo obtenido por el profesor Beveridge, ella tiene un rango más bajo, debido a que el personaje radica en el continente de Essos, apartada de la acción principal, que transcurre en el ficticio continente de Westeros. De acuerdo al propio Beveridge, el análisis de redes predice hacia dónde se dirigirá la historia, ya que “Daenerys realmente representa el futuro, pues se puede ver lo que está a punto de suceder, en base a la gente con la que ella está vinculada.” Y ciertamente así ocurre: durante los siguientes volúmenes y temporadas de la serie, la historia de esta mujer se ha vuelto infinitamente más importante; sobre todo porque desde el final de la quinta temporada de la serie de televisión, Tyrion ya es parte de la corte real de la “Madre de Dragones”.

De vuelta a la realidad

Sin embargo, dejando de lado el fantástico mundo del Juego de Tronos, esta disciplina tiene aplicaciones mucho más serias: a sabiendas de que el crimen organizado y el terrorismo se han vuelto una actividad social que requiere de medios de comunicación sofisticados, los análisis de redes permiten, mediante software comercial al alcance de todos, identificar a los miembros de este tipo de agrupaciones delictivas. En conjunto con registros telefónicos, es posible hacer un análisis que permita determinar con precisión la identidad de los cabecillas de una conspiración: de acuerdo al sociólogo e investigador en redes sociales Duncan Watts, si las agencias de seguridad estadounidenses hubieran realizado un análisis como éste en los meses previos a los atentados terroristas del 11 de Septiembre de 2001, dichas agrupaciones habrían identificado con facilidad a los principales responsables del ataque, acabando con el plan desde su incepción al haber capturado o eliminado a sus 3 autores intelectuales.

Aunque los detractores pueden considerar este tipo de análisis como un ataque a nuestra privacidad, la realidad es que este tipo de explotación de la información ya es usada de manera constante por corporativos multinacionales, incluyendo los bancos y las compañías de retail, para modelar nuestros gustos y preferencias, personalizando sus ofertas para asegurar una venta. De hecho, otras lo hacen porque ESE es su modelo de negocio: cuando una compañía nos ofrece servicios aparentemente de forma gratuita, es porque nosotros somos el producto. Sin embargo, tampoco deberíamos bajar la guardia: si las reglas del juego (privacidad y almacenamiento de la información personal) no están bien establecidas, esas compañías que muchos de nosotros consideramos nuestras “amigas”, y a las que confiamos nuestra información más íntima, no tienen ningún problema en entregar nuestra información a los malandros, por un precio.

h1

¿Qué es la estrategia TI Bimodal (Bimodal IT) y cómo podemos implementarla?

01/08/2016

Wizdoc [Icon By Buuf]  Tips & Tricks.

No importa qué tan lento vayas, siempre y cuando no te detengas.

Confucio (551 – 479 AC). Profesor, editor, político y filósofo chino.

Hace un par de semanas tuvimos una reunión con cliente relacionada a su estrategia TI y cómo piensa crecer durante el próximo año fiscal. Durante la junta salieron a relucir algunas palabras clave como innovación o implementación ágil. Sin embargo, la frase que nos dio la respuesta a lo que realmente está buscando, se resume en dos palabras: estrategia bimodal. ¿De qué se trata? ¿Por qué algunos la están considerando como la nueva panacea que asegurará la competitividad de las organizaciones TI? ¿Y cuáles son los riesgos encontrados durante su adopción?

Durante el Simposio/ITxpo llevado a cabo por la firma de consultoría e investigación de mercado Gartner en Octubre de 2014, el vicepresidente senior y jefe global de investigación, Peter Sondergaard, señaló que mientras los CIOs no sean capaces de transformar sus departamentos TI de manera que sean más ágiles y competitivos, podrán convertir sus organizaciones mediante un modelo TI Bimodal; de hecho, según Gartner, para el 2017, el 75% de las organizaciones de TI tendrá una capacidad bimodal. Este modelo se describe como “La práctica de gestionar dos modos distintos y coherentes de ejecución de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y precisión. El Modo 2 es exploratorio y no lineal, con énfasis en la agilidad y rapidez.” Así, la organización tendrá dos maneras de llevar a cabo sus iniciativas TI:

Modo 1

• Involucra a proyectos relacionados con el mantenimiento de los sistemas centrales (core systems) – usualmente las bases de datos y sistemas legados.
• Se centra en proporcionar estabilidad y eficiencia, respetando los ciclos de desarrollo más tradicionales, como cascada.

Modo 2

• Involucra a los proyectos que ofrecen innovación y agilidad para el negocio.
• El foco está en la respuesta rápida, mientras trabaja en liberaciones frecuentes (básicamente, desarrollo ágil de software).

No tan rápido

Sin embargo, el problema que intenta atacar Gartner no es nuevo (agilidad vs. estabilidad); por el contrario, si no se lleva a cabo de manera adecuada, el modelo bimodal puede degenerar en una lucha de poder entre las dos áreas, ya que es indispensable una colaboración transparente entre ambas con el afán de agregar valor de negocio. Las consecuencias, descritas en la revista CIO Insight, se enumeran a continuación:

• La primera y de mayor impacto sería la creación de silos artificiales para productos, procesos y personas. Esta es la dirección opuesta a toda tendencia organizacional saludable de TI desde que el término “síndrome del silo funcional” fue acuñado por Phil Ensor en 1988. TI Bimodal en silos significa lanzarse al ruedo precipitadamente, ignorando numerosos estudios publicados durante los últimos cuatro decenios.

• Estancamiento del Modo 1: El enfoque bimodal propone aplicar una curita sobre la herida que representan las plataformas tradicionales, pero no hace nada por detener la hemorragia. Este modelo institucionaliza el estancamiento, al desalentar la innovación en plataformas legadas bajo el pretexto de que “si no está roto, no lo arregles”.

• Rigidez del Modo 2: En palabras de Gartner, “el Modo 2 requiere un enfoque riguroso y disciplinado”, así que el modelo bimodal prescribe un flujo de proceso definido, previsible y lógico en torno a lo que en esencia, es un proceso impredecible para la experimentación y el descubrimiento. Algo así como “Pintura por números para la obra de Jackson Pollock.”

• Sobre-simplificación de procesos: Las nuevas aplicaciones se acuñarán en torno a uno de dos modos y serán siempre encerradas en un modus operandi que sin duda resultará ser inadecuado a largo plazo. TI Bimodal cierra las puertas a las aplicaciones legadas del Modo 1 para evolucionar a las ofertas ágiles del Modo 2; por el contrario se endurecerán las condiciones para que un prototipo ágil del Modo 2 pueda convertirse en una oferta de servicio más estable de acuerdo al Modo 1.

¿Cómo implementarla?

Aunque TI Bimodal suena bastante razonable sobre el papel, en la práctica los principales retos a sortear incluyen la priorización de los proyectos, la distribución de recursos entre ambos modos, integración o intercepción de proyectos (ya que por ejemplo, una aplicación móvil no es nada sin un back-end estable que la soporte) y cómo mantener a la organización, proveedores y socios de negocios apegados a esta visión. En pocas palabras, para alcanzar la meta planteada, es fundamental definir un gobierno TI o governance adecuado. Aunque la definición completa de un gobierno TI no es el objetivo de este post, baste decir que éste debe incluir los siguientes puntos:

• La alineación entre la estrategia de la organización y las TI.

• Obtención de valor que las TI generan para la organización.

• Mecanismos que permitan mediciones apropiadas para poder valorar las TI en su conjunto y poder tomar decisiones respecto a su gobierno.

• Gestión del riesgo que en un momento dado pueda afectar e impactar negativamente en las actividades y procesos de la organización.

• Gestión de los recursos TI y la utilización óptima de los mismos.

El gobierno TI debe facilitar un modelo transparente en el que todos los interesados tengan visibilidad sobre el día a día de las operaciones y el avance del programa estratégico. Asimismo, el modelo debe proveer una comunicación y priorización claras, que ayuden en la detección y resolución de problemas más rápidamente. Por ello, el proceso de gobierno debe abordar los siguientes tres niveles de revisión:

1. Estratégico: Cuando a un nivel de dirección ejecutiva, los diferentes grupos de interés puedan mantener y hacer crecer la relación (evitando caer en luchas de poder), resolviendo asuntos importantes, manteniendo la dirección establecida y aprobando los cambios estratégicos y el plan para el futuro.

2. Táctico: Donde a través de reuniones periódicas de los grupos de interés, éstos son capaces de asegurar que se está avanzando de acuerdo a los objetivos generales del programa.

3. Operacional: Cuando todos son capaces de trabajar sobre una base del día a día para ofrecer los servicios y entregables TI, respondiendo a peticiones, problemas y consultas, en línea con los objetivos del programa.

Pic: Bimodal IT Governance Example


Para que TI Bimodal – o cualquier otra estrategia de TI – tenga éxito, la visión tiene que ser compartida por todos los niveles de la organización: la alta dirección, proveedores, socios de negocio, gerentes de proyecto y equipos de trabajo por igual. Además, el éxito se mide no sólo por la entrega de valor a la organización de TI, sino por el valor del negocio; es decir, que la estrategia TI beneficia al negocio de una manera cuantificable. El éxito del programa, por lo tanto, debe ser comunicada a todos los niveles de la organización.

Parafraseando a George Orwell, aunque los tres niveles de revisión son igualmente importantes, algunos son más iguales que otros: el nivel estratégico tiene como principal responsabilidad mantener alienada la estrategia con los objetivos de negocio, monitoreando el desempeño de las demás áreas y detectando y resolviendo cualquier riesgo de alto nivel que se llegue a presentar; por otro lado, el nivel operativo lleva a cabo los proyectos individuales, reportando su progreso y asegurándose que las métricas impuestas por los otros dos niveles se cumplan. Sin embargo, el nivel que es crucial durante la implementación es el nivel táctico (la Oficina de Gestión de Proyectos o PMO, así como el Centro de Excelencia o CoE) ya que tiene por principal responsabilidad:

• Generar estándares y procesos, así como seleccionar las herramientas y tecnologías que usará el resto de la organización.

• Revisar el rendimiento y apego a normas de desempeño acordados para todos los grupos.

• Desarrollar el programa de implementación de la estrategia.

• Llevar a cabo el presupuesto, planeación y asignación de recursos.

• Asegurarse de que todas las políticas, planes, normas, etc. permean a los equipos de la organización.

• Resolver problemas tácticos escalados con el Comité de Gobierno estratégico (Steering Committee) y

• Escalar problemas al Comité de Gobierno cuando sea apropiado (por ejemplo, asuntos contractuales).

Algunos tips durante la adopción de este modelo

La gran ventaja de Bimodal es que la organización ya debería poseer un área de operaciones/desarrollo relativamente madura trabajando en Modo 1; esta madurez es precisamente la que asegura una implementación ordenada y estable, pero impide que iniciativas “para ayer” se concreten eficazmente. Por lo tanto, el proceso de adopción debe enfocarse a la creación del Modo 2 y cómo sus equipos deben interactuar y coordinarse eficientemente con los equipos del Modo 1. Por lo tanto, una adopción debe considerar entre otros, los siguientes puntos dentro del programa de implementación de estrategia:

• Una evaluación de la capacidad (readiness assessment) para convertir un segmento de la organización al Modo 2 de operación. Esto permitirá saber qué equipos y proyectos pueden generar el mayor valor de negocio en el menor tiempo posible. Por ejemplo, los proyectos más apropiados para llevarse a cabo en el Modo 2 son aquellos que poseen 1) fechas de entrega muy agresivas, 2) un alto grado de complejidad, y 3) un alto grado de innovación.

• Identificar uno o varios coaches versados en el Modo 2 de operación – Scrum, Lean, Kanban, V-Model, etcétera – que puedan resolver las dudas durante la implementación. Éstos por supuesto, deben ir de la mano con el Centro de Excelencia para definir los procesos, herramientas y entregables de gestión y desarrollo ágil que adoptará la organización.

• En caso de que los equipos del Modo 2 se hayan integrado con el personal original de la organización, es indispensable enfocarse en el cambio cultural. Si bien las prácticas y herramientas ágiles son importantes, establecer una mentalidad ágil es indispensable. Esto implica creer firmemente en el empowerment, liderazgo subordinado o equipos multidisciplinarios. El beneficio es que aseguramos una mentalidad de colaboración y urgencia para satisfacer las cambiantes demandas del negocio.

• Para el momento en que se inicie el delivery de equipos en el Modo 2, ya se debe haber seleccionado una herramienta de planeación (por ejemplo, JIRA o VersionOne), se debe haber proporcionado el entrenamiento adecuado a los equipos y se deben haber definido las métricas mínimas para que de manera periódica, pueda existir una rendición de cuentas al Comité de Gobierno.

• Finalmente, una vez que se han dado los primeros pilotos de adopción del Modo 2 y se ha establecido la manera en que ambos tipos de equipo estarán colaborando, es indispensable generar un proceso de mejora continua para perfeccionar la integración de todos los interesados. Para este momento, iniciar la estandarización – por ejemplo, certificar los proyectos corriendo en Modo 1 en CMMi-5 y los proyectos ejecutados en Modo 2 en CMMi-3 – ya es posible.

Conclusiones

La estrategia Bimodal NO es la bala de plata. Es tan sólo un paso intermedio hacia la introducción de prácticas como DevOps. A final de cuentas, lo que cualquier organización debe buscar, es la convergencia para actualizar sus procesos e infraestructura a la realidad del mercado. Hace algún tiempo, el analista independiente Jason Bloomberg dio su propio punto de vista al respecto de lo que él llamó una “receta para el desastre” de Gartner, añadiendo su propia recomendación: … para que la transformación digital tenga éxito, debe ser de extremo a extremo – con los clientes en un extremo y los sistemas legados del otro. TI tradicional, por supuesto, sigue siendo responsable de los sistemas legados.

Así, el enfoque debe ser el de empresas exitosas como Apple, Amazon o Google:

• ¿Cómo podemos deleitar a los clientes con nuevos productos y un mejor servicio?

• ¿Cómo se puede mejorar continuamente nuestro negocio con pequeños incrementos?

• ¿Cómo podemos optimizar la cadena de valor?

• ¿Cómo nos aseguramos de que el negocio impulsa el cambio y no el departamento de TI o marketing?

La clave reside en contestar estas preguntas honestamente y trabajar en ello… o formar parte del registro fósil de empresas fallidas, junto a anti-ejemplos tales como Eastman Kodak, PanAm y Compaq.

h1

CMMI in Mexico and the world (2015)

09/22/2015

Wizdoc [Icon By Buuf]  Tips & Tricks.

Quality is the best business plan.

John Lasseter (b. 1957). American animator and film director. Chief creative officer of Pixar Animation Studios, Walt Disney Animation Studios and DisneyToon Animation Studios.

For some years now, we have been presenting the status of CMMI around the world, as this quality model is a good indicator of the overall health of the global IT industry. Previously, we explained its origin, and described its different constellations and logic behind their inclusion in this study. For clarity, we present a brief summary justifying its history and importance:

  • CMMI stands for Capability Maturity Model Integration.
  • This is a model for improvement and evaluation of processes, which focuses on certain practices of development, maintenance and operation of software systems, allowing CMMI to evaluate and measure the maturity of the software development process used by any organization.
  • CMMI measures this maturity on a scale of L1 (chaotic) to L5 (continuous improvement).
  • CMMI began its development in 1987 by the Software Engineering Institute (SEI) of Carnegie Mellon University in Pittsburgh, USA.
  • Said model was commissioned by the Government of the United States to assess its vendors, especially those allocated to contracts for defense and space research, in order to base its bids not only on cost but also on the vendor’s maturity.
  • CMMI was originally designed for the development and maintenance of software, but was later extended to systems engineering, vendor management, development and integration of products and processes, human resource management and software acquisition.
  • While CMMI proponents see it as a tool to create better quality products and increase added value, as well as customer satisfaction, in practice the importance of CMMI lies in a greater catch of larger, high-risk projects, resulting in more attractive returns.
  • Finally, CMMI is a business-oriented tool; it is not people-centered. That is to say, it will not make life easier nor result in a more productive staff; nor it will decrease production costs. It just makes sure the organization adheres to a standard and its people “know what they’re doing”.

CMMI in the world

On September 10, 2015, there were 5014 active CMMI appraisals, from levels L2 to L5, spread over 83 countries worldwide. This amounted to an increase of 8% with regard to the certificates recorded on the previous study (4031 certifications on July 2012). The list is as follows:

Country / Level L2 L3 L4 L5 Total
China 20 1843 87 128 2078
United States 267 639 12 53 971
India 14 381 2 148 545
Mexico 110 84 8 22 224
Spain 58 62 13 133
Korea, Republic Of 29 85 11 6 131
Brazil 48 52 1 7 108
Colombia 5 64 15 84
Japan 13 42 8 6 69
France 32 21 53
Thailand 9 38 3 50
Taiwan 14 23 1 38
Turkey 1 32 1 1 35
Italy 12 18 1 31
Chile 15 10 5 30
Germany 11 19 30
United Kingdom 6 18 3 27
Argentina 4 14 8 26
Portugal 13 7 5 25
Viet Nam 21 4 25
Canada 8 14 3 25
Peru 3 17 3 23
Philippines 11 6 17
Egypt 5 8 2 15
Netherlands 2 5 5 12
Malaysia 1 10 1 12
Bangladesh 11 11
Morocco 3 6 1 10
Belgium 4 6 10
Israel 2 7 9
Sri Lanka 6 1 2 9
Poland 2 6 1 9
Singapore 1 5 2 8
Hong Kong 2 4 2 8
Australia 1 6 1 8
Switzerland 3 3 1 7
Pakistan 2 5 7
Russia 3 3 6
Saudi Arabia 3 2 5
Indonesia 5 5
South Africa 4 1 5
Uruguay 1 3 4
Ecuador 2 2 4
Czech Republic 1 2 1 4
Kuwait 2 1 1 4
Hungary 1 2 3
Ukraine 1 2 3
Romania 2 1 3
Latvia 3 3
Slovakia 3 3
Lebanon 3 3
United Arab Emirates 1 2 3
Luxembourg 2 1 3
Belarus 1 1 2
Finland 2 2
Ireland 2 2
Angola 2 2
Kenya 2 2
Nigeria 2 2
Paraguay 1 1 2
Austria 1 1 2
Cyprus 1 1 2
Somalia 2 2
Venezuela 1 1
Denmark 1 1
Macedonia 1 1
Qatar 1 1
Brunei Darussalam 1 1
Kazakhstan 1 1
Bolivia 1 1
Costa Rica 1 1
Jamaica 1 1
Panama 1 1
Norway 1 1
Jordan 1 1
Tunisia 1 1
Mauritius 1 1
Mozambique 1 1
New Zealand 1 1
Guatemala 1 1
Bulgaria 1 1
Greece 1 1
Sweden 1 1
TOTAL 737 3658 134 485 5014
Table of appraisals by country, for each level of maturity. Information as of September 10, 2015.

The most significant change with respect to the previous version, is the dramatic decrease in the number of L2 appraisals (737 in 2015 vs. 872 in 2012). This is because during the last three years, organizations have matured to higher levels of CMMI, or because of the economic difficulties that are suffering Europe, China and their respective spheres of influence, many companies that had a low level of maturity are gone. The key point here is that there are not enough L2 companies being created, which in some years may lead to further consolidation of IT companies, and possibly fewer labor opportunities. Naturally, the regional outlook has been affected by this situation:

•  Anglo-America (US, Canada) has maintained a steady growth in number of certifications with just over 4% per year (996 in 2015 vs. 888 appraisals in 2012), relatively on par to its economic growth over the last three years. By contrast, in terms of L5 evaluations, their number decreased from 59 to 56 over the same period.

•  Latin America has grown enormously over the past three years, about 21% annually (511 appraisals in 2015 vs. 316 in 2012). This block is being pushed mainly by Mexico and Colombia (with 224 and 84 certifications, respectively). And regarding the L5 certifications, today Mexicans and Colombians can be proud of the level of maturity found in their organizations, because by having 22 and 15 L5 certifications respectively, both countries are becoming the main IT service providers in the region. Unfortunately, you cannot say the same for Brazil, because due to its “World Cup effect“, this South American power has stalled, growing or replacing only 7 certifications in the last three years.

•  With the economic problems being faced by southern Europe – Portugal, Spain, France, Italy and especially Greece – the whole region is going down with 379 appraisals in 2015, down from the 406 it held in 2012. Although the fall in number of certifications is more pronounced in Spain, with 20 fewer certifications than in 2012, Western Europe in general has decreased the number of its certified organizations. The exception is Eastern Europe, especially Poland (+3) and the Czech Republic (+2). Of course, the European maturity level has increased, reaching 41 L5 in these three years.

•  The Middle East has remained as a hub of IT services for years – especially Egypt and Israel – demonstrating continuity with 38 certifications, of which 10 are L5.

•  Although Africa has made an extraordinary increase (26 appraisals in 2015 vs. 8 in 2012), the continent remains underdeveloped in terms of IT industry. This is very worrying, as a continent of 1.1 billion people still does not reach the technological maturity of a country like Argentina, which has the same number of certifications, but has a population of only 42 million.

•  Australia and New Zealand have remained relatively stable (9 certifications in 2015 vs. 8 in 2012).

•  Finally, Asia (3055 certifications in 2015 vs. 2248 in 2012) has reached an annual growth of 12% being led by China and India (2078 and 545 appraisals, respectively). Both countries together have just over half of the L5 certifications in the world (276 out of 485 certifications). However, this does not detract from other countries such as Thailand (50 certifications), Turkey (35) and Vietnam (25), having made a successful effort to attract investment to the IT industry.

CMMI in Mexico: using the Fuaaa

On September 10, 2015, Mexico had 224 certifications distributed among 219 organizations, making the country the fourth in the world with more evaluations in this model, after China, India and the United States. Having overtaken Brazil, Spain, Japan and South Korea in number of certifications, Mexico is also fourth in L5 assessments (22), behind the two Asian and American giants, respectively.

If each unit is considered as independently assessed – for example, HITSS Solutions (21855) has distributed functions between the states of Queretaro and Aguascalientes, counting as two certifications – there would be a total of 251 independent evaluations, distributed among Mexican states as follows:

State / Level L2 L3 L4 L5 Total
Federal District (a.k.a. Mexico City) 16 36 3 14 69
Jalisco 38 18 3 4 63
Nuevo León 10 13 4 27
Sinaloa 22 3 25
Querétaro 4 5 6 15
Yucatán 4 2 1 7
Coahuila 4 2 6
Chihuahua 2 2 1 5
Guanajuato 2 3 5
Aguascalientes 2 2 4
México 1 3 4
Veracruz 3 1 4
Zacatecas 2 1 3
Baja California 1 2 3
Michoacán 1 1 2
Tamaulipas 1 1 2
Durango 2 2
Tlaxcala 2 2
Puebla 1 1
Tabasco 1 1
Sonora 1 1
TOTAL 118 94 8 31 251
Table of certifications by state, for each level of maturity. Information as of September 10, 2015.

• It is notorious the ongoing rivalry between Jalisco and the Federal District for supremacy in terms of CMMI adoption. While both entities had 35 and 28 certifications in 2012, three years later both have 63 and 69 certifications, respectively. Federal District organizations have focused on consolidating the L5 level, while the Mexican Silicon Valley, being more dynamic, has 38 L2 organizations: just over 32% of the country overall.

• On the third place is the northern state of Nuevo Leon, which agglomerates 27 certifications, and following very closely, the state of Sinaloa with 25. It is worth mentioning that for some time, both states also have become strong rivals seeking to offer nearshoring services to the United States, taking advantage of proximity to customers in the case of Nuevo Leon (bordering Texas upstate), or cheap labor and relative proximity to California, as is the case with Sinaloa.

• Although the state of Queretaro is still establishing itself as an important industrial and IT services hub with 15 appraisals – of which 6 are L5: second place nationally – the surprise this time is the state of Yucatan, because it had no certifications in 2012, having attained 7 in the last three years. The most significant point of its growth is that it already has a L4 certification, which will become a new L5 in less than a year.

Conclusions

It’s interesting to see how the North-South divide does not apply to IT: so distant nations that are hardly heard in the news – such as Thailand and the Philippines – are powers within this industry. Of course, although it is not reflected in this study, there are multinationals that are responsible for these success stories: for example, the renowned Irish consulting company Accenture owns seventeen L3 certifications, one L4 and nine L5, distributed throughout Europe, Asia and Latin America – 27 in total, equal in number to those of the entire United Kingdom.

On the other hand, it is sad to see how powers in this area (Brazil, Spain) are deflating due to economic problems, as this will impact the medium and long term viability of their IT industries. This in fact is already evident in the case of Spain, since in recent years, Mexico has seen a new wave of Spanish immigrants fleeing the current economic crisis, and whom for better or worse, have benefited Mexico at the expense of Spain.

Speaking of Mexico, it is a pleasant surprise to see how the country has risen to the fourth place in the world rankings. Perhaps due to greater economic integration we have with the United States, or possibly some of the programs implemented by the federal government are paying off. Leaving aside the cause for another time, the reality is that by having an IT market worth approximately 23.63 billion dollars and an expected growth of 6.4% for 2015, Mexico is becoming one of the major global players. According to Gartner:

  • On 2016, one in five of the leading providers of local IT services will be acquired by a multinational.
  • By 2017, the dynamic server market in Mexico will experience the highest growth in the region.
  • On 2018, Mexico will become a Latin American power in data center services, which will result in large-scale creation of several dozen data centers.
  • By 2018, retailers in Mexico will double their existing investments in CRM, ERP, supply chain and BI due to the rapid growth of the retail market.

However, we must not lower our guard: with an economic downturn in our doorsteps, many of these plans can come down. For now, let’s have a toast: this is an occasion to celebrate.

h1

CMMI en México y el mundo (2015)

09/15/2015

Wizdoc [Icon By Buuf]  Tips & Tricks.

La calidad es el mejor plan de negocios.

John Lasseter (n. 1957). Animador y director de cine estadounidense. Director creativo de los Pixar Animation Studios, Walt Disney Animation Studios y DisneyToon Animation Studios.

Desde hace unos años, hemos venido presentando el estatus de CMMI alrededor del mundo, debido a que este modelo de calidad es un buen indicador de la salud general de la industria IT a nivel global. Anteriormente, explicamos su origen, y describimos sus diferentes constelaciones y lógica usada para incluirlas en este estudio. Para efectos de claridad, a continuación presentamos un pequeño resumen justificando su historia e importancia:

  • CMMI significa Capability Maturity Model Integration (Español: Integración de Modelos de Madurez de Capacidades).
  • Éste es un modelo de mejora y evaluación de procesos, que está centrado en ciertas prácticas del desarrollo, mantenimiento y operación de sistemas de software, por lo que CMMI permite evaluar y medir la madurez del proceso de desarrollo de software en una organización.
  • CMMI mide esta madurez en una escala de L1 (caótico) a L5 (mejora continua).
  • CMMI inició su desarrollo en 1987 por el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon en Pittsburgh, Estados Unidos.
  • Dicho modelo fue encargado por el gobierno de los Estados Unidos para evaluar a sus proveedores, especialmente aquellos asignados a contratos para la defensa e investigación espacial, con la finalidad de basar sus licitaciones no sólo en costo, sino también en la madurez del proveedor.
  • CMMI fue concebido inicialmente para el desarrollo y mantenimiento de software, pero más tarde fue extendido a la ingeniería de sistemas, gestión de proveedores, desarrollo e integración de productos y procesos, gestión de recursos humanos y adquisición de software.
  • Si bien los proponentes de CMMI lo consideran como una herramienta para crear productos de mayor calidad, así como incrementar el valor agregado y satisfacción al cliente, en la práctica la importancia de CMMI radica en una mayor captación de proyectos más grandes y de alto riesgo, que equivalen a rendimientos más atractivos.
  • Por último, CMMI es una herramienta orientada a la empresa; no a las personas. Es decir, no hará la vida del personal más fácil o productiva; tampoco disminuirá costos de producción. Sólo permite asegurarse que la organización se adhiere a un estándar y su gente “sabe lo que está haciendo”.

CMMI en el mundo

Al 10 de Septiembre de 2015, existían 5014 certificaciones CMMI activas, desde el nivel L2 hasta el L5, repartidas entre 83 países alrededor del mundo. Esto significó un incremento del 8% anual con respecto a las certificaciones contabilizadas en el estudio previo (4031 certificaciones en Julio de 2012). La lista es la siguiente:

País / Nivel L2 L3 L4 L5 Total
China 20 1843 87 128 2078
United States 267 639 12 53 971
India 14 381 2 148 545
Mexico 110 84 8 22 224
Spain 58 62 13 133
Korea, Republic Of 29 85 11 6 131
Brazil 48 52 1 7 108
Colombia 5 64 15 84
Japan 13 42 8 6 69
France 32 21 53
Thailand 9 38 3 50
Taiwan 14 23 1 38
Turkey 1 32 1 1 35
Italy 12 18 1 31
Chile 15 10 5 30
Germany 11 19 30
United Kingdom 6 18 3 27
Argentina 4 14 8 26
Portugal 13 7 5 25
Viet Nam 21 4 25
Canada 8 14 3 25
Peru 3 17 3 23
Philippines 11 6 17
Egypt 5 8 2 15
Netherlands 2 5 5 12
Malaysia 1 10 1 12
Bangladesh 11 11
Morocco 3 6 1 10
Belgium 4 6 10
Israel 2 7 9
Sri Lanka 6 1 2 9
Poland 2 6 1 9
Singapore 1 5 2 8
Hong Kong 2 4 2 8
Australia 1 6 1 8
Switzerland 3 3 1 7
Pakistan 2 5 7
Russia 3 3 6
Saudi Arabia 3 2 5
Indonesia 5 5
South Africa 4 1 5
Uruguay 1 3 4
Ecuador 2 2 4
Czech Republic 1 2 1 4
Kuwait 2 1 1 4
Hungary 1 2 3
Ukraine 1 2 3
Romania 2 1 3
Latvia 3 3
Slovakia 3 3
Lebanon 3 3
United Arab Emirates 1 2 3
Luxembourg 2 1 3
Belarus 1 1 2
Finland 2 2
Ireland 2 2
Angola 2 2
Kenya 2 2
Nigeria 2 2
Paraguay 1 1 2
Austria 1 1 2
Cyprus 1 1 2
Somalia 2 2
Venezuela 1 1
Denmark 1 1
Macedonia 1 1
Qatar 1 1
Brunei Darussalam 1 1
Kazakhstan 1 1
Bolivia 1 1
Costa Rica 1 1
Jamaica 1 1
Panama 1 1
Norway 1 1
Jordan 1 1
Tunisia 1 1
Mauritius 1 1
Mozambique 1 1
New Zealand 1 1
Guatemala 1 1
Bulgaria 1 1
Greece 1 1
Sweden 1 1
TOTAL 737 3658 134 485 5014
Tabla de certificaciones por país, para cada nivel de madurez. Información actualizada al 10 de Septiembre de 2015.

El cambio más significativo con respecto a la versión anterior, es la dramática disminución en el número de certificaciones L2 (737 certificaciones en 2015 vs. 872 en 2012). Esto se debe a que durante estos últimos tres años, las organizaciones han madurado hacia los niveles superiores de CMMI, o que debido a las dificultades económicas que están sufriendo Europa, China y sus respectivas esferas de influencia, muchas empresas que tenían un nivel bajo de madurez han desaparecido. El punto clave aquí es que no se están creando suficientes empresas L2, lo que en algunos años puede desembocar en mayor consolidación de empresas de TI, y posiblemente, menores oportunidades laborales. Naturalmente, el panorama regional se ha visto afectado por esta situación:

•  Anglo-América (Estados Unidos, Canadá) ha mantenido un crecimiento sostenido en número de certificaciones con poco más del 4% anual (996 certificaciones en 2015 vs. 888 en 2012), relativamente a la par de su crecimiento económico durante estos últimos tres años. Por el contrario, en términos de certificaciones L5, su número ha disminuido de 59 a 56 a lo largo de este periodo de tiempo.

•  América Latina ha crecido enormemente durante estos tres años, en alrededor del 21% anualmente (511 certificaciones en 2015 vs. 316 en 2012). Este bloque está siendo empujado principalmente por México y Colombia (224 y 84 certificaciones, respectivamente). Y en cuanto a las certificaciones L5, hoy por hoy, los mexicanos y colombianos pueden sentirse orgullosos del nivel de madurez encontrado en sus organizaciones, porque al contar con 22 y 15 certificaciones L5, ambos países se están convirtiendo en los principales proveedores de servicios TI de la región. Lamentablemente, no se puede decir lo mismo de Brasil, pues debido a su “Efecto Mundial de Fútbol“, la potencia sudamericana se ha estancado, creciendo o reemplazando tan sólo 7 certificaciones en los últimos tres años.

•  Con los problemas económicos que está enfrentando Europa Meridional – Portugal, España, Francia, Italia y sobre todo, Grecia – la región en su conjunto va a la baja con 379 certificaciones en 2015, disminuyendo de las 406 que poseía en 2012. Aunque la caída en número de certificaciones es más pronunciada en España, con 20 certificaciones menos que en 2012, en términos generales toda Europa Occidental ha disminuido en número de organizaciones certificadas. La excepción es Europa Oriental, especialmente Polonia (+3) y la República Checa (+2). Claro que, el nivel de madurez Europeo se ha visto incrementado, llegando a 41 L5 en estos tres años.

•  El Medio Oriente ha permanecido como un centro de servicios TI por años – especialmente Egipto e Israel – demostrando continuidad con 38 certificaciones, de las cuales 10 son L5.

•  Aunque África ha realizado un incremento extraordinario (26 certificaciones en 2015 vs. 8 en 2012), éste continente sigue estando poco desarrollado en términos de industria TI. Esto es muy preocupante, ya que un continente de 1100 millones de personas no alcanza la madurez tecnológica de un país como Argentina, que posee el mismo número de certificaciones, pero cuenta con una población de apenas 42 millones de habitantes.

•  Australia y Nueva Zelanda se han mantenido relativamente estables (9 certificaciones en 2015 vs. 8 en 2012).

•  Finalmente, Asia (3055 certificaciones en 2015 vs. 2248 en 2012) ha alcanzado un crecimiento del 12% anual con China y la India a la cabeza (2078 y 545 certificaciones, respectivamente). Ambos países en su conjunto poseen poco más de la mitad de las certificaciones L5 en el mundo (276 certificaciones de 485). Sin embargo, esto no le resta a otros países como Tailandia (50 certificaciones), Turquía (35) y Vietnam (25), quienes han hecho un esfuerzo exitoso por atraer inversión a la industria TI.

CMMI en México: usando el Fuaaa

Al 10 de Septiembre de 2015, México contaba con 224 certificaciones distribuidas entre 219 organizaciones, convirtiendo al país en el cuarto en el mundo con mayor número de evaluaciones en este modelo, después de China, India y los Estados Unidos. Habiendo superado a Brasil, España, Japón y Corea del Sur en número de certificaciones, también México queda en cuarto lugar en evaluaciones L5 (22), detrás de los dos gigantes asiáticos y el norteamericano, respectivamente.

Si se considera cada unidad evaluada de manera independiente – por ejemplo, HITSS Solutions (21855) tiene funciones distribuidas entre los estados de Querétaro y Aguascalientes, contando como dos certificaciones – existirían un total de 251 evaluaciones independientes, distribuidas entre los estados mexicanos de la siguiente manera:

Estado / Nivel L2 L3 L4 L5 Total
Distrito Federal 16 36 3 14 69
Jalisco 38 18 3 4 63
Nuevo León 10 13 4 27
Sinaloa 22 3 25
Querétaro 4 5 6 15
Yucatán 4 2 1 7
Coahuila 4 2 6
Chihuahua 2 2 1 5
Guanajuato 2 3 5
Aguascalientes 2 2 4
México 1 3 4
Veracruz 3 1 4
Zacatecas 2 1 3
Baja California 1 2 3
Michoacán 1 1 2
Tamaulipas 1 1 2
Durango 2 2
Tlaxcala 2 2
Puebla 1 1
Tabasco 1 1
Sonora 1 1
TOTAL 118 94 8 31 251
Tabla de certificaciones por estado, para cada nivel de madurez. Información actualizada al 10 de Septiembre de 2015.

• Es notoria la continua rivalidad entre Jalisco y el Distrito Federal por la supremacía en cuanto a la adopción de CMMI. Mientras en 2012 ambas entidades federativas tenían 35 y 28 certificaciones, tres años más tarde ambas cuentan con 63 y 69 certificaciones respectivamente. Las organizaciones del Distrito Federal se han enfocado en la consolidación del nivel L5, mientras el Silicon Valley Mexicano, siendo mucho más dinámico, tiene 38 organizaciones con L2: poco más del 32% total del país.

• En tercer lugar tenemos al norteño estado de Nuevo León, que aglomera 27 certificaciones, y pisándole los talones, el estado de Sinaloa con 25. Vale la pena mencionar que desde hace algún tiempo, ambos estados también se han convertido en fuertes rivales buscando ofrecer servicios de nearshoring hacia los Estados Unidos, aprovechando la cercanía con los clientes en el caso de Nuevo León (limitando con Texas al norte del estado), o la mano de obra barata y relativa cercanía con California, como es el caso de Sinaloa.

• Aunque el estado de Querétaro sigue estableciéndose como un importante centro industrial y de servicios TI con 15 certificaciones – de las cuales 6 son L5: el segundo lugar a nivel nacional – la sorpresa en esta ocasión es el estado de Yucatán, pues sin tener una sola certificación en 2012, ha alcanzado 7 en los últimos tres años. Lo más significativo de su crecimiento es que posee una certificación L4, la cual se convertirá en una nueva L5 en menos de un año.

Conclusiones

Es interesante ver cómo la brecha Norte-Sur no aplica en TI: naciones tan distantes y de las que casi no escuchamos en las noticias – como Tailandia o las Filipinas – son potencias en esta industria. Claro que, aunque no se ve reflejado en este estudio, hay multinacionales que son las responsables de estas historias de éxito: por ejemplo, la reconocida empresa de consultoría irlandesa Accenture es dueña de diecisiete certificaciones L3, una L4 y nueve L5 repartidas entre Europa, Asia y América Latina – 27 en total, equivalentes en número a las de todo el Reino Unido.

Por otro lado, es triste ver cómo potencias en este rubro (Brasil, España) se están desinflando debido a problemas económicos, pues esto impactará a mediano y largo plazo en la viabilidad de sus industrias TI. Esto de hecho, ya es notorio en el caso de España, pues en los últimos años, México ha visto una nueva oleada de inmigrantes españoles que huyen de la crisis económica y que para bien o para mal, han beneficiado a México, a costa de España.

Y hablando de México, es una grata sorpresa ver cómo el país ha subido al cuarto lugar en el ranking mundial. Tal vez se deba a la mayor integración económica que tenemos con los Estados Unidos, o posiblemente algunos de los programas implementados por el gobierno federal están dando resultados. Dejando de lado la causa para otro momento, la realidad es que con un mercado TI de aproximadamente 23,634 millones de dólares y un crecimiento esperado para 2015 del 6.4%, Mexico se está posicionando como uno de los grandes jugadores globales. De acuerdo a Gartner:

  • En el 2016, uno de cada cinco de los principales proveedores de servicios TI locales serán adquiridos por una multinacional.
  • Para el 2017, el mercado de servidores dinámicos en México experimentará el mayor crecimiento en la región.
  • En el 2018, México se convertirá en una potencia a nivel Latinoamérica en materia de servicios de centros de datos, lo que dará como resultado la creación a gran escala de varias decenas de centros de datos.
  • Para el 2018, los minoristas en México duplicarán sus inversiones actuales en CRM, ERP, gestión en la cadena de suministro y en BI, debido al rápido crecimiento del mercado minorista.

Sin embargo, no hay que bajar la guardia: con una desaceleración económica en puerta, muchos de estos planes se pueden venir abajo. Por lo pronto, brindemos: ésta es una ocasión para celebrar.