Lanzamiento del nuevo release Plex 7.2

Ayer CA comunicó la disponibilidad del release 7.2 de Plex. Mucho se ha conversado sobre qué incluiría, pero nada es adelantado en el anuncio. Lo que sí es adelantado es algo ya conocido, pero igualmente muy prometedor: la adopción de una política de releases incrementales rápidos, y con participación directa de todos aquellos clientes que deseen sumarse al plan:

The CA Incremental Release Program is a customer-interactive delivery model where new product features are developed and released using the Agile development methodology. CA’s development teams work closely with customers to create product features for rapid implementation. Rather than spending years building a software release full of features, we work with customers and release features incrementally, as they are completed.

El lanzamiento de la versión 7.2 es una confirmación de esta política, acortando todavía más los tiempos de entrega ya vistos entre la versión 7.0 y 7.1.
De la documentación inicial se desprende que el grueso de los cambios se concentran en la variante .NET y en WCF Service Connectors, el agregado de soporte para Oracle 12, y la esperada actualización del soporte de Visual Studio...2010. Se afirma que es posible el soporte de versiones superiores, pero no está testeado (VS 2013). En cuanto a Java, continúa soportado hasta la versión 7 (ya existente en 7.1) y en cuanto a OS400, el soporte alcanza a IBM i 7.1.
Evidentemente, hace falta la participación de la base de clientes, si queremos ver otras nuevas características disponibles.
Plex 7.2 en la wiki oficial (CA).
Lista de fixes en la wiki oficial de Plex.
Matriz de compatibilidad de Plex 7.2 (requiere usuario).

Una arquitectura de dos velocidades (McKinsey)

Un par de artículos publicados por McKinsey este mes de diciembre, (1 y 2, firmados por Oliver Bossert, Jürgen Laartz, y Tor Jakob Ramsøy), plantean una estrategia realista de adaptación en una empresa anterior al universo digital. Los autores proponen una estrategia de dos velocidades para sumar una capa digital a una empresa de corte tradicional. Si lo releemos un poco, podríamos concluír que el escenario descripto es común y mayoritario: las empresas nativas digitales son una minoría, aunque se hayan convertido en hegemónicas en muy pocos años. Excelente artículo para pensar estrategias.
El postulado de los autores es este:

Unlike enterprises that are born digital, traditional companies don’t have the luxury of starting with a clean slate; they must build an architecture designed for the digital enterprise on a legacy foundation. What’s more, while most companies would have been comfortable in the past going through a three- to five-year transformation and not implementing new features in the meantime, today’s highly competitive markets no longer allow players to alter architecture and business models sequentially. It is therefore important to realize that the transformation toward digital is a continuous process of delivering new functionality.

Para los autores, esta migración al mundo digital requiere hacerse fuertes en cuatro aspectos: Innovación en el desarrollo de productos y servicios, habilidad para atender múltiples canales, capacidad de análisis de datos y tendencias (big data), automatización y digitalización de procesos de negocios:

First, because the digital business model allows the creation—and shorter time to market—of digital products and services, companies need to become skilled at digital-product innovation that meets changing customer expectations. One such new offering for consumers is car-insurance policies enabled by geolocation-tracking technology, where the price of the policy depends on how much and how aggressively a person actually drives.
Second, companies need to provide a seamless multichannel (digital and physical) experience so consumers can move effortlessly from one channel to another. For example, many shoppers use smartphones to reserve a product online and pick it up in a store.
Third, companies should use big data and advanced analytics to better understand customer behavior. For example, gaining insight into customers’ buying habits—with their consent, of course—can lead to an improved customer experience and increased sales through more effective cross-selling.
Fourth, companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.

El problema básico al que hay que encarar es el relacionado con la contradicción entre una empresa estable, con procesos de negocios manejados de manera conservadora, frente a la necesidad de ser flexible, ágil, rápido y variable en la atención de los nuevos procesos. Esto requiere otra manera de organizar las actividades de IT:

