domingo, 26 de abril de 2015

Una propuesta de atributos marco para una arquitectura en tecnología




En cada ocasión que los responsables de las diferenes áreas de la TI se encuentran en un proceso de re-definición, actualización tecnológica o cualquier proceso de mejora continua que involucra a la parte tecnológica, es común, no tener una definición de atributos que la existente y la nueva arquitectura en tecnología deben cumplir como parte de un proceso de alineación que debe venir desde la planeación estratégica de la organización. En Togaf por ejemplo, se da mucha importancia a esta definición ya que es uno de los aspectos más relevantes al momento de llevar a cabo las decisiones a lo largo de las diferentes fases de desarrollo de la arquitectura empresarial.

La definición de estos atributos es también, confusa algunas veces y nueva para muchos responsables de la TI, es por eso, que me doy a la tarea de proponer una serie de atributos que puedan ser de utilidad para todos aquellos inmersos en esta tarea.

Atributos marco propuestos para una arquitectura en tecnología
  1. Fácil aprovisionamiento
    • Considerar que los componentes de la arquitectura, permitan la habilitación de funciones que lleven a una automatización en el aprovisionamiento de cambios (altas, bajas y cambios), lo más fácil y rápido posible. En este contexto, la aplicación de soluciones de SDN (Software Defined Networking) es una de las herramientas que debe ser tomada en cuenta. 
    • Aquí pertenecen por ejemplo, algunos de los aspectos de configuración de la red más complejos, demandantes en tiempo y que requieren mucha planeación como lo son: políticas de calidad de servicio (QoS), habilitación de multicast, etc.
  2. Segura
    • Qué significa que todo componentes o elementos que formen parte de la arquitectura en tecnología, debe contar con los mínimos mecanismos de seguridad definidos como suficientes para la organización, en sus versiones o propuestas más recientes. 
    • Una política integral de seguridad de la información en toda la organización, también forma parte de este atributo.
  3. Amplio acceso
    • Los componentes pertenecientes a la capa de componentes habilitadores del servicio o servicios de soporte, deben poder accesarse y ser utilizados desde múltiples medios de acceso y múltiples dispositivos (ubicuidad), por los servicios de usuario que soporta.
  4. Flexible
    • Parece un tanto obvio, pero es más común de lo pudiesen pensar, que se tiene operando una nueva solución tecnológica y cuando se revisa la siguiente fase a llevar a cabo, nos damos cuenta que las nuevas soluciones requieren cambiar o modificar las soluciones de fases previas y prácticamente desecharlos antes de su fin de vida útil.
    • Las incompatibilidades entran también aquí, cuidar que las soluciones tecnológicas a considerar, no tengan una fuerte dependencia de soluciones o funciones propietarias que haga tan compleja su adaptación a nuevas soluciones o componentes, que sea preferible reemplazarlas.
    • En general se debe cuidar poder acoplar la arquitectura tecnológica a nuevas soluciones y servicios de fases posteriores teniendo en mente el periodo de vida útil que se trazo desde el principio y con ello evitar sacar de operación las soluciones antes de ello.
  5. Escalable
    • Incremento de capacidades sin costos excesivos o estrategias fuera de mejores prácticas. ¿A qué me refiero?, como en el caso anterior, se debe tener en cuenta desde el principio que al llevar a cabo ampliaciones futuras de los componentes de la arquitectura, esto se debe llevar de manera transparente (como un todo y no generar silos) y homogenea, evitando parches al tratar de "reasignar" equipos a otra parte por no tener forma de integrarse a los nuevos componentes.
    • Ejemplos de una solución no escalable son: la amplicación de memoria en componentes, donde se requiere tirar a la basura las memorias actuales por no ser compatibles en configuración con las nuevas capacidades requeridas, el no poder apilar switches LAN por no haberse considerado soluciones de este tipo desde el principio y recurrir a malas prácticas como el "cascadeo" de equipos a través de puertos genéricos ethernet, recursos de multipunto de video separados y no integrados en un solo dominio de recursos, etc.
  6. Modular
    • La arquitectura tecnológica, debe diseñarse en módulos que ayuden a deliminar fronteras de funcionamiento y responsabilidad por los dueños de cada uno de ellos.
  7. Robusta 
    • Componentes redundantes deben de ser considerados en cada capa, solución y componentes de la arquitectura tecnológica que así lo permita y con la finalidad en última instancia de alinear esta redundancia al nivel de servicio esperado (SLA, Servive Level Agreement).
  8. Confiable
    • Se debe esperar que la arquitectura en tecnología, cuente con la confiabilidad en al menos 2 sentidos: el primero, tener el nivel de disponibilidad esperado (SLA) y segundo, ante una caída del servicio, contar con el menor tiempo de indisponibilidad posible a través de la habilitación de mecanismos avanzados de recuperación.
  9. Bajo demanda
    • La arquitectura en tecnología debe estar preparada para estar disponible en sus componentes y servicios que otorga al usuario final, solo en los momentos que sea requerido por la organización. Para ello, deben ser explorados esquemas de contratación de TI en la modalidad "como servicio" y servicios tercerizados u outsourcing.
Hay que tener en mente, un aspecto más que es inherente a los atributos mencionados pero por la misma razón, suele perderse de vista y es un eje rector al definir el cumplimiento a cada atributo:

El horizonte de tiempo, que se planteó como periodo de vida útil de la arquitectura en tecnología y que regularmente es largo plazo.

De manera gráfica lo pueden ver en el siguiente Prezi:


Como siempre, espero y les sea de utilidad!

domingo, 19 de abril de 2015

Un poco de historia hacia la colaboración en la nube

En esta ocasión, si me lo permiten, quisiera hacer un breve viaje al pasado en una de las áreas tecnológicas que más me apasionan y cuyo momento clave fue en la década pasada a raíz de la fuerte evolución que permitio llevar a cabo, me refiero a la evolución del servicio telefónico tradicional en las organizaciones conocido todo el siglo pasado como "telefonía" por la tendencia de "colaboración" liderada en estos momentos por las propuestas de empresas como Microsoft y Cisco.

A lo largo de mi narración, voy a separar los hechos que fueron ocurriendo directamente en la evolución de telefonía, es decir, las innovaciones que surgieron directamente de los foros de tecnología directamente ligados y las empresas que fueron haciéndolos realidad en sus ofertas de productos y servicios; de los factores "ambientales" que fueron ocurriendo en paralelo en México y en el mundo, que jugaron un papel importante en permitir el boom de lo que hoy conocemos como Colaboración.


