Un repaso a Microsoft Dynamics 365 con Renato Bellu

'Microsoft Dynamics 365 for dummies' es, simplemente, y como cabe esperar, una descripción del producto Dynamics 365 sin ningún tipo de pretensión ni literaria ni de originalidad. Eso sí, y a diferencia de otros libros de la serie 'for dummies', en este caso, la descripción es algo menos didáctica y mucho más exhaustiva. Perjudica, creo, en parte a la obra, el hecho de que el propio producto, más bien familia de productos, recogidos en Dynamics 365 es en sí mismo complejo y, sobre todo, confuso. Una confusión que nace del hecho de que Dynamics 365 es una marca que recoge productos de diferente procedencia que Microsoft está intentando unificar y armonizar pero que, en este momento, están lejos de ser un producto realmente único, con una arquitectura técnica y, sobre todo, una visión funcional claramente delimitadas. Hay que decir, que el autor nos explica desde el principio, y de forma bastante detallada, cómo es esta compleja historia y mapa de productos con lo que, al menos, el lector va advertido.

El contenido se recoge en diecisiete capítulos agrupados en cinco partes, como sigue:

• 'PART 1: DOING GREAT THINGS WITH MICROSOFT DYNAMICS 365:' En esta parte se nos explica, más que el producto en sí mismo, algunos elementos de contexto: el mapa de productos que componen Dynamics 365 y formas de extender y complementar su pontencia con elementos de integración con otros productos de Office 365, con PowerBI para reporting, con PowerApps para desarrollo y con Flow para hacer Workflows. 
  
  
  • 'Chapter 1: Foating on a Secure Cloud': Explica las ventajas del modelo cloud y, sobre todo, intenta dejar claro el complejo mapa de productos de Microsoft en el campo del ERP y el CRM, su evolución y dónde está Dynamics 365. También comenta algunos aspectos específicos sobre migración de versiones antiguas a la nueva.
  
  
  • 'Chapter 2: Extending Ypur Reach with Microsoft Dynamics 365': Explica algunos aspectos de la administración del producto: usuarios, suscripciones, contraseñas, etc así como la integración con el correo Outlook, con Excel, mediante un Add-in o con SharePoint, OneDrive o Skype
  
  
  • 'Chapter 3: Powering Up Your Business Intelligence': Nos habla de PowerBI, la herramienta de reporting y nos cuenta su historia, cómo instalarlo, cómo conectarlo con los diferentes módulos y cómo empotrar 'dashboards' hechos con PowerBI dentro de Dynamics 365.
  
  
  • 'Chapter 4: Extending Dynamics 365 with PowerApps': Se centra en PowerApps, la herramienta de desarrollo simplificado de aplicaciones móviles y web. Nos habla de cómo configurarlo y cómo conectarlo con Dynamics 365
  
  
  • 'Chapter 5: Going with the Microsoft Flow to Enhance Dynamics 365': Nos habla de Microsfot Flow, la herramienta para hacer workflows sencillos. Nos explica la relación de los workflows con la gestión documental y, en cuanto al producto en sí, cómo configurarlo y su uso en el ámbito de CRM y ERP.


• 'PART 2: CUSTOMER ENGAMEMENT (FORMERLY DYNAMICS CRM ONLINE):' Esta segunda parte se centra en la parte CRM de Dynamics 365. 
  
  
  • 'Chapter 6: Turning Relationships into Revenue with Sales': comienza introduciendo algunos conceptos sobre CRM para luego explicarnos el uso del producto en aspectos como la gestión de leads, cuentas y contactos, el seguimiento de oportunidades, así como la creación de ofertas, pedidos y facturas
  
  
  • 'Chapter 7: Connecting with Customer Anytime, Anywhere with Customer Service': Se centra en los aspectos de servicio al cliente. Nos presenta conceptos como los de casos, actividades, notas, tareas, colas o vistas y nos explica cómo trabajar con casos. También nos recuerda cómo incluir dashboards de servicio al cliente.
  
  
  • 'Chapter 8: Profiting from Project Service Automation': Nos explica que, en la visión de Microsoft hay dos enfoques para la gestión de la operación por proyectos que en el caso de Dynamics 365 se encuentra en el bloque de CRM. En este, en mi opinión, bastante incorrecto uso del término proyecto, lo que recoge son formas de entregar producto o servicio fuera del ámbito de la distribución comercial. En éste capítulo, en concreto, se centra en las funcionalidades orientadas a negocios de servicios profesionales.
  
  
  • 'Chapter 9: Creating and Nurturing Leads with Marketing': Se enfoca ahora más a los aspectos de marketing. Nos habla de segmentación y listas de clientes, de cómo recoger la voz del cliente y del uso de 'dashboards' para marketing.
  
  
  • 'Chapter 10: Going Mobile with Field Service': Es la segunda opción de esa mal nominada gestión de proyectos y que, en este caso, se refiere a la gestión de fuerzas de campo y del acceso a Dynamcs 365 mediante móvil para esas fuerzas de campo. Tras algunas consideraciones previas nos muestra cómo es la gestión del ciclo de vida de una orden de trabajo así como algunos aspectos de administración.