While a few players have overcome some of these hurdles, it is a big challenge for many IT executives to implement all four levers so customers can, for instance, purchase individually tailored products across multiple channels. One important reason is that the legacy IT architecture and organization, for example, which runs the supply-chain and operations systems responsible for executing online product orders, lacks the speed and flexibility needed in the digital marketplace.
Indeed, the ability to offer new products on a timely basis has become an important compe­t­itive factor; this might require weekly software releases for an e-commerce platform. That kind of speed can only be achieved with an inherently error-prone software-development approach of testing, failing, learning, adapting, and iterating rapidly. It’s hard to imagine that experimental approach applied to legacy sys­tems. Nor would it be appropriate, because the demand for perfection is far higher in key back-end legacy systems. Quality, measured by the number of IT system errors, and resilience, measured by the availability and stability of IT infrastructure services, comes at slow speed but is critical for risk- and regulatory-compliance management and for core transactional activities such as finance and online sales. In contrast, lower IT-system quality and resilience can be acceptable in customer-facing areas, for instance, when users participate in the testing of new software. For these reasons, many companies need an IT architecture that can operate at different speeds.

Los autores valúan como imprescindibles los dos tipos de procesos (tradicionales, difícilmente transformables, y digitales, con grandes requerimientos de agilidad, flexibilidad y rapidez de respuesta). En este marco, elaboran una serie de recomendaciones para mantener e interactuar entre ambos tipos de procesos y necesidades:

Manage a hybrid target architecture with very different platforms. Digital target architectures are heterogeneous, with trans­actional platforms managed for scalability and resilience coexisting alongside other systems optimized for customer experience. The transformation can be sustained only if a high-level target architecture and standards in critical areas such as cybersecurity are clearly described from the beginning. Without them, the transformation can be slowed down by the complexity of legacy and new hardware and application provisioning.
Plan for ongoing software delivery with blends of methodologies. There isn’t time to develop software by using a waterfall model and then separating the transformation into several long phases, as in traditional multi-year IT transformations. Nor is the solution to migrate all delivery to agile methodologies. The answer is to do both but blend the benefits of agile (iterative development, continuous delivery) into the waterfall model. Now, the software solution for each business challenge has to be constantly developed, tested, and implemented in an integrated fashion. This requires clear segregation of platforms into domains managed for fast iterative delivery (for example, for customer-experience applications) or for transactional integrity (for back-end transactional systems).
Develop the low-speed architecture, too. It’s important to establish a clear distinction between the two IT models from the beginning and not only focus on the fast-speed part but also develop the transactional back-end architecture. Those systems of record require rigorous development and testing methodologies and must be managed for resilience and scalability, with no compromises.
Build a new organization and governance model in parallel with the new technology. In the digital enterprise, business and IT work together in a new and integrated way, where boundaries between the two start to blur. This partnership has to be established during the transformation^.
Change mind-sets. By transforming the architecture, technology can become a key fac­tor for a company’s competitiveness. Such a development requires increased management attention and usually a place on the board agenda. While IT efficiency clearly remains important, spending levels may well rise as companies transform IT from largely being a necessary expense to being a true business enabler. As such, expenses are managed as investments rather than just costs; this will often require a substantial mind-set shift for the organization.
Run waves of change in three parallel streams. In a two-speed transformation, it makes sense to have an implementation plan that runs in three parallel streams. The digital-transformation stream builds new functionality for the business, supported by the results of a short-term optimization stream that develops solutions that might not always be compliant with the target architecture (for example, using noncom­pliant interfaces). To ease the development of short-term measures and create a sustainable IT infrastructure, an architecture-transformation stream is the third necessary component.

Las técnicas descriptas pueden verse no sólo como aplicables a una estrategia de cambio hacia una economía digital, sino a cualquier escenario de una empresa grande, con una tradición establecida de procesos de negocios y soluciones tecnológicas establecidas pero anticuadas; la idea central que destaco de la visión de Bossert y otros es la de articular dos velocidades en el desarrollo de nuevos procesos y arquitecturas, dando a cada parte su importancia relativa, y manteniendo procedimientos diferenciados según de qué área se trate.
Recomiendo releer varias veces estos artículos, extrapolando cuando parezca necesario.

Michael S. Hart y el Proyecto Gutenberg