La decáda de los 90´s y el inicio del nuevo milenio

¿Recuerdan como eran las redes empresariales de voz, datos y video en la gloriosa década del boom de la Internet?, para los que no, teníamos para empezar, grupos de especialistas separados dedicados a cada una de estas tecnologías con presupuestos de TI, independencia, líneas de reporte, medios de comunicación, expertos por marca y demás totalmente separados. Se contaba entonces con sistemas "cerrados" o propietarios de cada fabricante que difícilmente interactuaban con sistemas de marcas diferentes, así que una vez que se hacia una decisión de compra de una solución de determinado fabricante, se tenia que "casar" con ella la organización.

Para las soluciones de video, contabamos con infraestructura de conectividad mediante líneas ISDN (con tasas de trasmisión regularmente de 128 kbps), enlaces frame relay o enlaces dedicados (líneas privadas) para la conectividad de datos (con tasas de transmisión de nx64 kbps, regularmente enlaces entre 64 kbps-512 kbps) y enlaces dedicados de voz con el proveedor de la red telefónica (PSTN, Telmex en México) para la conectividad de larga distancia, entre la red de conmutadores telefónicos (n x troncales digitales E1 con señalización R2). Finalizamos la década, con la tendencia que empezaron a llamar "convergencia", refiriéndose a la convergencia de estos 3 servicios (video, datos y voz) en una única red, la red de datos IP. Iniciaron en México, las primeras implementaciones del transporte de la voz de conmutadores telefónicos, primeramente en redes de frame relay (VoFR, Voz sobre Frame Relay) y posteriormente, en redes "puras" IP (VoIP), mediante el uso de multiplexores TDM y los primeros Gateways de voz disponibles en el mercado por la marca Cisco Systems.

Los factores ambientales en ese momento más relevantes eran los primeros servicios de telefonía celular a finales de la década de los 90´s por operadores en México y el inicio de una masificación del servicio de Internet a usuarios finales, mediante conexiones a través de líneas telefónicas residenciales y modems de baja velocidad (menores a 33 kbps).

Por la parte de datos, contabamos ya, con una oferta de productos en el mercado para empezar a construir las primeras redes inalámbricas o WiFi, soportadas por el estándar IEEE 802.11b, a una tasa de transmisión de 11 Mbps.

Entramos entonces, al nuevo milenio con el desarrollo de propuestas encaminadas a madurar y hacer realidad la convergencia del servicio telefónico y la red de datos (el servicio de video tardó un poco más en converger en la red de datos o IP). Arrancamos, con la propuesta por parte de Cisco Systems ante el IETF, del estándar que se conocería como PoE (Power over Ethernet) y que consistía en la utilización del mismo cableado de datos utilizado en las redes internas o LAN (Local Area Network) de las organizaciones, cableado UTP categoría 5 en ese momento, para poder transportar energía eléctrica DC y energizar al mismo tiempo que se transportaban los datos o información a los dispositivos telefónicos que ahora nacian para ser conectados directamente en los equipos de la red interna o switches LAN, los teléfonos IP. Esto, debido a que ahora el conmutador telefónico tradicional al cual estaban conectados todos los teléfonos analógicos o digitales, evolucionaba a una aplicación instalada en servidores y por tanto, se cambiaba por completo la arquitectura de conexión y alimentación de los dispositivos de la red de telefonía. Por supuesto, hubo una serie de aspectos adicionales que detonó este cambio en la forma de contar ahora con el servicio telefónico, una fue, el incremento de anchos de banda en la red de datos, que ahora eran necesarios por este nuevo tráfico que se encontraría fluyendo por la red WAN y las consecuentes técnicas de calidad de servicio o QoS (Quality of Service) que se desarrollaron para que una aplicación que requería un tratamiento especial y estricto en los paquetes que enviaba (en tiempo real), pudiese tener una experiencia adecuada. Recordemos, que inherentemente el protocolo IP no contaba con mecanismos para diferenciar un tipo de tráfico de otro, dando por hecho inclusive, la posibilidad de re-transmisiones si algunos de los paquetes de datos eran descartados en algún punto de su camino hacia su destino, motivo por el cual se decía que IP tenía con un método de garantía de transmisión de tráfico o paquetes, de mejor esfuerzo o "best effort".

Al mismo tiempo, al inicio de la década de los 2000´s, comienza a desarrollar productos de video la empresa Tandberg, de orígen Noruego. ¿Qué importancia tenía?, bueno, fue la primera empresa exitosa en el desarrollo y lanzamiento de una oferta al mercado de sistemas de video que funcionaban desde el comienzo en la red IP, a través del uso del protocolo conocido como H.323. Esta empresa estaba haciendo en el ámbito de video lo que Cisco en el ámbito de voz, desarrollar productos nativos para su operación de la red IP y lograr con ello el objetivo de convergencia en la red de datos. Esto, evidentemente, tenía la gran ventaja a diferencia de los jugadores de nicho de esa época (Nortel, Avaya y Alcatel principalmente en la parte de telefonía y Polycom como rey absoluto en las soluciones de video basado en redes ISDN o H.320), de no tener que pasar por los largos periodos de re-ingeniería para pasar de sistemas propietarios a sistemas ahora basados en estándares operando en la red IP que a la larga provocó la extinción de muchas de las marcas de telefonía y video del siglo pasado.

Los fabricantes de soluciones inalámbricas, comienzan a lanzar al mercado de manera simultánea, las primeras ofertas de soluciones WiFi basadas en el estándar IEEE 802.11a/g, el cual mejoraba la tasa de transferencia de datos a 54 Mbps.

Cerramos el primer lustro del primer milenio, en el ámbito de evolución de las soluciones de telefonía corporativa, ahora operando en la red de datos y con la ratificación en 2005 por parte de la IETF del estándar 802.3af o PoE. Al mismo tiempo, salen a mercado una serie de aplicaciones nuevas que hacen evolucionar a la telefonia al siguiente paso al cual se le llamo "Comunicaciones Unificadas". 