• 'PART 3: BUSINESS CENTRAL ERP (FORMERLY DYNAMICS NAV):' Nos explica la primera opción en el campo de ERP que sería Business Central, evolución de Navision 
  
  
  • 'Chapter 11: Accounting for Your Business with Business Central': Primero nos explica a vista de pájaro el producto Business Central y su uso y luego nos habla de temas como la gestión de cuentas, la entrada de ofertas, la creación de facturas, créditos o memorias y la gestión de la información de clientes y fabricantes.
  
  
  • 'Chapter 12: Setting Up Business Central for Optimal Results': Explica una larga serie de posibilidades en cuanto a la configuración y adaptación del producto


• 'PART 4: FINANCE AND OPERATIONS (FORMERLY DYNAMICS AX):' Aborda en este caso la segunda opción en cuanto a ERP, el producto procedente de AX y centrado en los aspectos financieros. 
  
  
  • 'Chapter 13: Going Beyond Crunching Numbers with Financial Management': Vuelve a recordar la historia y evolución de los productos de Microsoft que se integran en Dynamics 365 y nos proporciona una visión de alto nivel de la funcionalidad de Finanzas y algunos aspectos de configuración.
  
  
  • 'Chapter 14: Becoming a Smooth Operator with Operations': Presenta ahora, pero sin apenas profundizar, las funcionalidades de Operación con aspectos como la gestión de catálogo o inventario pero dedica casi más espacio a hablar de temas más genéricos del módulo como el manejo de opciones, hojas excel, etc
  
  
  • 'Chapter 15: Looking Under the Hood (understanding the D365O Technology': Habla de algunos aspectos más técnicos e internos el producto en aspectos como la integración, la personalización de la interfaz de usuario etc. Y, de forma muy breve y quizá no muy estructurada, incluye también en este capítulo la parte funcional relacionada con gestión de recursos humanos


• 'PART 5: THE PART OF TENS:' Una suerte de resumen de aspectos a destacar
  
  
  • 'Chapter 16: The Ten Most Exciting Capabilities if Dynamics 365': enuncia lo que considera las diez mejores características de Dynamics 365
  
  
  • 'Chapter 17: Ten Dynamics 365 Myths to Dispel': Cierra con lo que considera son diez mitos a desterrar sobre Dynamocs 365.

'Microsoft Dynamics 365 for dummies' permite hacerse una idea bastante aproximada de las capacidades funcionales de Dynamics 365. Creo que se encuentra mejor descrita la parte relacionada con CRM (parte 2) que la relativa a ERP (partes 3 y 4) pero si lo que se pretende es saber qué cabe esperar a del producto puede ser suficiente (e incluso prolijo) aunque, evidentemente, para un desarrollo, una implantación o un uso en el día a día se precisa algo más de información.

Un libro, en fin, informativo y trabajado, pero sin alharacas ni aportaciones especialmente originales, cosas que no cabe esperar, por otro lado.

Renato Bellu

(Fuente: Traducción y ligera elaboración del perfil en perfil en LinkedIn Learning)

Renato Bellu