A propósito de la oferta de la Fundación de Software Libre, (elegir un regalo de un producto recomendado por la FSF), dando una recorrida sobre las sugerencias, se observa la oferta de libros electrónicos del Proyecto Gutenberg (junto a otros especialmente interesantes, como GIMP, Least Authority, o Trisquel GNU/Linux). Luego de revisar unos minutos el sitio del Proyecto Gutenberg, hay dos elementos que quisiera traer a primer plano: La noticia de la desaparición de su fundador, que desconocía, y la advertencia del Proyecto acerca de las negociaciones establecidas bajo el paraguas del TPP (Trans-Pacific Partnership), para asegurar la protección de derechos de autor globalmente.
Respecto a la desaparición de su fundador, Michael S. Hart, sólo me entero un par de meses después. Quizá se deba a desatención, pero me resulta curioso no haber conocido antes la noticia ¿relegada a noticia de tercer orden? no podría asegurarlo, pero no hay duda de que su actividad de por sí iba en contra de quienes tienen en sus manos difundirlo.Sin duda le debemos -y le deberemos- mucho a Hart, en la medida en que su esfuerzo ayudó a preservar un espacio abierto de conocimiento, y a contraponer otro modo de valorar la escritura y su difusión. Dice The Economist sobre Hart:

Everyone should have access to the great works of the world, whether heavy (Shakespeare, “Moby-Dick”, pi to 1m places), or light (Peter Pan, Sherlock Holmes, the “Kama Sutra”). Everyone should have a free library of their own, the whole Library of Congress if they wanted, or some esoteric little subset; he liked Romanian poetry himself, and Herman Hesse's “Siddhartha”. The joy of e-books, which he invented, was that anyone could read those books anywhere, free, on any device, and every text could be replicated millions of times over. He dreamed that by 2021 he would have provided a million e-books each, a petabyte of information that could probably be held in one hand, to a billion people all over the globe—a quadrillion books, just given away. As powerful as the Bomb, but beneficial.

En un contexto en que la obra literaria o científica es cada vez más manejada como un producto que se debe comprar, llevado a extremos que van contra miles de años de transmisión del conocimiento, el Proyecto Gutenberg nos recuerda que la Ilíada y la Odisea se transmitieron por siglos verbalmente, y que si se hubieran seguido los criterios que hoy se pretenden pasar por "naturales", ambas probablemente se hubieran perdido.
Por lo tanto, quisiera enmendar el olvido cometido con Hart, transcribiendo su visión de la misión del Proyecto:

The mission of Project Gutenberg is simple:

To encourage the creation and distribution of eBooks.

This mission is, as much as possible, to encourage all those who are interested in making eBooks and helping to give them away.
In fact, Project Gutenberg approves about 99% of all requests from those who would like to make our eBooks and give them away, within their various local copyright limitations.
Project Gutenberg is powered by ideas, ideals, and by idealism.
Project Gutenberg is not powered by financial or political power.
Therefore Project Gutenberg is powered totally by volunteers.
Because we are totally powered by volunteers we are hesitant to be very bossy about what our volunteers should do, or how to do it.
We offer as many freedoms to our volunteers as possible, in choices of what books to do, what formats to do them in, or any other ideas they may have concerning "the creation and distribution of eBooks."
Project Gutenberg is not in the business of establishing standards. If we were, we would have gladly accepted the request to convert an exemplary portion of our eBooks into HTML when World Wide Web was a brand new idea in 1993; we are happy to bring eBooks to our readers in as many formats as our volunteers wish to make.
In addition, we do not provide standards of accuracy above those as recommended by institutions such as the U.S. Library of Congress at the level of 99.95%.
While most of our eBooks exceed these standards and are presented in the most common formats, this is not a requirement; people are still encouraged to send us eBooks in any format and at any accuracy level and we will ask for volunteers to convert them to other formats, and to incrementally correct errors as times goes on.
Many of our most popular eBooks started out with huge error levels--only later did they come to the more polished levels seen today. In fact, many of our eBooks were done totally without any supervision--by people who had never heard of Project Gutenberg--and only sent to us after the fact.
We want to continue to encourage everyone to send us eBooks, even if they have already created some without any knowledge of who we were, what we were doing, or how we were doing it.
Everyone is welcome to contribute to Project Gutenberg.
Thus, there are no dues, no membership requirements: and still only the most general guidelines to making eBooks for Project Gutenberg.
We want to provide as many eBooks in as many formats as possible for the entire world to read in as many languages as possible.
Thus, we are continually seeking new volunteers, whether to make one single favorite book available or to make one new language available or to help us with book after book.
Everyone is welcome here at Project Gutenberg.
Everyone is free to do their own eBooks their own way.