Como factores ambientales relevantes en este periodo, tuvimos la primera compra de soluciones de TIC en una modalidad de compra totalmente nueva conocida como servicios administrados, en donde a diferencia de lo que se venía haciendo tradicionalmente, donde la operación de las soluciones de tecnología se llevaba a cabo por parte del cliente y la venta e implementación por parte de las empresas o fabricantes que vendían las soluciones, ahora, se entregaba a manos de un tercero completamente la operación y los niveles de servicio ligados de una parte de la TI de un cliente. La institución pionera en México a la que me refiero fue la SHCP (Secretaría de Hacienda y Crédito Público) en 2002, al licitar el contrato de "red privada virtual" que consistia esencialmente en un servicio de conectividad WAN (enlaces) y el transporte del tráfico de voz de los conmutadores telefónicos mediante VoIP (aún no, telefonía IP). ¿Qué impacto tuvo este acontecimiento en el tema de evolución de las soluciones de telefonía?, bueno, la oferta de enlaces por parte de los diferentes proveedores de servicios o carriers en ese momento, era esencialmente, enlaces Frame Relay y enlaces dedicados como herencia de la década anterior. En este concurso, se solicitó una oferta de enlaces WAN, IP por medio del protocolo MPLS, algo totalmente disruptivo que dió origen a una actualización masiva de la oferta de los diferentes carriers en México y a la construcción de múltiples nubes de MPLS, pilar para el buen funcionamiento de la telefonía IP y posterior oferta de comunicaciones unificadas.

Por las mismas fechas, inicio una oferta másiva en México de enlaces de Internet residenciales de alta velocidad con proveedores como ego e Infinitum de Telmex, lo que representó un salto cuántico en las velocidades de Internet por dial-up de unos cuantos kbps a ofertas de alrededor de 1 Mbps.

Al final de este primer lustro de 2005, era una realidad la oferta másiva de los teléfonos con servicio de mensajería instantánea y recepción de correo electrónico de Blackberry (su época dorada). Google en 2005, hace uno de los movimientos en el campo de la movilidad que cambiaría radicalmente el panorama de los dispositivos posteriormente a llamarse "smartphones" al comprar a la empresa desarrolladora del sistema operativo Android para estos dispositivos, y que dejó abierto para su uso público por cualquier fabricante. Hasta ese momento, nadie había sido capaz de lograr una interfaz en los teléfonos móviles o celulares con una experiencia aceptable al usuario, ¿alguno le tocó intentar navegar por Internet en un explorar de Blackberry? la experiencia era desesperante y frustrante!, no se podían llevar a cabo cosas tan sencillas como entrar al portal de correo electrónico a consultar nuestros mensajes (correos personales), ya no digamos la infinidad de páginas Web que no se podían ni desplegar.


En la siguiente imagen, se muestra esta historia de manera gráfica. El fondo, es una foto de la galaxia conocida como M106, que tiene como particularidad que hasta hace apenas un tiempo se pudo detallar de la forma como hoy la tenemos, no se tenía un foto tan completa previamente. Espero que este artículo logre algo parecido en la historia atrás de la colaboración en su adopción en México.



El segundo lustro de los 2000´s

Cuando la telefonía inicio su transformación y ampliación de servicios hacia comunicaciones unificadas, entro en juego un nuevo grupo dentro de la TI que hasta el momento nunca habia tenido traslapes en "telefonía", me refiero al grupo de "sistemas o informática" quienes ahora contaban con elementos clave para que la que la solución integral de comunicaciones unificadas pudiese ser implementada y funcionar conforme a lo esperado: el directorio corporativo (mayormente active directory, AD, como estándar de defacto) y el servicio de correo electrónico (mayormente exchange, igualmente como estándar de defacto). Ambos, piezas clave para que las aplicaciones de comunicaciones unificadas como la integración del correo de voz a los buzones de correo electrónico de los usuarios (llamado por algunos fabricantes como mensajería integrada o unificada), la aplicación de mensajero instantáneo (chat) con presencia (estatus de cada contacto: ocupado, disponible, ausente, etc) y el mismo directorio telefónico a ser mostrado en las pantallas de los teléfonos IP.

Al empezar a proliferar los primeros "smartphones", aunque aún no se les daba este nombre, con la salida al mercado del iPhone, se extendió el alcance de las aplicaciones de mensajero instantáneo con capacidad  de voz y presencia para ahora no solo poder estar instaladas en equipos de cómputo (PCs o laptops), sino que en estos dispositivos móviles. Con ello, sumamos un área más de TI al juego, la gente de "seguridad", ya que la conexión de estas aplicaciones en dispositivos que se encontrarían fuera de la red para su interacción con el resto de dispositivos de comunicaciones unificadas de dentro de la red, requería de conexiones seguras (VPNs, Virtual Private Networks) que eran ámbito de competencia de este grupo de TI.

Empieza a madurar el concepto de comunicaciones unificadas, estableciendo como aplicaciones de esta tendencia o definición, al menos las siguientes:
  • Mensajería integrada o unificada
  • Mensajería instantánea con presencia
  • Softphones (software en la equipos de cómputo para hacer llamadas sin necesidad de un teléfono físico).
  • Soluciones de reuniones virtuales a través de Internet.
Nace por iniciativa de Cisco en 2006, un nuevo concepto en al ámbito de las soluciones de video como evolución a la tradicional videoconferencia en definiciones estándar y los primeros equipos de alta definición que salían al mercado, esta nueva solución de video fue llamada telepresencia y tenía como sus principales diferenciales, una experiencia inmersiva al estar en una sala acondicionada para estos fines en donde el tamaño de las imágenes de los participantes en las sesiones eran de tamaño real, a una muy alta definición que permitia ver detalles de rostros como nunca antes y con un manejo de audio que permitia percibir los sonidos como si estuviesemos cara a cara en una sala real. Esta nueva solución, tenía el foco de contribuir a iniciar el cambio de paradigma de los eternos viajes de los altos ejecutivos para las reuniones de negocios y transformarlos en experiencias virtuales de alto impacto.

Se sumaron a estas soluciones, los fabricantes como Polycom y Tandberg en 2007 y 2008 respectivamente.

En 2008, con un salto en las soluciones de video a experiencias con telepresencia y video en alta definición que se inicio a incorporar en dispositivos ya no únicamente de propósito específico, si no también en dispositivos de uso general como equipos de cómputo, inicia la transformación de las comunicaciones unificadas hacia Colaboración, en donde Colaboración es la integración de las aplicaciones de comunicaciones unificadas, ahora con las soluciones de video que hacia los siguientes años, lograron integrarse de manera exitosa y aprovisionarse en múltiples dispositivos.