Renato Bellu, el autor de 'Microsoft Dynamics GP for Dummies' es uno de los más importantes expertos en implementación de ERP. Renato comenzó su andadura con Dynamics GP en una de las 'Big Four', PricewaterhouseCoopers,y a partir de ahí continuó siendo el líder de pensamiento para la división Avanade de Accenture.

Los diseños de Bellu han recibido el premio Microsoft Pinnacle Award en la Convergence 2005 conference, cuando Bill Gates fue speaker inagural. A partir de ahí, Renato continuo diseñando sistemas ERP y ECM para entidades famosas y para una de las grandes ciudades de Estados Unidos. Además, está especializado en Dynamics GP, Dynamics AX, Unit4 Business World (Agresso) y Hyland OnBase WorkView/Case Manager, que es una solución de Enterprise Content Management (ECM)

Renato es a la vez un experto funcional en aplicaciones y un programador avanzado en SQL y .Net que desarrolla modificaciones de pantallas, portales de reporting de business intelligence, utilidades de conversión de datos y programas de integración automatizada (interfaces de datos).

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

TITULO: Microsoft Dynamics 365 for dummies

AUTOR: Renato Bellu.

EDITORIAL: Wiley

AÑO: 2018

ISBN: 978-1-119-50888
PAGINAS: 384

Artículos de este blog relacionados

• El software ancla e ideas para superarlo
• La 'dieta' de los clientes potenciales
• Suites software y las digestiones pesadas

DevOps versus Bimodal IT

Hace un tiempo, reflexionaba yo sobre la viabilidad de aplicar metodologías Agile de forma generalizada en una empresa compleja con un mapa de sistemas complejo.

Y mi sensación, que en el fondo todavía mantengo, es que la aplicabilidad de Agile no es el todo general, que los proyectos más complejos precisan algo más de planificación y visión a largo plazo, y un ciclo de vida que, al menos al principio, no se adapta a la velocidad y metodología de Agile. Pensaba yo que ciertos proyectos deben seguir una gestión de proyectos más tradicional (en general los más complejos y los que más determinan la arquitectura y mapa de sistemas) y otros, sin embargo, se beneficiaría de un enfoque agile (aquellos de planteamientos funcionales más sencillos, con mayor orientación hacia el cliente y con más peso en los aspectos de interfaz de usuario).

Y en eso descubrí el concepto de Bimodal IT, creado por Gartner y que se parecía mucho a lo que yo había pensado. Bimodal IT distingue, en efecto, dos tipos de proyectos y dos formas de gestionarlos. 

Los sistemas que se denominan 'sistemas de registro ('record systems'), es decir, los que soportan la columna vertebral de los procesos y datos corporativos, se gestionarían en el modo 1 según el modelo en cascada más tradicional y buscando sobre todo la fiabilidad. 

Los sistemas que denominan de relación ('engagement system'), los dedicados a interaccionar con el cliente y crear un vínculo con él, se gestionarían en el modo 2, que sería 'agile' y donde lo que primaría sería la velocidad y capacidad de respuesta.

Me encuentro ahora leyendo 'The DevOps Handbook' para profundizar en DevOps que, como ya vimos, es heredero de, aunque no se limita a, la filosofía agile. Y veo que uno de sus autores, Jez Humble, hace poco más de un año dedicó en su blog, 'Continuous Delivery', un post en que criticaba esa filosofía promovida por Gartner.

Tres son los argumentos que esgrime Jez Humble en contra de Bimodal IT

• Reduccionismo: Opina Humble que es una simplificación el pensar que con esos dos modos se resuelve toda la problemática.


• Acoplamiento entre los sistemas de registro y los de interacción: Afirma en este sentido Humble que la modificación de un sistema de relación (modo 2) suele precisar de modificaciones en los sistemas de registro (modo 1), por lo que no es correcta una separación drástica entre ambos tipos de sistemas y entre ambos modos.


• La fiabilidad no está reñida con la velocidad: Aquí, Humble va más allá y, por decirlo de alguna manera, 'niega la mayor': no es cierto que la fiabilidad esté reñida con el tiempo de respuesta. Jez Humble entiende que DevOps da respuesta a ambas necesidades y, por tanto, no es necesaria la famosa gestión bimodal.

Jez Humble en acción