Simple, y fundamental.
En otra nota hablaremos de la iniciativa trans pacífica, que requiere tiempo.

Fin de año con la Free Software Foundation

La FSF propone festejar las fiestas regalando productos de software libre, y publica una lista comparativa de regalos "libres", y sus equivalentes de orígen propietario. No es una lista extensa, pero no está de más revisarla, y tenerla en cuenta. Tanto como a la FSF misma.

Plex en la transición de Visual Studio...(y otras transiciones)

Mientras Plex 7.2 continúa en beta, y nuevos cambios de arquitectura aparecen en el horizonte, me interesaría retomar una conversación iniciada en mayo: qué hacer con la variante c++ (WinC) de Plex. Como se mencionara entonces, existe una iniciativa expuesta por Simon Cockayne, product manager,  por actualizar el soporte de Visual Studio de 2005 (qué horror!) a Visual Studio 2012 "o el más reciente que exista". Algo más que necesario...Pero a partir de este punto, existen diferentes líneas de avance. Dos o tres ideas sobre esto:

Algunas respuestas sugieren pasar entonces directamente a una variante .NET, esto sería, dado que la línea principal de trabajo en CA Plex parece apoyarse en .NET, evolucionemos a ella. Pero esto presenta tres escollos, a primera vista: Uno, económico, ya que no se trata simplemente de reconfigurar el modelo para adoptar una nueva variante (cambiar el valor de un combo box en la ventana de configuración), sino de pagar nuevas licencias, una por cada asiento que vaya a trabajar generando en la nueva configuración. Aunque existan ofertas o paquetes de negociación, es un costo que hay que pesar.
Un segundo escollo de importancia es la migración: no se trata tan solo de migrar paneles, sino de inventariar el conjunto de APIs de bajo nivel que se hayan estado utilizando basadas en c++/win32, y probablemente reescribirlas. Se trata de tener en cuenta la diferencia de modelo de arquitectura (managed/unmanaged code; framework de .NET). Todos los interesados, (y aquí se debería incluír también al soporte de CA) deben pesar el impacto de migrar no solo el código evidente, sino también cualquier dependencia de ActiveX, OLE, COM y VBScript. Todo ha sido afectado por el modelo .NET.
Y el tercer escollo a tener en cuenta es .NET en sí mismo: este parece ser un buen momento de la arquitectura, considerando los planes para abrirla a la comunidad en general. Pero atendiendo a los adelantos informados, no está claro que la apertura sea suficiente ni exenta de nuevas contradicciones. Este es un tema que requiere ser tratado por separado. Pero además, tampoco está claro qué papel tendrá finalmente .NET en los planes futuros de Microsoft, considerando su evolución a la nube, y los cambios de arquitectura desarrollados a partir de Windows RT.

Entretanto, no sólo evoluciona la arquitectura de Windows en general, sino también Visual Studio y el propio c++, tanto el estándar en sí mismo como la interpretación de Microsoft: hoy c++ 11, con planes para c++ 17. ¿Cómo de integrados están los planes en curso? Considerando la experiencia pasada, me pregunto, con pocas esperanzas de que se pueda tomar un curso preventivo, si no hubiera sido estratégicamente preferible, largo tiempo atrás, mantener un núcleo del generador mas apoyado en el estándar y algo distanciado de los planes de desarrollo de Microsoft. La variante de Plex es WinC, e implica un compromiso con Windows ya en su nombre: así WinC se ha desarrollado apoyado en las MFC, en ActiveX y VBScripts, y en mucha menor medida, en OLE y COM. Ahora cualquier plan de evolución o migración debe partir de este hecho. Un escenario algo más mediado hubiera permitido ver el código c++ con un mayor grado de portabilidad. En fin, la encrucijada por .NET o no, es una propia de Microsoft, en un universo cada vez más abierto, y cuando el propio Visual Studio se ve obligado a contemplar extensiones para otros sistemas operativos. ¿Podría ser conveniente persistir en Visual Studio, y abordar a partir de allí la entrada a otros medios? en fin, la apertura de .NET se propone entrar en Linux y OS X . Apuesta dudosa...Pero esto requiere una nota aparte.