En 2009, se ratifica el nuevo estándar para redes inalámbricas WiFi conocido como IEEE 802.11n en donde pasamos a tasas de transferencia de 300 Mbps en comparación a los 54 Mbps de los estándares anteriores.

En 2010 hay 2 grandes noticias, primero, Cisco anuncia la compra del fabricante de soluciones de video Noruego Tandberg con la estrategía de desarrollar soluciones integrales de colaboración. Para entonces, Tandberg ya había tomado el liderazgo en el segmento de video que por años llegó a tener Polycom. 

En este mismo año, se anuncia por Cisco, el lanzamiento de la primera solución de Colaboración a nivel mundial en modalidad de servicio en la nube o Cloud, a través de su plataforma que nombraron HCS (Hosted Collaboration Solution). Con este anuncio, se inició la carrera hacia la transformación de las soluciones tradicionales de Colaboración a ambientes de contratación más flexibles, en demanda y con pago por lo que se consumía únicamente.

Como factores ambientales relevantes en este periodo, iniciamos en 2006 con el lanzamiento de una de las ofertas de servicios de Cloud con más éxito a la fecha, Amazon Web Services. En México, la Secretaría de la Función Pública y el gobierno federal, publican el decreto de austeridad aplicable a todas las dependencias del gobierno federal, en donde se emitían lineamientos claros para la preferencia por contratar servicios administrados de TI en vez de la compra tradicional de infraestructura por parte del gobierno y operación por ellos mismos. Este fue un pilar clave ahora, en la forma en comprar tecnología por el cliente más grande en el país lo que provoco una gran inercia al cambiar para siempre la forma en que las empresas de tecnología tenían que adaptarse a este cambio.

En 2006, fue el año del nacimiento de varias redes sociales, voy a llamarlas de nueva generación que contaron con una gran aceptación y éxito de largo plazo, y que en consecuencia que se integraron como una nueva forma de vida para todos, me refiero a Twitter, Facebook y YouTube.

¿Qué tecnólogo no tiene grabado en su mente 2007? ¿La razón? el anuncio por Steve Jobs del iPhone, ese "teléfono" que cambió radicalmente la forma en como debía ser un dispositivo de este tipo de nueva generación, hundiendo las reglas y modelos en status quo de Blackberry Nokia y cambiando el mapa de competidores a fabricantes como Samsung, LG, Motorola, HTC entre otros.

Estos nuevos dispositivos que podían hacer de una forma casi perfecta muchísimas cosas que antes solo se podían hacer únicamente en equipos de cómputo, permitió dar el banderazo de salida a la movilidad real por el usuario. Se ganaron con ello el nombre de "smartphones".

Llegamos así a finales de la primera década de este milenio y nos encontramos con el lanzamiento de un nuevo segmento de productos tecnológicos enfocados en el usuario común, las tabletas y su producto insignia la iPad de Steve Jobs y Apple. Ese mismo año, en la conferencia conocida como D8, Steve Jobs anunció el inicio de la era "Post PC", muchos cuestionaron esto con el argumento de que solo era publicidad para la recién lanzada iPad, sin embargo el tiempo le dio la razón a Steve y casi todas las empresas de equipos de cómputo terminando vendiendo esas divisiones y la caída de ventas de estos dispositivos del siglo pasado empezó a ser cada vez mayor, en tanto que las ventas de smartphones y tabletas se fueron a las nubes.

La oferta de enlaces para conexiones WAN de los carriers en México empezó a evolucionar del MPLS a enlaces LAN to LAN (L2L) con velocidades de más de 5 Mbps a un costo de una fracción de los enlaces MPLS, por la misma capacidad.


La segunda década del siglo 21

Nos encontramos actualmente en un proceso de transformación a sistemas centralizados nuevamente (la nube) que tiene inherentemente a la virtualización como una tecnología clave para ello. La proliferación de dispositivos móviles, cada vez, con más capacidades de procesamiento, ha hecho inevitable la atención por la organizaciones a este fenómeno.

En 2013, se ratifica un estándar más para redes inalámbricas WiFi (IEEE 802.11ac) que nos permite tener tasas de transferencia cercanas a 1 Gbps y con miras a varias a varios Gbps durante los siguientes años (siguientes "olas" como se les ha llamado). Con esto, se alcanza las velocidades de transmisión que los usuarios corporativos contaban de manera alámbrica a través de Ethernet y todo parece indicar que cada vez más la comunicación será inalámbrica y se dejará de lado en dispositivos de usuario la comunicación a través de Ethernet o cableado físico.

Surgen una serie de nuevas tendencias, como el Internet de las cosas (IoT, Internet of Things), que tiene que ver con el reto de conectar "a la red" todos los dispositivos a los cuales podemos brindarles más inteligencia (semáforos, cámaras de videovigilancia, dispositivos de control en hidroeléctricas, centrales de energía, etc) y el Internet de todo (IoE, Internet of Everything) que tiene como misión conectar todo y a todos. El big data, que es el análisis de los montones de datos de todo tipo que hemos recolectado por décadas, darles orden y sentido y en consecuencia explorarlos inteligentemente para la toma de decisiones, la realidad aumentada, que es el brindar en tiempo real información, datos y experiencia al usuario a través de dispositivos como lentes, pulseras, relojes, etc (wearables o dispositivos que utilicemos como parte de nuestra vestimenta diaria) y la evolución en la forma en como trabajamos aplicando toda esta nueva tecnología y lo más importante, la omnipresencia (literalmente estaremos conectados y trabajando en todo momento desde cualquier lugar, cambiando las reglas de la oficina del siglo pasado o Workspace).

Como factores ambientales de esta última década, la proliferación de los nuevos dispositivos móviles (smartphones y tabletas) dieron inicio a la tendencia de BYOD (Bring Your Own Device, Trae tu propio dispositivo a la organización), lo cual tomó desprevenidos a muchos de los responsables de TI que ahora tenían que controlar mediante políticas el uso dentro de sus instalaciones de estos nuevos aparatos. El Instituto Nacional de Estándares y Tecnología de Estados Unidos (el NIST, National Institute of Standards and Tecnhology), se dio a la tarea de definir los lineamientos en 2011, bajó los cuales toda solución de tecnología en "la nube", podría llamarse así, a raíz de la diversidad de opiniones y variedades de aspectos que los "expertos" comenzaban a matizar al respecto. Hoy, toda solución de nube debe alinearse a estas definiciones para evitar confusiones con soluciones de servicios administrados u Outsourcing.