Finaliza Humble su artículo en un tono algo más conciliador y entreve que, quizá, la gestión bimodal sea útil como un primer paso, en el caso de empresas con una gestión muy tradicional, para acercarse a DevOps. Un primer paso que en opinión de Humble no puede exceder de unos meses.

Un debate, en cualquier caso, muy interesante y más que necesario y realista. Mi experiencia me lleva a estar más cerca del modelo de Gartner... y mi esperanza a estar más cerca de Jez Humble y DevOps.

¿Conclusión?

Supongo que no hay otra: debemos aspirar al modelo DevOps, pero ser muy realistas y cuidadosos en la transición... y ser muy conscientes de la realidad (la realidad, no la aspiración) de nuestras compañías. Quizá no estemos tan cerca de un DevOps o un Agile como quisiéramos...

Tres interesantes patrones de gestión de sistemas

A aquellos que estén familiarizados con el diseño software, especialmente el diseño orientado a objetos, les resultará seguramente familiar el término 'patrones de diseño'. Un patrón de diseño es algo así como un diseño genérico, un modelo de diseño repetitivo. una buena solución 'ya enlatada' para un problema común de diseño software.

Los patrones de diseño se hicieron populares (y tremendamente útiles) a partir del afamado libro 'Design Patterns. Elements of Reusable Object-Oriented Software' de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El libro, debo decirlo, con el que creo que más aprendí de diseño orientado a objetos en su momento (un momento algo lejano ya).

Pero los patrones no tiene por qué limitarse a diseño de software orientados a objetos. Siempre que existan unas problemáticas frecuentes y similares en cualquier ámbito, y siempre que identifiquemos un tipo de solución válida para ese tipo de problemáticas, nos encontraremos ante un patrón.

Leyendo 'The DevOps Handbook' me encuentro con esta misma palabra, patrón ('pattern'), pero en un ámbito diferente, aunque todavía dentro del mundo del software. Se trata de tres patrones que tienen que ver más con la arquitectura y explotación de sistemas que con la ingeniería del software.

En el caso de los dos primeros patrones, el problema a resolver es cómo conseguir un despliegue frecuente (idealmente continuo) de nuevo software en producción con un riesgo tolerable. Para este problema, se nos proponen dos patrones: 'feature toggles' y 'dark launching' que, por cierto, pueden ser complementarios.

'Feature toggles' (conmutadores de características) consiste en dotar al sistema de unos elementos de configuración (por ejemplo vía fichero XML o JSON) que permitan realizar activación/desactivación o la apertura de las nuevas funcionalidades de forma controlada. Por ejemplo, se puede controlar a qué usuarios se les permite o no el acceso a la funcionalidad reciente, implementando políticas de número crecientes de usuarios como podría ser: al principio sólo el equipo de desarrollo, luego los usuarios de la compañía proveedora del servicio, luego un número limitado de clientes y, finalmente, toda la planta de clientes. También se puede utilizar para desactivar completamente una funcionalidad que se ha mostrado defectuosa o no escalable.

'Dark launching' (lanzamiento opaco) habla de desplegar en entorno de producción software y funcionalidad pero de modo que no son visibles para los usuarios finales, ya sea porque está desactivadas para ellos, ya sea porque no producen ninguna manifestación visible sino sólo trabajo en 'background' (por ejemplo, medidas y obtención de KPIs). En la sombra, el equipo de proveedor del servicio puede trabajar comprobando el funcionamiento correcto y las prestaciones y escalabilidad, antes de decidirse a desplegar 'en abierto'. Este patrón pude apoyarse en el de 'feature toggles' ya que pueden ser esos conmutadores de características lo que nos sirva para mantener la nueva funcionalidad como 'opaca'. 

El tercer patrón cambia de tercio y se centra ahora más en una solución de arquitectura para permitir desplegar una nueva tecnología conviviendo con otra legacy.

