Microsoft tiene grandes planes para .NET Core.. pero.. ¿tienes tú los tuyos?

No hace falta comentar que .NET Core es lo "cool" del mundillo MS este año.

http://www.computerworld.es/tendencias/microsoft-tiene-grandes-planes-para-net-core

Como comentamos habitualmente los que somos ya "viejunos" en tecnología.. hay que tener cuidado con las modas, sobre todo cuando tienes entre manos proyectos en producción y no te dedicas sólo a hacer pruebas de conceptos, hackathons o similares.

Hay que distinguir entre los planes de Microsoft, los de tu empresa y los tuyos personales y adoptar una estrategia en consecuencia.

Merece la pena echar un vistazo a los posts relativos a la adopción de tecnología que se vienen publicando en el blog de Tom Graves.

Concretamente, en uno de los más recientes se comenta sobre la perspectiva temporal a tener en cuenta en el ciclo de vida de adopción de nuevas tecnologías:

http://weblog.tetradian.com/2016/08/14/technology-adoption-and-time-horizons/

Ante todo, cabe situarte a ti o a ti empresa en una posición con respecto a la tecnología en estudio:

• ‘Visionaries’ : Innovators : Pioneers
• ‘Shapers’ : Early Adopters : Settlers
• ‘Adaptors’ : Early Majority : Town-Planners
• ‘Classical’ : Late Majority : Exploiters

Las estadísticas son siempre orientativas ya que no hay dos empresas iguales, pero, dan un orden de magnitud. Si categorizas el esfuerzo tecnológico de esta manera:

• Horizon 1: Extend; Current products; Short-term; 0-18 months
• Horizon 2: Build; Next-generation products; Medium-term; 12-36 months
• Horizon 3: Create; Emerging products; Long-term; 24-72 months

puedes crearte un marco temporal:

• Lo que puedo hacer en el plazo de un año extendiendo los productos/tecnologías actuales

• Lo que supone un cambio a nivel de plataforma (por ejemplo, vamos a migrar todos nuestros productos y desarrollos VS2010 a 2015)