En 2011, es el año en el cual las ventas de equipos de cómputo personal son superadas por la venta de dispositivos móviles (smartphones y tabletas). Ese mismo año, el iPhone se convirtió en el smartphone más vendido dejando para siempre el liderazgo de las marcas de la década pasada en el olvido.

En Noviembre de 2012, Telcel en México, anuncia su despliegue de la primera red móvil de tecnología de cuarta generación (4G).

Para 2013 (Julio puntualmente), nos encontramos con la intersección de las ventas de teléfonos celulares básicos, siendo igualados por las ventas de smartphones.

El gobierno mexicano, anuncia su muy esperada estrategia digital nacional en Noviembre de 2013, donde marca como objetivos marco, la digitalización del gobierno y como meta, lograr ser el país con mejor índice de digitalización de América Latina de acuerdo al índice (método) establecido por la OCDE para 2018. Dentro de los múltiples lineamientos en términos de tecnología, se da el banderazo de salida para la contratación de soluciones de nube para las instituciones del gobierno federal y la conectividad masiva de sitios a nivel nacional a través de la iniciativa de México Conectado.

La figura siguiente muestra gráficamente lo acontecido la última década.



Una posible conclusión o "efecto mariposa"

Después de este breve recorrido por las últimas 2 décadas de historia tecnológica alrededor de la telefonía, comunicaciones unificadas y ahora Colaboración, podemos aventurarnos a concluir como fue de manera sistémica lo que permite hoy contar con soluciones de movilidad y aplicaciones de nueva generación en las manos de los usuarios de las organizaciones:

  1. El catalizador desde mi perspectiva, fueron los incrementos de ancho de banda en las múltiples redes (WAN, Internet), 
  2. Lo que permitió hacer realidad la convergencia de voz, video y datos en una sola red, la red IP;
  3. Permitiendo adicionar nuevas aplicaciones a la telefonía tradicional como conferencias Web o reuniones remotas y la mensajería instantánea corporativa,
  4. Que hicieron que las múltiples áreas en la TI (redes, telefonía, sistemas, seguridad) comenzarán  el camino hacia la unificación de la red (consolidación de sistemas de management, tarificación, políticas de seguridad, etc),
  5. Y que con la apertura del gobierno a soluciones de servicios administrados a raíz del decreto de austeridad, detonaron este nuevo modelo de consumo o de adquisición de tecnología;
  6. El desarrollo de la tendencia de computación en la nube (Cloud Computing),
  7. Rápidamente llevó al lanzamiento de soluciones de Colaboración en la nube,
  8. Y con la proliferación de múltiples dispositivos en los usuarios,
  9. Smartphones y tabletas,
  10. Contribuyeron a madurar la consolidación de la TI en las organizaciones y con el impulso de las redes sociales, el video y el BYOD; nos permitieron tener todo integrado y orientado en el usuario en un modelo ya disponible de nube.

Gráficamente, se vería así:



¿Alguien sabe que más nos deparara el destino?...




sábado, 11 de abril de 2015

El dilema de eso que significa contar con "alta disponibilidad" en nuestras arquitecturas de tecnología (parte 3 de 3)





Como vimos al final de la parte 2 de estos artículos, ya que el error humano es el que más contribuye a indisponibilidades, se debe contemplar entre otras cosas dentro de los procedimientos internos de la TI:
  • Definir quienes están autorizados a realizar cambios en las configuraciones de los diferentes equipos de la red.
  • Contar con un comité de planeación y revisor de los cambios a aplicar y su viabilidad, asi como su plan de contingencia asociado.
  • Planear los momentos correctos para el cambio de configuraciones buscando que ello afecte lo menos posible a la operación y disponibilidad de los servicios a los usuarios (ventanas de mantenimiento).
  • Mantener una bitácora de quién hizo qué y cuando ayudado por una herramienta para este fin como un servicio de AAA (Tacacs suele ser preferido para esto).

Ahora, las caídas de la red son inevitables, lo que hemos venido viendo es como tratar que sean lo menor posibles y de tiempos muy cortos (MTTR), pero, ¿cómo tener a la mano herramientas o mecanismos que hagan más sencillo y rápido el troubleshooting en estas eventualidades?. Estos son algunos de estos mecanismos que deben tenerse en cuenta como parte integral de la estrategia de una alta disponibilidad de la red:
  • Definir mecanismos de respaldo periódico de configuraciones.
  • Habilitar mecanismos que agilicen la rápida operación de los módulos de control redundantes ante la caída del módulo principal en operación.
  • Habilitar mecanismos que permitan la actualización del sistema operativo de cada equipo en "caliente" o sin sacarlos de operación y mejor aún, que puedan ser solo actualizados los módulos del sistema operativo que se requieran y no todo el sistema. 
  • Habilitar mecanismos de rollback de configuraciones previas (rollback n).
  • Preferir habilitar mecanismos que permitan una más rápida convergencia (ejemplo de ello, habilitar capa 3 en la capa de acceso de la red LAN vs capa 2 que tradicionalmente ha sido el estándar de de facto).

¿Qué otros factores debemos tener en cuenta y que pueden afectar la disponibilidad de la red en su todo? ¿Qué tal las caídas derivadas de aspectos blandos de seguridad? Ejemplo:
  • Por accesar utilizando telnet a los equipos y un ataque del tipo "man in the middle" pueda capturar las credenciales para entrar a los equipos y borrar las configuraciones o simplemente darles shutdown, en vez de utilizar una forma segura de acceso como SSHv2. 
  • O por suplantar la identidad de una PC dentro de la red LAN al generar ataques por la forma de funcionamiento intrínseco del protocolo ARP y no activar mecanismos tales como inspección dinámica de ARP y mecanismos contra IP spoofing.
  • Y que tal un ataque de negación de servicio (DoS) al servicio de DHCP por no tener habilitado DHCP snooping en la red LAN.
  • Y la facilidad de acceso a la red por no tener habilitados mecanismos en la red LAN como seguridad en puerdo basada en direcciones MAC (port security).
  • Y la información no cifrada en la red inalámbrica (WLAN) por seguir usando WEP en vez de WPA2.
  • Y más común, dejar por default el autoregistro de teléfonos IP a la red.
  • O no habilitar el cifrado de llamadas telefónicas para evitar ser capturadas y reproducidas posteriormente.