'Strangler application' (estrangulador de aplicaciones') lo que propone es, simplemente, recubrir el 'legacy con un API, de forma que se concentre ahí toda la interacción entre la nueva tecnología o aplicación y la legada. De esta forma, se reduce drásticamente el acoplamiento entre ambas y se habilita una relativamente sencilla eliminación de la aplicación legada, si así lo decidimos, mediante una nueva implementación del API que recubría al legado. La re-implementación de esa API puede incluso, ser gradual, resultando en cualquier caso trasparente el ritmo de sustitución para la nueva tecnología o aplicación.

Probablemente, aquellos lectores duchos en ingeniería software y con experiencia real con sistemas reconozcan estos patrones, incluso aunque puedan no haber oído nunca el nombre que se les aplica. En mi caso particular, puedo decir que, en efecto, he conocido las tres estrategias en la práctica, aunque hasta ahora no las había catalogado como patrón ni conocía el nombre que las denomina.

Es lo que tienen los patrones: son soluciones comunes, y muchos profesionales probablemente han llegado a y aplicado las mismas conclusiones, incluso sin saber que otros colegas hacían lo mismo en otras compañías o proyectos.

El identificarlos como patrones hacen más fácil, sin embargo, entenderlos, comunicarlos  e identificarlos la próxima vez.

Y con ese espíritu, y por lo que pueda ayudar, he escrito este post.

Deuda técnica

La deuda no es mala por sí misma.

Endeudarse es una forma de obtener recursos y con base en ellos impulsar nuestro negocio o nuestra vida. Mediante la deuda podemos afrontar iniciativas que, tal vez sin ella, fuesen imposibles. Nos endeudamos como personas, 'nos hipotecamos', para comprar una casa que difícilmente podríamos pagar al contado, o para permitirnos unos estudios o quizá un coche. Nos endeudamos como empresa para invertir en proyectos de futuro: una expansión internacional, una nueva línea de productos, una nueva tecnología productiva, unas nuevas infraestructuras...

La deuda proporciona lo que se denomina el apalancamiento financiero, y la palabra apalancamiento nos sugiere impulso, potenciación de capacidades. Y es así, sin el capital que se nos aporta al contraer una deuda, no podríamos imaginar llevar a cabo ciertos proyectos.

No. La deuda no es mala en sí misma. No es mala siempre que se gestione responsablemente, siempre que se mantenga en límites asumibles, siempre que seamos capaces de saldarla, siempre que la controlemos y no seamos controlados por ella.

Pero no sólo existe deuda financiera.

En el ámbito de las tecnologías de la información, Ward Cunningham acuñó el término deuda técnica, algo así como problemas latentes que creamos por decisiones erróneas o cortoplacistas y que, poco a poco comprometen la evolución de nuestra TI.

Esta es su explicación según es citada en 'The DevOps Handbook' de Gene Kim, Jez Humble, Patrick Debois y John Willis:

technical debt describes how decissions we make lead to problems that get increasingly more difficult to fix over time, continually reducing our available options in the future- even when taken on judiciously, we still incur interest.

¿Tampoco es mala la deuda técnica? ¿La podemos considerar un apalancamiento?

La verdad es que creo que la deuda técnica es fundamentalmente negativa. Suele responder a errores o falta de visión o planificación a medio/largo plazo.

En algunos casos particulares podría considerarse como un apalancamiento: situaciones en que adoptamos una solución no óptima a corto plazo, para tener resultados más rápido. Quizá, por ejemplo, en lugar de renovar sistemas para adaptarse a una nueva tecnología o arquitectura, construimos una capa sobre los existentes que 'simulan' esa adaptación.  El problema es que, rara vez se gestiona la deuda. Rara vez, eliminamos la capa que creamos como solución a corto para realizar la verdadera renovación. Rara vez, en definitiva saldamos la deuda contraída. Muchas veces ni siquiera recordamos haberla contraído. 

Por desgracia, la deuda técnica no suele controlarse sino que aumenta y aumenta... aumenta sin medida hasta que es preciso un 'rescate'.. o una desaparición.

El triángulo imposible del sistema perfecto

Bueno, bonito y barato, reza el ideal de cualquier producto visto desde el lado del consumidor.

Joshua Cooper Ramo, en su libro 'The seventh sense' parece insinuar que hay tres atributos que hacen de un sistema de ordenadores interconectados, el sistema ideal: que sea abierto, que sea rápido y que sea seguro.

Sin embargo, no se hace ilusiones y afirma: 

Systems can be fast, open or secure, but only two of these three at a time.

Es decir, que ese triangulo del sistema perfecto es inalcanzable. No ofrece evidencias de ello, pero sí un razonamiento sencillo. 

Podemos proteger un sistema haciéndolo cerrado. El sistema podría ser además rápido, pero lo que no sería es, evidentemente, abierto.

Si lo abrimos, puede seguir siendo rápido y ya es abierto...pero se generan riesgos de seguridad.

Ahora podemos invertir en seguridad, proteger el sistema, por ejemplo, filtrando y analizando los paquetes que circulan...pero eso ralentiza la ejecución, es decir, el sistema ya no es rápido.

Quizá el razonamiento sea algo simplista, pero concuerda bastante con la intuición, con el hecho conocido de que si se invierte mucho en un atributo, ésto suele ir en detrimento de otro.

Por eso la estrategia es importante, las elecciones son importantes... y el diseño también...

Espagueti de sistemas. Receta para la construcción y la deconstrucción

Espagueti de sistemas... No sé si suena apetitoso... pero en realidad no lo es, no lo es en absoluto. Es la pesadilla (y por desgracia, con frecuencia la realidad) de los departamentos de sistemas de las grandes corporaciones.

Una maraña inmensa de sistemas construidos con diferentes tecnologías, diferentes modelos de información, diferentes tecnologías de integración, diferentes semánticas de datos...pero interconectados entre sí, influyéndose entre sí, solapándose entre sí, limitándose entre sí.. y complicando la vida, a veces hasta extremos insospechados e insoportables, del departamento de sistemas y de los departamentos de negocio a que estos dan soporte.

Es una pesadilla...pero es real, muy real...

Leyendo 'Leading digital' de George Westerman, Didier Bonet y Andrew McAfee encuentro razonamientos y situaciones que me resultan tan familiares que no sé si consolarme con aquello del mal de muchos...

Así se describe en 'Leading digital' el espagueti:

why do so many large companies have poorly designed technology platforms?. Large companies operate in silos each with its own systems, data definitions and business processes. The systems are confusing, sometimes duplicative, and often tied together in complex (and sometimes unknown) ways. Generating a common view of customers or products can be very difficult.

¿Cómo se llega a estos espaguetis de sistemas? ¿Cuál es la desgraciada receta?

En general se produce en organizaciones grandes y con historia más o menos larga. En esa situación, los sistemas surgen (o surgieron en el pasado) para ir dando respuesta a necesidades puntuales de diferentes departamentos. Mientras los sistemas todavía eran una pieza relativamente secundaria, mientras existían pocos sistemas, mientras estos no eran críticos para el negocio, y mientras sólo existían islas de informatización no solapadas, esta situación, sin ser óptima, no era especialmente problemática.

Pero con esa dinámica, el número de sistemas crece. Poco a poco, además, se hacen más críticos para el negocio. Poco a poco toda la actividad  de la empresa se encuentra informatizada... Así que los sistemas ya son muchos, heterogéneos, solapados e interconectados. Es decir: primera aparición del espagueti en el menú... 

Todavía, empero, podría haber sido la situación en ese punto reconducible con un esfuerzo razonable de racionalización y ordenación de demandas. Pero entonces surgen las presiones del negocio, del 'time-to-market', de los resultados, y... la ortodoxia de la arquitectura y mapa de sistemas se rompe irremediablemente...

De nuevo, en 'Leading digital':

Every request for a nonstandard technology, every demand to do things your own way, every choice to go around corporate governance processes so you can move faster, and every integration meeting that your staff people miss will create more complexity. Sometimes that complexity is neccessary, but often it is not.

Como consecuencia de esa presiones de tiempo y de la falta de una adecuada racionalización arquitectural se adoptan presuntas soluciones, construyendo nuevos sistemas encima de los anteriores o de capas que presuntamente ocultan la complejidad de los anteriores...pero sin eliminar ningún sistema ni revisar el mapa de sistemas en su conjunto.

We don't retire systmes. We just add on top of them, which creates a tremendous amount of expense and complexity.

Más sistemas, más intereracciones, más complejidad...El espagueti en todo su esplendor...

¿Y qué hacemos ahora?

Pues ahora tenemos un gran problema y no queda otra que un profundo programa de transformación, de revisión, reordenación, reducción y simplificación del mapa de sistemas.

El trabajo es titánico...pero inevitable. La propia supervivencia de la empresa a medio plazo puede estar en juego si no se acomete.

El trabajo es ciertamente inmenso, pero hay tres ingredientes que nos pueden ayudar en esta deconstrucción, en esta transformación de sistemas.

En primer lugar, la arquitectura empresarial, una herramienta que nos permite ordenar los procesos, la información y las tecnologías con visión global de compañía. En esta arquitectura debe encajarse de manera limpia cualquier solución de futuro.

En segundo lugar, SOA, como tecnología de integración que permite ordenar los servicios de negocio y la información que intercambian esos servicios...servicios e información que, además, deben encajar perfectamente en la arquitectura empresarial.

Y la tercera, liderazgo, mucho liderazgo. Liderazgo intelectual para saber poner orden en el caos y mantener el rigor en la aplicación de la arquitectura empresarial y SOA. Y liderazgo transformador, para construir la visión, comunicarla y movilizar a la organización en pos de su consecución. En cierto modo, la falta de este liderazgo ha permitido en el pasado llegar al espagueti, y ahora ese liderazgo perdido se debe recuperar... 

Spaghetti happens only because leaders let it happen. And removing spaghetti requires strong leadership.

No, el espagueti de sistemas no es apetecible en absoluto. 

Una deconstrucción de sistemas, con guarnición de nuevo mapa de sistemas, cocinada conforme a la receta de la arquitectura empresarial y sazonada con SOA es mucho más apetecible y, para conseguirlo, más que buenos cocineros necesitamos líderes...

Que aproveche...

El privilegio de los sistemas: software y negocio.

A medida que el sector del software ha ido madurando, la profesión de informático, programador o ingeniero software ha perdido mucho de su antiguo prestigio y 'glamour', al menos en España.

En cierto sentido, es una profesión que se ha 'comoditizado', quizá no siempre de forma justa o con buen criterio.

La propia función de IT, aunque cada vez más importante en las empresas, con frecuencia tiene una consideración de secundaria, de apoyo al negocio... y culpable subsidiario de muchos de los problemas de éste.

Sin embargo, el mundo de los sistemas y del software creo que aún conserva algunos elementos que pueden llenar de orgullo y satisfacción a sus profesionales. 

Uno de ellos, al que me quisiera referir en este artículo, es la enorme visión de negocio que se puede adquirir en el mundo de los sistemas, especialmente cuando hablamos de desarrollos a medida y cuando el profesional se mueve en el mundo de los requisitos o del análisis de negocio.

Este tipo de profesionales tiene el enorme privilegio de adquirir una gran visión global del negocio y la operativa de la empresa, la propia empresa si hablamos de un departamento interno, o de los clientes, si se trata de un integrador.

¿Por qué?

Porque para entender el negocio que deben modelar y automatizar se les abren las puertas de los principales protagonistas, se les explica el funcionamiento actual y el deseado, los procesos, los datos que se manejan, los indicadores, los informes e, incluso, si se adquiere confianza con los interlocutores, hasta los 'chascarrillos'. Pero, además, en el ejercicio de su labor, esta elicitación de conocimiento se extiende a vario actores, varios departamentos, varias funcionalidades. De esta forma, el analista, el ingeniero de software, el jefe de proyecto, adquieren un enorme, valiosísimo y casi diría privilegiado entendimiento del funcionamiento del negocio, un conocimiento que con frecuencia supera,  al menos en amplitud y perspectiva, al de los propios usuarios o clientes.

No sé cuántos de los profesionales del sector del software reconocen este hecho, cuántos lo valoran, cuántos lo desarrollan y cuántos están dispuestos a, pasados unos años, aprovecharlo para dar un salto profesional hacia la consultoría, la gestión e incluso la dirección.Pero el privilegio y la oportunidad están ahí...

La labor del profesional del software puede que se haya comoditizado...pero aún guarda tesoros escondidos. Bien harían estos profesionales en ir buscando su propio plano del tesoro.