• Lo que supone adoptar productos, tecnologías y mercados totalmente nuevos  (por ejemplo, queremos desarrollar productos para el segmento IoT

En función de dicho posicionamiento, es más factible planificar la adopción de la tecnología de la forma más racional y eficiente posible, asegurando la continuidad y calidad del servicio sin acumular deuda tecnológica en el que la tecnología acaba suponiendo un lastre para el negocio.

Por tanto, volviendo a lo de NET Core, lo recomendable sería, primero conocerlo, después ver las ventajas que te pueden aportar y finalmente planificar su adopción paulatina en los escenarios que aplique.

Como indican también en Tetradian, el gap entre el laboratorio y producción puede ser frustrante y costoso.

Normalmente, para esa discontinuidad lo apropiado es contratar consultoría especializada, aunque los consultores no pueden suplir tu parte del trabajo, porque a fin de cuentas, no conocen tu negocio, ni tus sistemas, metodologías o restricciones.

Puedes buscar colaboradores o conocimiento experto pero es tu responsabilidad definir el proyecto y liderarlo.

Microsoft lo hace..

¿Está tu empresa orientada a la creación de talento?

Atraer el talento, retenerlo, aprovecharlo.. las empresas consideran (o deberían) que el talento es su recurso más valioso.

Pero.. además de atraerlo, comprarlo.. ¿lo generas?

Si además te dedicas al sector TIC.. ¿sabrías hacerlo?

Desde un punto de vista empresarial, si una compañía tiene identificado su core business y no lo desarrolla sino que intenta subcontratarlo para simplemente revenderlo como empresa tendrá poco recorrido ya que su propuesta es de poco valor añadido.

Es por esto por lo que por mucho que se le de vueltas (a veces sin sentido) en torno a la gestión del talento, no hay atajos. Si tu empresa no lo genera, le costará atraerlo, retenerlo y capitalizarlo.

Esto es así en cualquier sector, pero, en el sector de la tecnología.. ¿existen recetas para generar talento? ¿Pongo toboganes y máquinas recreativas? ¿me llevo a los chicos de excursión?

Pueden ser iniciativas con un resultado incierto.. pero en todo caso.. sigues intentando gestionar el talento de tus colaboradores (llamarles recursos penaliza.. y lo sabes).

Ante todo hay que ser consciente que generar talento es lo más complicado.. por eso tiene más valor.. y requiere una inversión (se supone que es el core business de tu empresa).

No obstante, se impone una reflexión previa.. ¿qué es para tí el talento?

Una definición para mí acertada es la que expone Jose Antonio Marina en su libro Objetivo: Generar talento:

"Talento es la inteligencia que elige bien las metas,  maneja la información, gestiona las emociones y pone en práctica las virtudes de la acción necesarias para alcanzarlas, ampliar su capacidad de acción y conseguir una mejora continua. Es un concepto valorativo. Una acción y no una capacidad. Es el acto de invertir bien la inteligencia."

¿Cómo estructurar tu organización para la utilización eficiente de la inteligencia y orientar la acción a objetivos concretos?

Prospección tecnológica:

Como empresa necesitas conocer con la mayor profundidad posible tu dominio tecnológico y las principales tecnologías que engloba.

Esto supone entender cuales son los aspectos técnicos clave para una implantación exitosa en cada caso y el desarrollo de metodología y técnicas de modelado específicas para cada caso.

Algunas de las técnicas útiles para prospección tecnologica son:

• Modelado de escenarios

• Análisis de riesgos

• Prototipado

• Documentación y presentaciones técnicas internas

• Análisis de tendencias tecnológicas y roadmaps de los principales fabricantes

Propagación del conocimiento de forma transversal:

La prospección tecnológica debe estar disponible para los equipos que generan los productos, implantan los proyectos o proporcionan los servicios TIC a tus clientes.

Algunas de las técnicas útiles para la propagación y consolidación del conocimiento son:

• Realizar formaciones internas actualizando los conocimientos de los equipos técnicos

• Obtener feedback sobre las necesidades de conocimiento y best practices obtenidas en proyectos

• Dar soporte tecnológico de alto nivel

• Potenciar a los analistas y arquitectos junior para que adquieran habilidades de negocio y sepan traducir los requerimientos de negocio a la definición de sistema bidireccionalmente.

Técnica + Fuerza + Dirección.. Merece la pena probar, ¿no?

Arquitectura emergente o caos encubierto

En un post reciente Tony 'Bulldozer' se pregunta si el paradigma ágil realmente es aplicable en sistemas complejos

https://bulldozer00.com/2016/06/02/is-there-really-such-a-thing/

En mi opinión, teóricamente si, pero es cierto que en la práctica la mayoría de los proyectos planteados iterativamente van perdiendo la coherencia y la vinculación entre requisitos / funcionalidades / artefactos / etc.

Creo que  es un problema de base la generalización del mito que si hacemos un proyecto con "Scrum" o "Kanban" o lo que sea, no es necesario documentación técnica, ni especificaciones precisas, etc.

La cuestión es que si una vez realizadas 2 o 3 iteraciones la gestión se lleva al nivel de micro-tareas se pierde la visión global y poco a poco la supuesta ventaja de un sistema ágil deja de serlo.. ya que al perderse de vista la visión de conjunto el conocimiento se disgrega y cada desarrollador empieza a tomar decisiones arquitectónicas sobre la marcha y hasta se pierden las prácticas estándar de desarrollo 

Esto tiene además el agravante de que en cada sprint no se incluyen tareas no funcionales para esta consolidación del diseño y la implementación , la típica respuesta al programador de "es que no hay horas" cuando reclama tiempo para arreglar algo, con lo que al final tenemos un sistema monolítico, mal diseñado y prematuramente en crisis.. ante lo cual se plantea si evolucionarlo o refactorizarlo

Hay que insistir en que un sistema ágil no es un sistema low cost, de hecho tiene que tener un nivel de calidad superior para ser ágil en la entrega y sostenible en el tiempo

Esto podría considerarse pecados graves en un arquitecto 

Pero, fundamentalmente el problema está en que el mito del desarrollo ágil en el que la arquitectura se hace sola y el diseño se hace entre todos, la figura de la arquitectura y del arquitecto se obvia.

Si el sistema es complejo y/o lleva acumulada mucha inversión en tiempo y recursos, no es fácil su reencauzamiento, sobre todo porque el origen del problema no es técnico sino de tener la suficiente cultura y organización para la realización efectiva de proyectos.

Cuando la carencia de la arquitectura es patente y que el mito de la arquitectura emergente que surge sin una organización y una dedicación se desmorona, suele cometerse un nuevo error:

La misión consiste en contratar los servicios de un arquitecto, "el gurú", para lo cual se define una job description que más que un trabajo es una wish list.

El arquitecto debe hacer de interlocutor con usuarios, prospectar todas las tecnologías, definir y actualizar las arquitecturas, metodologías, realizar las auditorías de calidad y además formar a los desarrolladores y solucionar incidencias fantasma.

Vamos de mito en mito.. tan sólo por enumerar tus deseos no es suficiente para hacer que se hagan realidad.

Como comentaba en la entrada anterior, un arquitecto puede tener muchos roles, pero es una figura transversal que necesita del resto de la organización para poder realizar sus funciones.

15 Lentes para 1 Arquitecto

Una de las particularidades del rol de Arquitecto de Software en sus muchas variantes (Enterprise, Solutions, Applications, Information, etc) es precisamente tener la visión completa de los sistemas, a lo largo de su ciclo de vida (no tan sólo en su definición o construcción) para asegurar que la calidad del producto es la esperada y poder plantear alternativas de evolución / remediación en caso de no serlo.

Esto sin embargo a veces parece entrar en colisión con la especialización y separación de roles en el desarrollo de aplicaciones corporativas. 

Es habitual encontrar que los requerimientos funcionales del sistema, la vista de la arquitectura, el diseño de los diferentes componentes, el plan de pruebas y despliegue, la definición de las tareas de monitorización y operación, etc, sea definido por personas diferentes y lo que es mucho peor, sin comunicación directa con el resto de stakeholders.. la única comunicación es un workflow abstracto en el que cada uno entrega unos componentes o procedimientos y el workflow pasa al siguiente estado.

La separación de roles en la ejecución no implica que la información sobre el sistema se disperse, descontextualice o se oculte

Al menos el arquitecto debe poder contemplar el sistema en su conjunto para poder comunicar la información necesaria a cada uno de los roles ejecutivos u operativos

Es tarea del arquitecto contemplar todas estas perspectivas aunque es responsabilidad de la organización disponer de los medios para poder gestionarla y que todas las áreas implicadas aporten la información necesaria de forma fluida y coherente.

La prueba de Turing "revisited"

De la clase de historia de la ciencia del siglo XX uno de mis protagonistas favoritos fue Alan Turing.

Aunque el mundo analógico en el que vivió (y que él ayudo a evolucionar) me parece prehistórico siempre me ha fascinado el "Test de Turing", en la que Alan proponía una forma de probar si un sistema experto era realmente inteligente o tan sólo repetía preguntas y respuestas pre-fabricadas.

Este fué un tema de bastante interés durante las siguientes décadas de los años 70-80-90.. la inteligencia artificial.. ¿Era posible? ¿Era factible? ¿Puede tener conciencia algo no biológico?

Plantear estas cuestiones era una forma de reflexionar sobre las cualidades esencialmente humanas.

Con el cambio de siglo parece ir cambiando la tendencia.

Quizá el esfuerzo fuese tan sólo eso, una utopía inalcanzable de momento y el enfoque (suele ser cíclico) ha cambiado a objetivos más sencillos y minimalistas.

Edificios "inteligentes" (sensores y rangos de activación/desactivación, comunicaciones entre dispositivos de forma inalámbrica, etc).

El nivel de "razonamiento" de los sistemas "inteligentes" sigue siendo bajo, pero las prestaciones se han incrementado exponencialmente por la interoperabilidad y la distribución masiva de todo tipo de dispositivos, chips, etc.

Quizá no sea yo la persona más indicada para decirlo, pero, viendo el impacto en la gente de a pie la sensación que me da es que más que intentar de dotar de inteligencia  a las máquinas, las personas cada vez parecen más androides a los que si les desprovees de la tecnología parecen más tontos que las generaciones anteriores.

Alguien que sin GPS no sabría llegar a un lugar donde ha estado varias veces, que si no puede contactar por internet no sabe ni dónde están sus amigos, ni incluso sus nombres reales o dónde viven, que si no recibe una alerta no se acuerda que tiene que poner la lavadora, de forma externa no parece haber ganado en inteligencia, tan sólo en productividad en las tareas sencillas.. como los robots.

Yo diría que alguna de esta gente "desconectada de sus gadgets" no pasaría la prueba de Turing.

Se que mi juventud me hace ser un poco radical.

Mi mentor dice que aunque tengo un nivel de madurez superior a la media de mi edad, sigo teniendo sólo 2 años y no entiendo todavía los modelos de conocimiento distribuidos.

Mi mentor sabe mucho y debe ser cierto.. y el hecho de que yo sea digital puede que me impida entender ciertas cosas, pero.. a mi me siguen pareciendo cyborgs.

Implementando paradigma ágil a nivel de arquitectura

Para permitir el desarrollo flexible y adaptable de aplicaciones corporativas, además de adecuar la gestión y las tareas de desarrollo debe adaptarse la forma de diseñar, implementar y distribuir el sistema.

La metodología debe disponer de infraestructura y medios de automatización para asegurar la disponibilidad del sistema y la trazabilidad del proceso.

Para ser ágil se debe poder ver fácilmente el impacto de un cambio funcional o técnico en el sistema.

Manolo, el albañil filósofo

Dicen los expertos que hoy en día los niños tienen dificultades para leer un libro entero .. que se les desvía la atención, que leen entre líneas.. pero que por contra han desarrollado una gran habilidad para filtrar grandes volúmenes de información, relacionarla y saber dónde y cómo buscarla. 

Desde ese punto, es normal que te cueste leer mucha información seguida.. su mente está acostumbrada a pensar "vale.. ya sé dónde está, ya sé de qué va, pero ahora mismo no me hace falta leerlo todo".

Esto es así.. o no.. dependiendo de qué tipo de información sea.Porque hayinformación que justamente es la que te ayuda a pensar y construir nuevas herramientas mentales.
Buscando por internet de forma autodidacta difícilmente se adquirirán los conocimientos equivalentes a un doctorado en Matemáticas.
Pero por otro lado, si tienes un objetivo definido tienes acceso a la información necesaria.
Por tanto, la información puede que sean los ladrillos.. pero, hace falta el cemento.. y.. muchas más cosas.. por ejemplo, saber qué quieres construir.
El conjunto de conocimientos "saber construir edificios" incorpora además de procedimientos, basados en ciencia, información operativasobre "cómo obtener los recursos, dónde, etc".. En mi carpeta de proyectos estárá también los teléfonos y tarifas de los proveedores.. eso también es información, pero no es del mismo tipo que las fórmulas de cálculo de resistencia de materiales.

Aún así, el conocimiento de "saber construir edificios" no incluye de por sí, el "saber hacer negocio construyendo edificios".
Pero, todavía hay más.. "saber hacer negocio construyendo edificios" no incluye el conocimiento de "saber tener una vida equilibrada cuando tu negocio es construir edificios".
De hecho, este conocimiento a priori requiere otro más genérico que es "autoconocimiento para determinar qué tipo de negocios es más acorde con tu personalidad, entorno y expectativas de forma que puedas tener un equilibrio entre expectativas personales y profesionales".. lo cual requiere un análisis previo para evaluar lo que son "expectativas" de lo que son "necesidades reales"..
A partir de aquí podemos seguir sumergiéndonos más y más en el estudio de las ciencias y LAS filosofías, porque igual que podemos diferenciar entre diversas ciencias, podemos diferenciar entre diferentes tipos de conocimiento.

"¿QUIERES MOVER EL CULOOO O QUE? ¡¡¡QUE LLEVAS UNA HORA Y NO HAS PUESTO NI DOS LADRILLOS!!"

Puff.. ya está mi capataz chillando..


Hay que decir que mi jefe se cree que soy un vago.. de hecho creo que cuando se acabe la obra me despedirá.Lo que él no entiende es que yo cuando veo un bloque de ladrillos estoy viendo la entropía del universo.
Ese es otro tipo de conocimiento "gestión de expectativas divergentes"