Podríamos dedicar un libro entero a detallar solo aspectos que vulneran la seguridad desde los múltiples puntos de vista o torres de servicios que están presentes como parte de la TI en las organizaciones e impactan directamente la disponibilidad del servicio, así que dejaremos hasta aquí esos ejemplos.

Finalizare con un reflexión que parecería "obvia" pero la mayoría de las veces no lo es para los múltiples responsables de la TI inmersos en mantener la disponibilidad que el negocio o la organización demanda...

A partir de cuando empieza la medición de la caída o indisponibilidad de la red, ¿cuando el usuario ya no puede accesar a su aplicación o cuando se cae la infraestructura asociada a la aplicación?

Les asombraría a muchos que la principal respuesta que elígen los responsables de la TI es: a partir de la caída de los elementos tecnológicos a su cargo. ¿Qué problema ven al respecto?, primero, no siempre se caen completamente los componentes que soportan una aplicación o servicio al usuario, motivo por el cual para los responsables de la operación de la TI, no existe del todo una indisponibilidad, y a partir de este punto de vista pueden surgir múltiples discusiones de si tienen razón ellos o los usuarios que no entienden nada de tecnología, ¿verdad?, ¿suena familiar?. Segundo, una aplicación o servicio al usuario, comúnmente depende de múltiples componentes habilitadores e infraestructura asociada que forma parte de múltiples áreas de competencia dentro de la TI (redes, sistemas, telefonía, etc) por tanto para garantizar la disponibilidad que se espera de ella, se deben contemplar las múltiples disponibilidades asociadas a cada área ya que son elementos en serie para fines de la matemática a llevar a cabo, y esto es acotado a través del establecimiento de acuerdos de niveles de servicio internos (OLAs como son definidos en ITIL) que la mayoría de las veces no existen o al menos no son tan claros y del conocimiento de todas las áreas de la TI. Por tanto, la indisponibilidad de una aplicación o servicio al usuario inicia y termina a partir de la falla en la experiencia del usuario y su regreso al funcionamiento esperado, no importando el estado de los componentes individuales (componentes habilitadores del servicio e infraestructura asociada).


Hace unos años, Juniper Networks mostró la siguiente gráfica que detalla lo que acabó de comentar, verán claramente un diferencial entre la disponibilidad de la red vs la disponibilidad real en la aplicación al usuario por las razones comentadas anteriormente.




Hasta aquí, todo lo que hemos hablado tiene que ver con únicamente con los aspectos a considerar en el hardware de la red y algunos mecanismos lógicos al respecto, sin embargo hemos obviado que para llevar a cabo el cálculo completo de disponibilidad aún nos falta considerar como componentes en serie, lo siguiente:

  • Software o sistema operativo de los equipos
  • Sistemas de energía (UPS, alimentación eléctrica, etc)
  • Cableado

¿Cómo calcular la respectiva disponibilidad de los componentes anteriores para tener el cálculo completo?, de los sistemas de respaldo de energía (UPS) pudiese llevarse a cabo si el fabricante respectivo proporcionara el MTBF de sus equipos, del resto de componentes es casi imposible obtener una estimación por lo cual son dejados de lado en el cálculo (salvo casos de infraestructura en centros de datos o DC, en donde la disponibilidad esta regida por el nivel de la certificación o Tier que acredite el Uptime Institute a través del estándar TIA-942).



viernes, 10 de abril de 2015

La verdadera razón de ser (misión) de la TI en las organizaciones



En esta ocasión vamos a especular si me lo permiten, con respecto a la misión de las TI en la organizaciones (uso de manera genérica el término TI para referirme a todas las áreas inmersas en ella cualquiera que sea la estructura que tiene cada organización).

Si pudiéramos preguntarnos lo siguiente, que contestarían:

¿Cuál es la verdadera razón de ser (misión) de la TI y que regularmente se pierde de vista?

Si me permiten mi opinión, la respuesta debería ser algo como lo siguiente:

"Dotar de tecnología (hoy día aplicativos) a todos y cada uno de los usuarios del negocio*, cuidando su experiencia en el uso cotidiano de esta"

Si es así, ¿cuál es la razón para orientar las compras de tecnología en términos de las capacidades tecnológicas que nos brinda cada componente independientemente de su naturaleza ó de los protocolos y funciones asociados (features) y dejar de lado que el objetivo son los aplicativos con que dotaremos al usuario para llevar a cabo mejor (mejoría en términos tangibles o intangibles, de disminución del tiempo de actividades, rápida toma de decisiones, etc) su día a día?. Parecería contradictorio o poco claro verdad!. Sigamos...

¿Cuál es la dinámica que existe regularmente al momento de planear y ejecutar proyectos de tecnología?

El camino es algo como esto:
  • Poco conocimiento del plan estratégico de tecnología (si existe) y que debiera ser el rector de cualquier compra de TI.
  • Pensar en la tecnología en términos de ingenieros y no en términos de la aplicativo de negocio a diseñar.
  • Centrar el proyecto en habilitadores del servicio y la infraestructura "cajas" únicamente.
  • Confundir servicios con atributos de arquitectura.

Para ejemplificar el cambio de paradigma entre seguir viendo los proyectos de TI con la óptica de los "ingenieros" responsables de ella y cambiar el enfoque en el usuario y su experiencia, les pondré el siguiente ejemplo que me gusta mucho:

Si les preguntara, ¿cuál creen que es el servicio telefónico más básico que la TI provee en las organizaciones?, ¿qué contestarían?, la respuesta es simple, el servicio de llamadas telefónicas (solo audio). ¿Qué componente de infraestructura lo hace posible?, el conmutador telefónico o PBX-IP hablando de manera genérica y siendo agnósticos a los nombres puntuales que les da cada fabricante a estos dispositivos. Ahora reflexionemos un poco al respecto, el conmutador telefónico tiene una serie de digamos "monerías" o facilidades telefónicas que puede llevar a cabo (conferencias, transferencias, retención de llamada, códigos de autorización, etc), así que siendo estrictos la voz o llamada telefónica es una facilidad no un servicio en sí mismo. Nos encontramos con el hallazgo para este ejemplo, de que la respuesta fue una respuesta de un típico ingeniero responsable de este componente en la organización.

Vamos ahora a cambiar el paradigma un poco y pensar al revés, es decir, en la tecnología o aplicativo a poner en las manos del usuario común dentro de las organizaciones y quién será el consumidor activo de esta propuesta motivo por el cual recordemos, debemos pensar además en una experiencia centrada en él. 

Dedicando un buen tiempo a imaginar como aplicar la tecnología de ese conmutador telefónico y sus facilidades telefónicas y tomando en cuenta los pasos para el diseño de un servicio orientado en el usuario que describí en un artículo por separado, podemos llegar por ejemplo a los siguientes servicios al usuario:
  • Servicio de asesor o experto virtual, que se lleva a cabo mediante la habilitación de una facilidad en el conmutador llamada hunting groups o ACD.
  • Servicio de localización de usuario, a través de un número único de contacto que se lleva a cabo mediante otra facilidad telefónica llamada "número único".
  • Servicio de conferencias telefónicas "on demand", mediante marcación a un número de extensión definida en vez de tener que marcar a uno por uno de los participantes. Esto, llevado a cabo mediante otro facilidad del conmutador llamada "meet me".
  • Servicio de quioscos de información, de audio o audio y video, mediante la aplicación de una facilidad simple de auto-marcación al momento que un usuario levanta el auricular del quiosco o presiona la pantalla del dispositivo táctil, estableciendo una sesión de comunicación con una recepcionista que puede estar en cualquier lugar.
  • Servicio de evacuación y repliegue, a través de la habilitación de otra facilidad del conmutador que es el voceo.

¿Se logra notar la diferencia?, en la propuesta tradicional, se tenia foco únicamente en la tecnología "per se" sin tener presente su aplicación y el beneficio o alineación con el usuario de la organización (cuando sucede esto es común escuchar en las organizaciones frases del tipo "los de TI parecen niños con juguete nuevo" ó "ya llegaron los equipos de los de TI", cuando en realidad no son activos de la gente responsable de TI, es un activo de la organización, sin embargo al no verse el beneficio tangible por parte de los usuarios, para estos, no es claro el objetivo del gasto que se llevó a cabo), en la segunda, se tomó como punto de partida los aplicativos a poner en la mano del usuario (servicios al usuario) para el desarrollo de sus actividades cotidianas (falta claro dar ejemplos de casos de uso para cada uno de los servicios y lo más importante, insertar estos servicios en los procesos de negocio). 

Misma tecnología, inversión idéntica, una diferencia radical en su alcance y éxito posible de una propuesta vs otra.

*El término usuarios del negocio será utilizado en vez de "empleados o colaboradores" de la organización.

lunes, 6 de abril de 2015

¿Y qué sigue después de diseñar servicios enfocados en el usuario?



Una vez habiendo diseñado los servicios de TI enfocándonos en el usuario de negocio a través de los aplicativos a dejar en sus manos para las actividades de día a día, y habiendo con ello, poblado el catálogo de servicios de TI conforme a lo descrito por ITIL, falta aún solventar 2 desafíos adicionales:
1.- insertar estos servicios (o mejor dicho su aplicación a la que llamaré caso de uso*) en el quehacer de las actividades diarias que en su conjunto, dichas actividades, forman parte de los diferentes procesos de negocio con que cuenta cada organización, sean formales o informales y 
2.- llevar a cabo una intensa campaña para comunicar y capacitar a los actores de cada proceso, en la nueva forma de llevar a cabo las actividades impactadas o mejoradas con la tecnología.

¿Cuál es la verdadera importancia de los 2 desafíos anteriores?

La gran mayoría de las implementaciones de proyectos de TI llevadas a cabo después de largos procesos de evaluación y compra son ejecutadas como meta, para llevar a cabo la famosa "instalación, configuración y puesta en operación". Sin embargo, en este punto solo han logrado saber que la infraestructura comprada funciona y tiene por ello sus focos en verde, por lo que hay que caminar mas allá (escalar del campamento base a la cima) y habilitar los servicios enfocados en el usuario que se definieron en la etapa de planeación o diseño de la forma que se conceptualizaron (dispositivos y medios de acceso asociados a cada uno).

Es importante llevar en paralelo a la fase de implementación de la solución, todo el proceso de reingeniería de procesos "insertando" los servicios de acuerdo a los casos de uso que hagan sentido en cada actividad para que una vez estando "corriendo" los servicios enfocados en el usuario, pasemos al último desafío que es la capacitación y adopción tecnológica por parte de todos los involucrados.

Tip
*Para dejar claro el concepto de caso de uso desde la perspectiva en que lo estoy enfocando, tomaré como ejemplo el servicio de reuniones virtuales. Para este servicio, algunos de sus posibles casos de uso serán por ejemplo: reuniones de ventas, reuniones de seguimiento a proyectos, reuniones con proveedores, reuniones con clientes, etc.

Esta última parte es la más importante de todo el proceso y es la más comúnmente olvidada por los responsables de la TI en cada organización.

Sin esta, solo se habrá comprado un "refresh" de infraestructura sin aparente beneficio tangible al usuario del negocio e inevitablemente se caerá en las interminables discusiones de las facilidades, funciones o features que cada usuario percibe pérdidas de lo viejo vs lo nuevo (conversaciones por cierto sin sentido).

¿Suena familiar?, los invitó a mirar más como meta de un proyecto de TI la cima de la montaña y no solo el arribo al campamento base para tomar las fotos de evidencia de que estuvieron en ese lugar.


Una propuesta "inversa" al momento de incubar proyectos de TI

A lo largo de mi experiencia con los clientes en el desarrollo de proyectos de TI, inumerables ocasiones (o casi todas ellas), se hace un desarrollo "tradicional" de estos proyectos pensando en la infraestructura que se requerirá (switches LAN, ruteadores, access points, IP PBX, equipos de videoconferencia, teléfonos, etc).

Se revisa aunque no en todos los casos y es importante hacerlo, lo que llamo servicios de soporte o componentes habilitadores del servicio, que es todo aquello que "proporciona la red" para que las soluciones de TI puedan ser implementadas en todo su explendor (servicio de DHCP, NTP, syslog, virtualización, management, respaldo de energía, entre otros muchos).

Entramos entonces, en las dinámicas también tradicionales de citar a proveedores o fabricantes para que muestren los nuevos equipos o soluciones que tienen para considerarlas en el proceso de evaluación, se llevan a cabo los famosos cuadros comparativos, se piden propuestas preliminares para establecer el costo probable de inversión, ajustamos el proyecto alrededor de ello, hasta llegar a un formal RFI o estudio de mercado con su siguiente RFP o publicación del concurso en forma, muchas veces, con un anexo del tipo "lista de súper" en donde se da santo y seña de los modelos, marca y cantidades de equipos requeridos (hardware, software y licencias).

Esta dinámica de trabajo, tiene al menos 2 inconvenientes:
1.- Primero, provoca el desarrollo del proyecto de TI de inicio a fin con una óptica puramente de ingeniería y se deja de lado el principal objetivo de la TI "proveer de tecnología o aplicativos a los usuarios de la organización (negocio)". Este enfoque lo llamo la estructura de pirámide tradicional y en donde el usuario queda en último lugar, el resultado es regularmente un simple "refresh" en donde pocas aplicaciones nuevas acaban en las manos de los usuarios.



2.- Segundo, los pocos servicios o aplicativos que llegan al usuario, comúnmente llegan a quedar "amorfos". Me refiero con el término "amorfo" a que el mismo servicio no puede convivir o comunicarse por caer en silos de TI diferentes (el servicio de comunicación llamemosle audiovisual, de la sala de videoconferencia no puede comunicarse por ejemplo con los dispositivos con este mismo servicio que estan registrados en el PBX IP, increíble! el mismo servicio y no tiene transparencia en su funcionamiento).

¿Cómo solventar entonces estos desafíos?

Qué les parecería invertir la pirámide anterior y pensar primero en los servicios a habilitar en los usuarios del negocio (aplicativos), después en los componentes de la red para hacerlos realidad de manera integral y solo despúes, poner atención en la infraestructura que se requerirá para llevar a cabo estos servicios. La propuesta quedaría así:




Tip
Recordemos que la palabra "servicio" la ocupo para describir la tecnología (aplicativos) a poner en las manos del usuario (aspecto funcional) y no para referirme al esquema comercial de adquisición de la tecnología (servicio de outsourcing).

Al realizar el mapeo utilizando la propuesta de pirámide inversa, garantizamos tener en mente la eliminación de los silos tradicionales en las diferentes áreas de la TI (y su proceso de unificación o convergencia), entregar servicios al usuario de negocio que serán parte del impacto en los procesos de negocio en última instancia y evitar las "amorfidades" tradicionales del servicio.

¿Le encuentran el valor?.




Los 5 pasos para el diseño de servicios enfocados en el usuario



A lo largo de mucho tiempo, he notado que en el ámbito de TI la palabra "servicio" se encuentra inmersa en una serie de descripciones confusas y que significan distintas cosas de acuerdo a quién se pregunte. 
El diseño de servicios para la TI llamado por ITIL "catalogo de servicios" se encuentra contemplado en las primeras dos fases de este marco de referencia de los más utilizados (fases de estrategia del servicio y diseño del servicio). Sin embargo, a pesar de su estructura y amplio uso de ITIL, se pierde de vista fácilmente que el servicio debe encontrarse siempre enfocado en aquella tecnología (o aplicativos hoy día) que cada responsable de la TI en las organizaciones va a dotar a cada usuario del negocio (los llamo así a todos y cada uno de los colaboradores dentro de las organizaciones), para llevar a cabo de una mejor manera, las actividades de día a día.

Si partimos entonces de la idea de diseñar servicios de TI enfocados en el usuario que serán los que formen parte del catálogo de servicios, los siguientes pasos pueden ayudar a ser exitosos en el camino:
Paso 1.- Bautizar al servicio con un nombre "artístico", es decir, debe ser un nombre que tenga relación más con la actividad o función que llega a resolver que con el nombre de la tecnología que lo hace posible (solución específica de algun fabricante o algun "feature"). Ejemplo de ello, utilizar "servicio de reuniones virtuales" como nombre del servicio de TI en vez de "servicio de go to meeting".
Paso 2.- Definir los dispositivos en que se podrá acceder o desde donde estará disponible este servicio. Hoy día pensar como en el siglo pasado en que un servicio de TI esta ligado a un dispositivo específico o inmutable es algo irreal para nuestro contentexto actual en donde proliferan dispositivos móviles como smartphones, tabletas, laptops, etc. adicionalmente a los dispositivos tradicionales especiaizados (teléfonos IP, videoteléfonos, etc).
Paso 3.- Definir los medios de acceso desde los cuales se podrá llevar a cabo la conectividad necesaria para accesar al servicio desde los dispositivos definidos en el paso 2. Esto es, la red WiFi, la red cableada o LAN, la red móvil 4G/LTE, etc.
Paso 4.- Definir el alcance del servicio (lo que se podrá llevar a cabo con este y su interrelación con los componentes habilitadores del servicio*). Lo más claro y conciso posible este paso.
Paso 5.- Dar ideas de los casos de uso (aplicaciones en actividades de día a día del servicio desarrollado) en que cada usuario puede utilizar el servicio.

Tip
*Un componente habilitador del servicio o servicio de soporte, son todas aquellas funciones proporcionadas por la red para hacer posible el funcionamiento que cada servicio enfocado en el usuario (o simplemente servicio al usuario) requiere.

Hasta ahora lo único que hemos hecho es diseñar uno de los servicios que formarán parte del catalogo de servicios de la TI. Al llevar a cabo "n" iteracciones, lograremos ir poblando el catalogo de servicios de TI de nuestra organización.

Recordemos, que una vez definido cada servicio, debemos llevar a cabo un proceso de definición de los componentes habilitadores y la infraestructura asociada (marca y modelo específico) de plataformas que necesitaremos para que el servicio enfocado en el usuario sea realidad.

Bajo este enfoque no perdamos de vista que los componentes habilitadores y la infraestructura asociada a cada servicio, pueden ser adquiridos de la forma que más convenga a la organización (como servicio administrado, arrendamiento, financiamiento, servicio en la nube o como compra tradicional de activos).