No comprometa proyectos basados en Google II

 Como hemos dicho antes, la confiabilidad en la continuidad de un proyecto o un producto de Google, tiende a cero. Tanto que existe una página "Killed by Google", con un recuento de productos e iniciativas que en su momento fueron populares y que fueron abandonadas. Decir "abandonadas" quiere decir que lo que alguien hubiera invertido se ha perdido, o a duras salvado con un costo de reingeniería.

Liz Martin en Medium (Why Google Keeps Killing Its Products):

(...) But here’s the thing: killing off projects is part of Google’s innovation process. Many of the Google products that people use today include features from things that no longer exist.

For example, Google Inbox was killed off in 2019 but many of its features migrated over to Gmail. Google Play Music was killed off in 2020, but several of its features are being used in Youtube Music. Google Allo was killed off in 2019, but its best features were ported over to Android Messages.

(...) Google exists in a fast-paced space. The faster the company can fail, the more quickly it can innovate and beat the competition to the newest technological advancement. No matter how chaotic, these calculated risks are the method to Google’s madness.

Question: What do you think Google will kill off next? What product would you like to see Google bring back to life?

 

China, Gitee, GitHub

 En Technology Review, del MIT, el 30 de mayo, escribe Zeyi Yang

Earlier this month, thousands of software developers in China woke up to find that their open-source code hosted on Gitee, a state-backed Chinese competitor to the international code repository platform GitHub, had been locked and hidden from public view.

Gitee released a statement later that day explaining that the locked code was being manually reviewed, as all open-source code would need to be before being published from then on. The company “didn’t have a choice,” it wrote. Gitee didn’t respond to MIT Technology Review, but it is widely assumed that the Chinese government had imposed yet another bit of heavy-handed censorship.

For the open-source software community in China, which celebrates transparency and global collaboration, the move has come as a shock. Code was supposed to be apolitical. Ultimately, these developers fear it could discourage people from contributing to open-source projects, and China’s software industry will suffer as a result

 Una nueva muestra de la dependencia de grandes actores existente en el mundo Open Source en primer lugar. Pero yendo más lejos, una indicación de la limitada capacidad de elección existente en el mundo de la tecnología y de las ideas y culturas transportadas por su medio. El problema descubierto por los desarrolladores chinos con su propio repositorio "oficial" puede repetirse potencialmente en el mundo occidental, bajo el sello de las grandes tecnológicas que dominan directa o indirectamente los repositorios abiertos, "públicos", y las infraestructuras y servicios en la nube. Ni Google, ni Microsoft, ni Amazon han demostrado neutralidad en su historia, y son protagonistas de décadas de juicios por prácticas desleales. Confiar tu base de código, o tus aplicaciones en este marco no es lo más apropiado, probablemente.

Un afilado comentario sobre el estado del uso de modelos

Scott Finnie publica a finales de Septiembre un acertado comentario (a mi juicio por lo menos) crítico sobre el estado y evolución del uso de modelado en la vida real, en sus distintas vertientes actuales. Finnie encuentra que algunas de las tendencias en modelado han evolucionado mal, y prácticamente no encuentra alguna via conceptual o herramienta aplicada que sea totalmente satisfactoria.
Finnie comienza dedicando un párrafo breve a los métodos más formales, que considera en general inaplicables por sus exigencias:

Formal methods can definitely contribute to the “better software” imperative. Any impact on “faster” is a second order effect however: the models have to be translated into working software by hand. And the learning curve can be steep, requiring a solid foundation in the theory and notation of one or more mathematical disciplines (predicate logic, sets, graphs).

En segundo lugar, Finnie se ocupa de los lenguajes específicos de dominio (DSLs) sobre los que señala sus límites de adopción en la dificultad que representa sumir la creación de lenguajes adecuados a una diversidad de problemas por parte de equipos de empresa. Sólo los ve aceptables en nichos de empresas cuyo producto es el software, en general:

Domain-specific approaches can directly address both “better” and “faster”. But they are not without hurdles, both technical and organisational. On the technical front it’s the challenges of language design. Textual approaches (e.g. Spoofax, Xtext, MPS, Rascal) require the designer to understand compiler construction: parsing, linking, semantic analysis, type systems and so on. Graphical approaches such as MetaEdit+ perhaps simplify that. But there’s still the question of designing a language.
The organisational barriers are at least as significant – and independent of the textual/graphical debate. Getting traction for a DSL depends heavily on the organisation’s approach to software. It’s possible in companies building software products, especially those offering related product families. The cost of investing in language design and tooling is justified through repeatability and hence efficiency. But not all software falls into the “product family” bucket. Even when it does, some organisations – and many developers – are nervous about building a proprietary language. Maintainability, recruitment and CV curation can be powerful adversarial forces.

Finalmente, se enfoca en los lenguajes de modelado de propósito general, de los que espera más, pero encuentra grandes dificultades. La principal objeción a este tipo de modelado, enfocándose fundamentalmente en UML, es la incapacidad de casi todas las variantes desarrolladas de pasar de un esquema más o menos definido, a código ejecutable, o como suele decirse, a modelos ejecutables:

The vast majority of UML models are mere sketches. Sketches aren’t working software.
Sketches need lots of human endeavour to translate them into working software. Which isn’t to say they’re bad: a quick diagram on the whiteboard can be invaluable. But it’s a long way from working software. At the height of its hype curve, the UML wasn’t capable of describing precise, executable models(²). Without those, it’s impossible to automate software generation. Without automation, we don’t get better software quicker.
This is the fundamental mistake with MDA:

1. An incomplete language intended for sketches is not a viable basis for precise, executable models.
2. Without precise models,
   1. no formal checking can take place. So the impact on “better” is marginal;
   2. no process automation can take place. So the impact on “faster” is at best nil.

Summing up: MDA didn’t deliver better software quicker. It had the hype and the backing of large organisations. It didn’t stick because, brutally, it didn’t work.
So – in the context of general purpose modelling – let’s be clear about this: as long as a manually intensive process sits between a model and working software, the model is no more valuable than a sketch.

Finnie sostiene que hoy están dadas las condiciones para reparar estas faltas. Enumera una lista de asuntos por ajustar y resolver, con final abierto:

• whilst there are a plethora of tools for building models, few of them support executable models. Of that few, far fewer still are actually rewarding to use.
• we’re missing the pre-existing models that serve as exemplars. Models that are demonstrably translated into real, working software. Models that can be adapted or reused to meet different requirements.
• we’re missing the translators that turn those models into working software. Automatically, quickly and repeatably. We have the tools to write those translators: we don’t have the translators themselves. At least not robust, industrial quality translators that produce robust, industrial quality software. That can be used by real users or sold to real customers. Results that looks as good as, and function as well as, ‘hand written’ alternatives. Crucially, those translators need to be open for adaptation.
• we’re missing the cohesive environments that make it easy. Environments that don’t need weird hacks or obtuse incantations to make them work. Tools that “just work”. Tools that combine the constituent parts for modelling and translation into a consistent, seamless, industrial-quality experience.
• we’re missing eco-systems that pull these things together to forge communities. Communities that generate interest because they’re doing cool stuff.

Ante esta discusión, que creo que sigue siendo de interés fundamental, desde nuestra comunidad de usuarios de Plex...¿cuántas oportunidades se han perdido  en este camino para lograr una mayor abstracción y alcance?
Nota: si lee el artículo de Finnie, no deje de leer también los comentarios posteriores.

De Eclipse a IntelliJ...y vuelta

El año pasado hubo mucho ruido con el congelamiento de los desarrollos de Android para Eclipse, y el paso a su IDE propia, y el gran crecimiento del respaldo a IntelliJ tanto para desarrollos con Android, como en general para Java. Contínuamente se podía observar la adopción de IntelliJ Idea por nuevos desarrolladores.
Pero ahora parece haberse presentado un cambio de política comercial de JetBrains, dueño de la herramienta, un cambio que pone en evidencia el punto débil del movimiento hacia su IDE desde Eclipse: está anunciado un nuevo modelo de relación comercial basado en la renta y no la venta de sus productos.
Basicamente, el nuevo "comprador" ya no será dueño de su instalación, salvo durante el período de renta. Es decir, esto es lo que va desde un producto construído por una amplia comunidad, capaz de evolucionar basado en el interés de sus participantes, a otro condicionado a las estrategias comerciales de sus propietarios. Como dice algún comentarista (Mike Milinkovich), aunque esta medida hoy vuelva atrás, marca una diferencia fundamental en las estrategias y horizontes de uno y otro producto.

Una guía de trabajo con Plex

George Jeffcock, en su sitio relacionado con sus Stella Tools, dedica algunos párrafos a recomendar buenas prácticas en el uso de Plex. Coincidiendo con las guías de enseñanza usuales en Plex, George recomienda:

STOP Coding - Start Architecting
Plex development is essentially a three-step process involving Data Modeling, Pattern Matching and Customization. There are no shortcuts, each step must be adhered to achieve the goals. Missing a step may seemingly achieve a short term solution but in the medium and long term the solution will surely decay far quicker than it should have. The mindset required to use plex effectively is one of:

• Object oriented approach to application design to eliminate the need to code repeatable elements of applications
• Working at a level of abstraction rather than at the ‘nuts and bolts’ level, probably just saying the first point again but this can’t be over stressed the importance to think this way instead of coding procedural code line after line
• Model-based and pattern-based approach to increased application quality and flexibility
• Multiple inheritance is a key part of the way applications are developed in CA Plex therefore leveraging the full value of a site’s existing patterns
• Encapsulation so that function interfaces contain only the attributes pertinent to the use of the function
• An application should be separated into separate layers/tiers, Functionality should be strictly separated into data access, business logic and presentation logic, as this promotes the consistency of the application as well as the possibilities to reuse functionality.

La primera regla que un nuevo desarrollador en Plex debe asumir, es que debe escribir la menor cantidad de código posible: olvidarse de escribir líneas de código, y pensar, pensar el modelo de datos y relaciones, luego estudiar cómo abstraer y explotar patrones existentes, y sólo luego escribir código, sólo lo que es estrictamente necesario. "Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it"

Qué va de un AS/400 a un System i

Aunque el lanzamiento corresponde a mediados del año pasado, la cuenta de Google+ de IBM Red Books, volvió a destacar una publicación de mucho interés en estos últimos días: Modernization Redbook has been published!. El comentario refiere al Red Book "Tools and Solutions for Modernizing Your IBM i Applications", editado en septiembre de 2014, y renovado ahora. Este libro contiene información de servicios y características del System i, pero particularmente la descripción de implementaciones de distintos socios de negocios de IBM. Este texto merece ocuparse de él, pero ahora lo que particularmente me interesa es la entrada de blog que aparece relacionada: "Modernization Redbook has been published!". Porque esta entrada, de junio de 2014, comenta un red Book que es la base de "Tools and Solutions...". Se trata del libro "Modernizing IBM i Applications from the Database to the User Interface and Everything in Between ", y éste sí es especialmente interesante, fundamental. En este texto se explica qué ha cambiado, y qué es posible hacer hoy con un System i. Realmente, mucho ha pasado entre el inicial AS/400 y su continuidad actual.
El libro tiene toda una primera parte donde habla de modernización, un aspecto especialmente requerido en entornos de AS400, en los que es frecuente encontrar cierto conservadorismo en el uso del equipo. Quizá no en general, donde el área de IT podría estar actualizado, pero sí en el área del AS400. Probablemente la propia ventaja de que pueden ejecutarse aún antiguas aplicaciones migradas de versiones anteriores de IBM (S/36, S/38 y más) tiende a mantener un ambiente que no cambia lo que funciona. Y lo mismo sucede en parte con el horizonte de los recursos humanos involucrados. Por lo tanto, la minuciosidad de las explicaciones en el terreno de la modernización, son entendibles.
Pero el resto del libro es material más que útil, destacando los nuevos servicios que el System i dispone, lo que lo hace distinto a sus orígenes:
El ambiente integrado de lenguajes (ILE), que permite interactuar entre distintos lenguajes disponibles en el equipo. A través del libro se explican distintos casos de aplicación del ILE. Es fundamental entender las posibilidades del ILE  para la explotación del equipo, por ejemplo, desde el punto de una arquitectura SOA.
Java, PHP, Ruby on Rails integrados. La disponibilidad de lenguajes capaces de trabajar para arquitecturas web, o articulables sobre múltiples plataformas, ha abierto completamente las posibilidades del equipo.
Servicios de administración de datos extendidos (data centric development). Desde el lejano inicio del DB2 sobre el AS400, las posibilidades de trabajo con la base de datos han cambiado y mejorado radicalmente. Nunca me he quejado de la eficiencia de DB2 en el AS400, pero los ajustes que se hacen sobre el ahora System i extienden su excelente servicio a las actuales necesidades de grandes bases de datos (Big Data).
El libro describe esta evolución así:

The original database designs might have come from an S/36 environment. This origin implies that the files are programs that are based on a flat file design. If the design is from the S/38 or early days of the AS/400, chances are that the database design was created one time and has lost any resemblance to that original design over time. Programmers can be good at adding a function or extending something after they do only a cursory review of the effect to the overall design. Although these designs continue to work on IBM i, neither approach takes full advantage of the power of DB2 for i.
Since the announcement of the AS/400, 25 years ago, IBM has continued to add new features and new functions to the database with each new release and technology refresh. A contemporary design is critical to take advantage of these new functions and to experience the performance improvements inherent in the updates. It is time to look at a data-centric view of development (...)
One of the most important improvements to the database over the years is the advancement of SQL. When we talk about a modern database, SQL is a requirement. This is not to suggest that native database access should be forbidden, but instead that it should use the correct tool for the job.
Traditional record access for small data sets can be effective. But, as data sets become larger, the effectiveness of native access can diminish. Additionally, your applications are required to take more responsibility for processing data across multiple tables. This processing can lead to complicated application code that can cause performance issues.
This situation is where SQL must be used. The beauty of SQL is that it uses the system or operating system versus the application. Many complicated data access routines can be replaced by SQL, which allows the system to figure out the indexes that make the most sense to retrieve the wanted data. The SQL engine on IBM i has undergone significant development focus over the past few years. The database has become better at creating and maintaining indexes to optimize your data access. The more records that you need to process, and views you need to combine, the better SQL can perform. In addition to the optimized indexing, SQL can use the multi-threading capabilities of the system without causing RPG and COBOL program (which are single-threaded) issues.

El i está abandonando definidamente el enfoque que siempre mantuvo sobre la base de datos, orientada a la recuperación de filas (orientada a registro - READ/WRITE) para adoptar el punto de vista de la orientación a sets de datos, dando prioridad al SQL. IBM  está recomendando abandonar la creación de tablas mediante DDS para hacerlo con DDL.
Este es un punto donde Plex debe actualizarse, acompañando esta "revolución copernicana" en el manejo de datos. Notablemente, Plex es capaz de generar código SQL, pero lo hace para variantes ODBC/JDBC, dando prioridad en las variantes de servidor/400 (RPG400, RPGIV, SQLRPG400, SQLRPGIV) a la "orientación a registro". No es que no se pueda explotar este cambio en Plex, pero exije un grado de intervención manual que no debería tener, dado que tiene los elementos necesarios para otro enfoque. Entre las modificaciones solicitadas por los usuarios, algunas de las más importantes se concentran en este área (generación de DDL, explotación a fondo de SQLRPGIV).
Otros aspectos del cambio en el System i son los relacionados con SOA y Servicios Web, Sevicios XML, Soporte de servidores Web, Soporte de Cloud, enlace con aplicaciones móviles...
Pero esto será para conversar en la siguiente oportunidad. Por ahora, hasta aquí.

Diez reglas para recordar (y seguir...)

Firmado por Javin Paul, un artículo que recuerda diez reglas importantes de orientación a objetos en el diseño con Java (10 Object Oriented Design Principles Java Programmer should know), que podríamos extender fácilmente a otros campos (y estoy pensando en Plex). Un pequeño decálogo, tan escueto que podríamos pegarlo en una pizarra frente a nuestros ojos, y que deberíamos repasar todos los días.

 DRY (Don't repeat yourself)
Our first object oriented design principle is DRY, as name suggest DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. Benefit of this Object oriented design principle is in maintenance. It's important  not to abuse it, duplication is not for code, but for functionality . It means, if you used common code to validate OrderID and SSN it doesn’t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beware of such coupling and just don’t combine anything which uses similar code but are not related.

Encapsulate What Changes
Only one thing is constant in software field and that is "Change", So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several of design pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.

Open Closed Design Principle
Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that's the goal of Open Closed Design principle. By the way, Open Closed principle is "O" from SOLID acronym.

Single Responsibility Principle (SRP)
Single Responsibility Principle is another SOLID design principle, and represent  "S" on SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality. If you put more than one functionality in one Class in Java  it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality,  which require another round of testing to avoid any surprise on production environment.

Dependency Injection or Inversion principle
Don't ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of this design principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to  implemented Dependency injection like using  byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of IOC and DI design pattern to learn more about this SOLID design principle. It represent "D" on SOLID acronym.

Favor Composition over Inheritance
Always favor composition over inheritance ,if possible. Some of you may argue this, but I found that Composition is lot more flexible than Inheritance. Composition allows to change behavior of a class at runtime by setting property during runtime and by using Interfaces to compose a class we use polymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance.

Liskov Substitution Principle (LSP)
According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue". LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality ,and does violated LSP. In order to follow LSP SOLID design principle, derived class or sub class must enhance functionality, but not reduce them. LSP represent  "L" on SOLID acronym.

Interface Segregation principle (ISP)
Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that. This happens mostly when one interface contains more than one functionality, and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this design principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Programming for Interface not implementation
Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and head first design pattern book.

Delegation principle
Don't do all stuff  by yourself,  delegate it to respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behavior.

Y volviendo sobre la idea de su aplicabilidad en Plex, sin duda lo es. En algunos casos fácilmente entendible, (Favor Composition over Inheritance, Encapsulate What Changes, DRY,  Favor Composition over Inheritance) y en otros casos, después de luchar contra la vía fácil de hacer las cosas (Programming for Interface not implementation). Solo veo difícil implementar Dependency Injection. Y cuando me refiero a aplicabilidad, lo hago a nivel del modelo, no a nivel del código generado, donde su aplicabilidad está asegurada.
Plex, como otros productos, admite distintas interpretaciones, distintas formas de desarrollar. Aplicar principios de OOD permite explotarlo en forma más productiva, potenciando sus características. Luchar por no usar una hoja de ruta rutinaria favorece resultados consistentes y duraderos.

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.

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.

Evaluando la comunidad oficial de Plex

En la comunidad de usuarios de CA Plex estamos atravesando la enésima modificación del sistema de intercomunicación entre el dueño del producto (CA) y sus usuarios (todos nosotros). A varios meses del cambio, ¿qué podemos destacar de positivo o negativo?
Primero lo positivo...
Mayor visibilidad: finalmente, parece que CA unifica una misma vía de comunicación con usuarios, distribuidores e incluso personal interno. No sé si a alguno de los community manager "on charge" les importa algo, pero ahora los productos de desarrollo de aplicaciones aparecen en el flujo de discusiones junto a las estrellas de la promoción del negocio. Un aspecto que a alguien podría llamarle a atención es el número de participantes en discusiones, suficientemente alto en Plex, 2E o Gen.
Acceso unificado al soporte, la documentación técnica o de divulgación. Existen mejores posibilidades de investigar la documentación de una incidencia o los artículos técnicos de formación. Parcialmente accesibles incluso en una búsqueda anónima en Internet.
Acceso externo a las discusiones de la comunidad de Plex/2E, tanto si se busca un problema determinado, como si se usan los alimentadores de noticias
Unificación de las dos líneas de colaboración: seguimiento de problemas y anuncios, y postulación de ideas de cambios o mejoras. Ahora ambas líneas de colaboración comparten la misma corriente de noticias, lo que favorece la participación de usuarios que antes quizá no eran concientes de que existía una vía directa de solicitud de mejoras. Quizá este sea el aspecto más interesante.
Y lo negativo:
Una vez más los cambios...algunos usuarios poco dados a conectarse a la comunidad, tardarán un tiempo en advertir que ya no sirven los viejos enlaces. Los alimentadores de noticias ya no funcionan, y hay que rehacer las direcciones usadas. El esfuerzo de comunicación puesto para facilitar la transición, muy escaso.
Los "community managers": si en las restantes comunidades se los ha seleccionado como a los de Plex/2E, tardaremos largo tiempo en tener una actividad de promoción de su parte. En nuestro caso, no parecen tener mucha experiencia en los productos. Por lo tanto, salvo dar hurras a la actividad de los usuarios, poco podemos esperar por ahora.
La transición de un producto de administración de la comunidad a otro, poco planeada (por lo menos para nuestros productos); adios a las etiquetas que previamente existieran asociando conversaciones con incidencias, y creo que adios a muchos documentos adjuntos. Al menos varias incidencias. Me resulta difícil entender que se planee un cambio y las incidencias de conversión queden para después.
La participación: por algunas semanas, mínima: quizá porque los usuarios debieran rehacer algún aspecto de sus perfiles, o quizá por falta de ubicación de las direcciones de cada cosa, o por el cambio en el manejo de incidencias. Luego ha aumentado, pero todavía sin llegar a la participación usual en el pasado.

¿El futuro? Espero que menos cambios formales, y más promoción y trabajo sobre los productos. En un momento tecnológico complejo y necesitado de este tipo de herramientas, esperamos más apoyo a la potenciación de nuestros modeladores y generadores de código.

En el filo de la nueva era...

Renovadas apuestas sobre la estrategia y ruta de desarrollo de los negocios de Microsoft. La reciente conferencia de Satya Nadella a todos los empleados ha confirmado que habrá novedades de gran porte en las estrategias de Microsoft, pero deja todavía dudas y dificultades para materializar en productos, áreas de ocupación o servicios que serán priorizados...o desechados.
Dice Mary Jo Folley:

Microsoft CEO Satya Nadella is working to focus the company on fewer, key areas where it has a better chance of winning. The areas where Microsoft is trumpeting its wins at this week's Worldwide Partner Conference are largely in the cloud -- with Azure, Office 365, Dynamics CRM Online -- and Office, Windows Server and business intelligence/SQL Server on premises.
(...) Microsoft is in the midst of attempting to pivot and remake itself as a "productivity and platforms" company, rather than a devices and services company. That change is more than semantic. In the post-Ballmer Microsoft, hardware is interesting only insofar as it "lights up" productivity software and services.

Nadella lanzó una palabra, "experiencias", para hablar de un nuevo paradigma de contrucción y funcionamiento de aplicaciones y servicios. Comenta Folley:

The focus on productivity -- and "platforms" -- is the newest focus for Satya Nadella's Microsoft. Just last week, Nadella outlined Microsoft's shift from a devices and services company to one focused on productivity and platforms. (...) Microsoft wants to offer a "complete suite of Microsoft experiences preinstalled on any device, on any platform"

Cuando Nadella habla de "experiencias", tiende a apuntar a la interacción entre aplicaciones de empresa y socialización, tratando de establecer herramientas de interconexión que hacen borrosas las diferencias entre actividad de negocios y actividad informal ¿será este un camino lleno de "experiencias"?
Entretanto Microsoft redefine sus objetivos, esta semana que termina se anunciaron 18000 despidos en el futuro próximo, lo que comenzará a convertir las ambiguas directivas en cortes y reubicaciones elocuentes. Esta cifra significa alrededor del catorce por ciento de su personal, aunque doce mil corresponden a la herencia de Nokia (25000 empleados reducidos a la mitad), lo que reduce el corte general a 6000, alrededor de un cinco por ciento (1). No sólo una gran reorientación de negocios y objetivos, sino también un compromiso financiero de cerca de quince mil millones de dólares en indemnizaciones.
Escalando la transición forzada por el gran cambio en los negocios habido en el mundo (2), todo es incierto en Microsoft, desde las tecnologías de sustento, hasta el objetivo de los negocios. Téngalo en cuenta cuando estime sus planes de desarrollo de tecnología, y sus próximas compras y compromisos de larga duración.

Microsoft End-of-service: prepare su cronograma

Comentado por Mary Jo Foley esta semana: Microsoft comunica el fin de soporte de varios de sus productos para este 2014, y los planes para los próximos años. Es oportuno estar al tanto de este cronograma, para organizar las propias estrategias: Windows 7, Windows Server 2008, Exchange Server 2010 y Windows Phone 7.8  pasan a soporte extendido en enero de 2015 (El soporte extendido dura 5 años e incluye actualizaciones de seguridad gratuitas y soporte técnico con revisiones de pago. Además, Microsoft no aceptará solicitudes de cambios de diseño o nuevas características durante la fase de soporte extendido, según indica el propio anuncio de Microsoft). Foley recuerda que este año también pasan a "soporte extendido" Office 2010 y Sharepoint 2010:

Support for Office 2010 with Service Pack 1 ends on October 14, 2014, as does support for SharePoint 2010 with SP1. Support also is ending for Forefront Unified Access Gateway 2010 with SP3 and Visual Studio 2012 Remote Tools, Test Professional, and Express for Web, Windows 8 and Windows Desktop.

pero además, que finaliza todo soporte para Windows Server 2003:

Complete end of support for Windows Server 2003 is approaching next year, as well. On July 14, 2015, Microsoft's extended support period for that product cuts off, which means the company won't be issuing patches, updates or fixes of any kind for that operating system (unless users have pricey Custom Support Agreements in place). A number of small businesses are still running Windows Server 2003. Microsoft officials are hoping to convince them to move to Windows Server 2012 R2 and/or Azure

Es decir, en sólo un año más, todo la comunidad de instituciones, negocios e individuos que mantiene algún tipo de licencia de Microsoft, se encontrará en la encrucijada de quedar fuera de soporte (o recibir un soporte reducido) , o escalar a un nuevo modelo de sistema operativo, con todas sus conexiones e implicaciones. No se trata de cambios graduales, sino de largas listas de incompatibilidades, ausencias de soporte y documentación, sorpresivas incidencias por recursos perdidos, ignorados, desaparecidos. En el nuevo modelo al que todos los usuarios se asoman hay un corte radical con una escasa posibilidad de integración del patrimonio preexistente de aplicaciones y herramientas. No es algo que salte a la vista, pero es algo que está presente donde se enfoque la atención.
Es decir, activamente conozca el alcance de los cambios, y planee una ruta; examine su patrimonio y estime su plan de acción futuro...Quizá, si su patrimonio está muy comprometido, sea hora de estudiar otra alternativa global.

IBM: Liderazgo en fuga?

IBM 360, en computerhistory.org

Adam Hartung, en Forbes, comenta la evolución financiera y de bolsa de IBM reciente, poniendo en evidencia la errática conducción de la corporación, y su inexplicable estrategia...Hartung pone en el centro de sus decisiciones descaminadas, la baja de su inversión en investigación, lejos de lo que fuera por décadas, y la recompra de acciones, incluso recurriendo a endeudamiento. Hartung apunta a un problema de conducción de la empresa, focalizando en su actual CEO, aunque probablemente podamos hablar de más tiempo...

Why You Don't Want to Own IBM
IBM just finished a tough week.  IBM fell 2% after announcing earnings on Wednesday, dragging the Dow Jones Industrial Average (DJIA or Dow) down over 100 points.  And as the Dow reversed course to end up 2% on the week, IBM continued to drag, ending down almost 3% for the week.
Of course, one bad week – even one bad earnings announcement – is no reason to dump a good company’s stock.  The vicissitudes of short-term stock trading should not greatly influence long-term investors.  But in IBM’s case, we now have 8 straight quarters of weaker revenues.  And that HAS to be disconcerting.  Managing earnings upward, such as the previous quarter, looks increasingly to be a short-term action, intended to overcome long-term revenue declines which portend much worse problems.
This revenue weakness roughly coincides with the tenure of CEO Virginia Rometty.  And in interviews she increasingly is defending her leadership, and promising that a revenue turnaround will soon be happening.  That it hasn’t, despite a raft of substantial acquisitions, indicates that the revenue growth problems are a lot deeper than she indicates.
CEO Rometty uses high-brow language to describe the growth problem, calling herself a company steward who is thinking long-term.  But as the famous economist John Maynard Keynes pointed out in 1923, “in the long run we are all dead.”
Today CEO Rometty takes great pride in the company’s legacy, pointing out that “Planes don’t fly, trains don’t run, banks don’t operate without much of what IBM does.”  But, powerful as that legacy has been, in markets that move as fast as digital technology any company can be displaced very fast.
Just ask former CEO Scott McNealy and his leadership team at Sun Microsystems.  Sun once owned the telecom and enterprise markets for servers – before almost disappearing and being swallowed by Oracle in just 5 years (after losing $200B in market value.)  Or ask former CEO Steve Ballmer at Microsoft, who’s delays at entering mobile have left the company struggling for relevancy as PC sales flounder and Windows 8 fails to recharge historical markets.
Managing earnings is not managing for long-term success
CEO Rometty may take pride in her positive earnings management.  But we all know that came from large divestitures of the China business, and selling the PC and server business to Lenovo.  As well as significant employee layoffs.  All of which had short-term earnings benefits at the expense of long-term revenue growth.  Literally $6B of revenues have been sold off just during her leadership.
Which in and of itself might be OK – if there was something to replace those lost sales.  Even if they didn’t have any profits – because at least we have faith in Amazon creating future profits as revenues zoom. But IBM was far late to the cloud, and hasn’t shown it has anything to leapfrog industry leaders.
The REAL problems – R&D cuts, higher debt, massive stock buybacks
What should terrify investors about IBM are two things that are public, but not discussed much behind the hoopla of earnings, acquisitions, divestitures and all the talk, talk, talk regarding a new future.
CNBC reported that 121 companies in the S&P 500 (27.5%) cut R&D in the first quarter.  And guess who was on the list?  IBM, once an inveterate leader in R&D, has been reducing R&D spending.  The short-term impact?  Better quarterly earnings.  Long term impact????
The Washington Post reported more this week about the huge sums of money pouring out of corporations into stock buybacks rather than investing in R&D, new products, new capacity, enhanced marketing, sales growth, etc.  $500B in buybacks this year, 34% more than last year’s blistering buyback pace, flowed out of growth projects. To make matters worse, this isn’t just internal cash flow spent on buybacks, but companies are actually borrowing money, increasing their debt levels, in order to buy their own stock!
And the Post labels as the “poster child” for this leveraged stock-propping behavior…. IBM.  IBM

“in the first quarter bought back more than $8 billion of its own stock, almost all of it paid for by borrowing. By reducing the number of outstanding shares, IBM has been able to maintain its earnings per share and prop up its stock price even as sales and operating profits fall.

The result: What was once the bluest of blue-chip companies now has a debt-to-equity ratio that is the highest in its history. As Zero Hedge put it, IBM has embarked on a strategy to “postpone the day of income statement reckoning by unleashing record amounts of debt on what was once upon a time a pristine balance sheet.”

In the case of IBM, looking beyond the short-term trees at the long-term forest should give investors little faith in the CEO or the company’s future growth prospects. Much is being hidden in the morass of financial machinations surrounding acquisitions, divestitures, debt assumption and stock buybacks. Meanwhile, revenues are declining, and investments in R&D are falling. This cannot bode well for the company’s long-term investor prospects, regardless of the well scripted talking points offered last week.

Tendencias: IOT

El 6 de junio de 2012 se produjo el Lanzamiento Mundial de IPv6, inicio explícito del nuevo y reformulado protocolo de Internet. "IPv6" no se trató simplemente de atender la explosión social de Internet, sino que fue un paso necesario para atender a otra explosión: la perspectiva ya inmediata de extender la red de internet potencialmente a cualquier recurso susceptible de aplicarle inteligencia. Esto es, la Internet de las cosas (IOT), es decir, la posibilidad de que enormes cantidades de objetos puedan disponer algún grado de inteligencia, una dirección propia para comunicarse, y posibilidades inagotables de interrelacionarse con el mundo circundante. Sumémosle el mundo ya lanzado de la movilidad, y tendremos un universo de recursos de potencialidad sin límite. Ian Skerrett, de la Fundación Eclipse, expuso ayer mismo en pocas líneas su visión sobre el alcance de IOT. Creo que vale la pena reproducirlo, por su claridad, profundidad y síntesis:

How to categorize the Internet of Things

I was recently asked how to categorize the Internet of Things. IoT is so broad and multi-dimensional that I am not sure if there is one easy answer or set of categories. However, here is my current thinking…

1. IoT Hardware

A lot of the excitement in IoT and the maker community starts with the cheap, easily accessible hardware. Arduino, Raspberry Pi, BeagleBone are the poster kids in the space. Now there are a ton of new hardware solutions be made available, ex Parallela (16 cores for $99) , Galileo from Intel

2. IoT Standards and Protocols

There is a lot of talk about IoT protocols and which one will win. It is too early and I agree not any one protocol will win. One thing I do know is that closed proprietary solutions are not going to win. We do need to work on having a common set of standards like CoAP, MQTT, Alljoyn, SensorML, etc  Of course, we also need to make sure that we have open source implementations for these standards and protocols. That is why Eclipse IoT is so important for an Open IoT.
There will also be a lot of vertical standards that will be developed for IoT, like OneM2M, Continua, etc.

3. IoT Gateway Software

The typical IoT solution architecture will have some type of gateway solution that connect the sensors and actuators to the Internet. Eclipse Kura and Mihini are good examples of this but there are certainly others.

4. IoT Middleware

Companies like IBM, Axeda, Sierra Wireless, 2lemetry, ClearBlade, Microsoft, Eurotech, Thingworx, Litmus Automation and others are providing IoT platforms/middleware solutions. This is definitely an emerging space where all platforms are not equal. I expect to see a lot more startups and the big enterprise middleware vendors driving the innovation for IoT middleware.

 5. IoT Databases

The amount of data generated by IoT solutions has the potential to be Huge Data, not just big data. AS pointed out by Matt Asay, the exists a massive opportunity in analyzing IoT data.  Splunk seems to be the leader in this space but I expect a lot of innovation in this space.

6. IoT Solutions: IoT & Humans vs Industrial Internet

There are also a lot of  industry specific and user-case specific IoT solutions. Tim O’Reilly wrote a recent article titled ‘The Internet of Things and Humans‘ which does a very nice job summarizing the human impact of IoT. In fact a lot of the hype for IoT is around wearables and home automation.  Nest is the poster-child for IoT&H but you can’t go a week without finding another home automation solution being launched on kickstarter.
There is no doubt the human side of IoT will be important but I find the Industrial side to be a lot more compelling. SCADA systems like the London Tube system , Nespresso providing remote management of coffee machine, the work GE is doing for hospitals, aircrafts, etc. are the things  are fascinating and exciting opportunities. This is also where a lot of the profits in IoT will be made.

In the last 6 months the activity/hype around IoT has exploded. It will be fun to watch how these categories emerge and merge in the next 1-2 years. Of course an Open IoT is what is needed for all this to be successful. Eclipse IoT will be an important part of the solution.

Es hora de adelantar(se) en este escenario; ¿nuestras herramientas serán capaces de operar sobre este conjunto? ¿conocemos los recursos, infraestructura, estándares, proveedores, con los que habrá que interactuar? ¿tenemos la comprensión adecuada para transmitirla a quienes serán sus beneficiarios? Creo que sin duda, esta es la hora de los DSLs y de los modeladores y generadores de código, y comparto la expectativa de Skerrett en el papel que Eclipse pueda cumplir, por su flexibilidad y la extensión de su comunidad de usuarios y proveedores.

Migrando a System i 7.1

En un proyecto en el que trabajo, en poco tiempo más (midiendo en meses) migraremos un conjunto de sistemas IBM i (AKA AS/400, iSeries, al menos en su base), de 6.1 a 7.1, mientras que IBM ya anuncia i 7.2 . El cambio no representa  inconvenientes mayores: probablemente no haya demasiado que tocar en aquellas aplicaciones que generamos con Plex, que básicamente no debemos recompilar ni tampoco rehacer código.Únicamente deberíamos asegurarnos de que ningún API usada o procedimiento de lenguaje de control pudiera entrar en conflicto por obsolescencia. De acuerdo a la información adelantada por IBM, los problemas no vendrían por este lado. Es casi seguro que podremos seguir trabajando todas nuestras aplicaciones RPG, sus APIs, y nuestro CLs, sin modificaciones.
En cambio, tenemos asegurado trabajo de revisión con Java, quizá el área de mayores novedades en el software incluído para la versión 7.1, ya que, si consideramos que nos movemos desde 6.1, debemos tener en cuenta que la nueva versión abandona la máquina virtual estándar de Java (esta parte tampoco nos afecta, porque Websphere 7.0 ya la usa), y utiliza sólo la propia de IBM (J9). Esto sí requiere análisis y tests para aquellas aplicaciones que no se ejecutan con Websphere.  En el caso del servidor de aplicaciones, que es el que usamos relacionado con Plex, estimo que podremos mantener inicialmente la versión 7 de Websphere, que ejecuta Java 6, pero en algún momento debemos pensar en subir su versión a 8.1, que usa Java 7. Y esto implica que también deberemos planear la migración de Plex a 7.1. No es obligatorio, ya que podríamos mantenernos como hasta ahora, pero debemos pensar que también podemos llegar a estar presionados por los cambios en Windows, de 7 a 8.
A pesar de todos estos movimientos, no es mucho lo que impacta en nuestras aplicaciones, que se mantienen con cierta holgura en estos movimientos de versiones. Más bien, lo que debemos repensar es qué cosas podríamos reenfocar, sacando provecho de las nuevas posibilidades: gran parte de los cambios se manifiestan como extensiones. Mayor es el peligro si habláramos de dependencia de Windows, ya que el paso de 7 a 8 sí apunta a un cambio de arquitectura mayor. Pero de estos inconvenientes podemos hablar mejor en otro momento.
Dany Burger, en The Four Hundered, dedica un interesante artículo a los problemas de migración de i 6.x a i 7.1 y 7.2, que me motivaron a chequear nuestros propios riesgos a futuro. Como en otras ocasiones, es de reconocer y agradecer la política de cambio y migración de IBM y el iSeries (o como lo llames), que difícilmente te deje en una situación de callejón sin salida con una aplicación antigua: se puede evolucionar gradualmente sin tirar lo que ya está hecho.

Retraso de infraestructura móvil en Argentina

Este martes, La Nación publica un editorial sobre infraestructuras de telefonía móvil en Argentina, a propósito del Mobile World Congress de Barcelona. El editorial destaca la creciente distancia entre la evolución de la tecnología y su estado en Argentina, ya no sólo respecto a los países de la primera línea de desarrollo y adopción, sino también respecto a sus vecinos regionales. Una debilidad estructural y estratégica que tiene que afectar profundamente a cualquier plan nacional que se proponga como centro de negocios en servicios de software. Lo esencial dicho:

En estos días, Barcelona ha sido el escenario ideal para la cumbre global de la industria de la conectividad móvil, el Mobile World Congress (MWC, por sus siglas en inglés). Y aunque visto desde afuera y por los no iniciados en el tema, el encuentro pueda parecer todavía del futuro, no lo es. Se trata del presente bien presente, el mundo de la gran tecnología sobre el que se asienta un cada vez más pujante negocio digital.

Lamentablemente, la Argentina parece estar muy lejos de todas estas novedades, tanto de las tecnológicas como de las comerciales, y, paradójicamente, a pesar del entusiasmo con que los argentinos abrazamos todas las innovaciones. Efectivamente, una de las certidumbres que confirmó este encuentro mundial es que nuestro país, en éste como en otros temas, no tiene planes a la vista para mejorar la tecnología para celulares y, por ello, está cada vez más atrasado en América latina. Por ejemplo, fue el único de la región que no anunció la adopción de la tecnología sucesora del 3G, la 4G LTE, que permitiría mejorar el acceso a la Web desde teléfonos móviles. La adopción de este estándar es clave para superar los recurrentes apagones que afectan a las comunicaciones móviles y, sobre todo, para conectarse a Internet a alta velocidad desde el celular.
Mientras los argentinos comprobamos en carne propia este atraso todos los días, ya hay 18 países en América del Sur y el Caribe que lanzaron servicios 4G LTE, mientras que en Europa y los Estados Unidos ya se experimentan versiones más avanzadas aún.
Esta realidad tampoco es desconocida para el Gobierno, que, sin embargo, con las medidas adoptadas un año atrás, lo único que logró fue justamente atrasar a todo el sector local de la telefonía móvil. Como se recordará, en febrero de 2013, se decidió dejar sin efecto una licitación pública para asignar frecuencias radioeléctricas para los servicios de telefonía móvil, y la Presidenta instruyó al secretario de Comunicaciones, Norberto Berner, para que asignara esas frecuencias a la Empresa Argentina de Soluciones Satelitales SA (AR-SAT), propiedad del Estado, cosa que hasta ahora no ha ocurrido. Ya en diciembre de 2012, la mandataria y el ministro de Planificación, Julio De Vido, habían anunciado también la creación de Libre.ar, una nueva marca de servicios de telefonía móvil que prestaría el Estado a través de AR-SAT -fue presentada como una acción para "recuperar el éter para los argentinos"-, pero ésta fue la última noticia importante que se tuvo de esta operadora móvil.
Por su parte, las tres principales operadoras móviles de la Argentina -Telefónica, Telecom y Claro- siguen esperando que el Gobierno haga algún anuncio al respecto, y tratan de capear las cada día más crecientes dificultades para evitar las caídas recurrentes de sus redes; la demanda de ancho de banda por medio del móvil -con dispositivos cada vez más potentes- no deja de crecer, y exige mayores ajustes en las redes, con nuevas antenas y radiobases. Con este panorama, en el que las autoridades nacionales parecen no darse cuenta de la importancia del tema, no resulta extraño que la única funcionaria argentina presente en el MWC haya sido la gerenta de control de la Comisión Nacional de Comunicaciones, Anabel Cisneros.
Decíamos que la Argentina está lejos incluso de lo que es el enorme negocio digital: si licitara espectro -un recurso natural limitado por el que se transmiten las señales inalámbricas- para 4G, podría recaudar por lo menos 1000 millones de dólares, y otros 1500 millones serían necesarios para que las tres operadoras móviles locales comiencen a desplegar redes 4G LTE.
Hoy, además de la indefinición política, se cierne otro inconveniente grave: se confirmó que el servicio móvil LTE puede interferir la televisión digital terrestre, que tiene en la Argentina el país con mayor alcance de América latina. No hay que olvidar otras dos cuestiones que también dificultarían la llegada al país de la nueva tecnología: la exigencia de ensamblado de los teléfonos en Tierra del Fuego, que termina encareciendo sus precios, y el freno aduanero a las importaciones de antenas y equipos para evitar la salida de dólares.
Si pensamos que la última licitación de espectro se realizó en 1999, cuando había poco más de dos millones de usuarios de telefonía celular, y que ahora, con mucho más de cincuenta millones de líneas móviles en servicio y con dispositivos que, al permitir el acceso a Internet y a contenidos de multimedia requieren muchas más frecuencias, se está operando en las mismas condiciones que hace 13 años, se comprenderá la gravedad de la situación actual.

DSLs en su lugar

Una "vieja" entrada del blog de Bertrand Meyer, necesaria de recordar cuando se habla de DSLs (Domain Specific Languages) con alguna liberalidad: en ocasiones se los propone para resolver problemas específicos  que parecen condenados a bufurcar el camino de trabajo. La posición de Meyer es radical: ¿cuándo crear un lenguaje de dominio? Nunca:
El contexto:

It is a common occurrence in software development. Someone says: “We should design a language”. The usual context is that some part of the development requires a rich functionality set, and it appears appropriate to provide a flexible solution through a specialized language.

La objeción de Meyer:

Designing a language in such a context is almost always a bad idea (and I am not sure why I wrote “almost”). Languages are endless objects of discussion, usually on the least important aspects, which are also the most visible and those on which everyone has a strong opinion: concrete syntactic properties. People might pretend otherwise (“let’s not get bogged down on syntax, this is just one possible form”) but syntax is what the discussions will get bogged down to — keywords or symbols, this order or that order of operands, one instruction with several variants vs. several instructions… — at the expense of discussing the fundamental issues of functionality.
Worse yet, even if a language will be part of the solution it is usually just one facet to the solution.As was already explained in detail in [1], any useful functionality set will naturally be useful through several interfaces: a textual notation with concrete syntax may be one of them, but other possible ones include an API (Abstract Program Interface) for use from other software elements, a Graphical User Interface, a web user interface, yet another for web services (typically WSDL or some other XML or JSON format).
In such cases, starting with a concrete textual language is pretty silly, since it cannot yield the others directly (it would have to be parsed and further analyzed, which does not make sense). Of all the kinds of interface listed, the most fundamental one is the API: it describes the raw functionality, excluding any choice of syntax but including, thanks to contracts, elements of semantics.

Conclusión:

One of the key rules for successful software construction — as for many other ventures of course, especially in science and technology — is to distinguish the essential from the auxiliary, and consequently to devote proper attention to the essential issues while avoiding disputations of auxiliary issues. To define functionality, API is essential; language is auxiliary.
So when should you design a language? Never. Well, hardly ever.

 Si computaramos el tiempo de trabajo para definir el DSL y asegurar que funcione, en tales contextos, la adhesión a la posición de Meyer es segura...

Cloud computing y soberanía

La reciente comprobación de la nula privacidad de las comunicaciones electrónicas, ya no sólo en el tráfico de datos, sino también en las comunicaciones telefónicas o incluso en el seguimiento de matrículas de autos, ha establecido un freno importante a la expectativa de uso de cloud computing. No estamos hablando ahora sólo de prevenciones en cuanto a la seguridad o disponibilidad de los datos y servicios, sino de la intromisión incontrolada en su contenido. La comprobación de que distintas oficinas de control de seguridad en múltiples países pueden acceder a datos privados sin mediar una orden judicial expresa, pone en duda cualquier plan de externalización de datos. ¿Pueden sus datos, bajo circunstancias especiales, estar sujetos a espionaje industrial?. Quizá sea hora de pensar dos o tres veces qué se pondrá fuera del control de una red privada.
Pablo Albarracín, en América Economía, puntualiza los problemas jurídicos relacionados con la normativa que cada país dicte para la protección de datos, destacando que estos se convierten en un problema de soberanía nacional:

El caso PRISM ha resucitado la preocupación sobre la soberanía de los datos. ¿Los datos que una compañía o gobierno considera estratégicos, deben estar en una nube internacional o en servidores y data centers dentro del territorio nacional? La masiva adopción del cloud, desde el popular Gmail a sofisticadas plataformas empresariales, está provocando una ambigüedad geopolítica de datos en todos los frentes. Dicho de otro modo, Snowden sacudió en la cara de todos los gobiernos y agencias de seguridad del mundo su deficiente soberanía informática.
El tema es más importante de lo que aparenta, puesto que pone en juego la reputación y confiabilidad del cloud como depositorio de los datos críticos, como pueden ser secretos militares, patentes industriales, información de los clientes de un banco o la información clínica de toda una ciudad o región. Una óptima adopción del cloud debería asegurar que los proveedores de la nube garanticen a sus clientes que los datos se alojen en el país de origen."La soberanía de datos se ha convertido en la principal preocupación para los clientes fuera de los EE.UU. que están buscando la adopción de una nube pública", dice el informe de Gartner Data Sovereignty Can Be a Hurdle for the Adoption of Cloud Computing. "Durante los próximos cinco años, los problemas de soberanía de datos disminuirán a medida que más proveedores pongan atención a este asunto. Sin embargo, el problema no va a desaparecer por completo".

De esta manera, tanto el cliente como el proveedor de la tecnología, evitan confusiones relativas a las diferentes normativas legales que cada país posee y que pueden generar problemas al momento de enfrentar un litigio (Google y Microsoft mucho saben de esto a raíz de PRISM). Más aún, cuando la oferta cloud está abarcando no sólo la capa de software (SaaS), sino que los niveles más físicos del cloud también cuentan con una oferta deslocalizada (IaaS, PaaS). La seguridad nacional puede estar en riesgo.
“Los datos no son de Google, los datos son de las empresas. Ellas son las dueñas de los datos y se responsabilizan de la información", dice Gabriela Franchetto, Google Enterprise Sales Manager. "Google se pone a disposición de ustedes (los clientes), pero los datos no son nuestros, sólo la infraestructura que los aloja”. (Conozca más sobre los aspectos legales y técnicos en la adopción del cloud en el reportaje: Leyes del Cloud Computing: ¿está la región preparada para subirse a la nube?)

Según el estudio Data Sovereignty and the Cloud de la University of New South Wales (UNSW) y el Cyberspace Law and Policy Centre, el lugar donde se alojan los datos es una problemática no sólo técnica, sino que legal y estratégica de un país. El tema ha dejado de ser asunto exclusivo de abogados a considerarse un punto importantísimo en gestión de riesgo, empresarial como gubernamental, situación que irá creciendo con los años.

Albarracín destaca la probable acción de Brasil expresada a través de su ministro de Comunicaciones, Paulo Bernardo Silva, de exigir por ley a sus proveedores de servicio de almacenamiento de datos de que éstos sean alojados en el país:

Según informó EFE, el ministro afirmó que el almacenamiento de los datos en el país es un asunto de soberanía nacional debido a que las empresas de internet se están negando a ofrecerle datos a la justicia brasileña con la disculpa de que sus archivos no están en el país. Bernardo se refirió a la reciente negativa de Google de entregar copias de un e-mail a un tribunal que investiga un caso de lavado de dinero. "Con esas denuncias (de Snowden) vimos que ellos (las empresas) entregan todo. Aquí alegan que no pueden hacerlo".
"Creamos incentivos para que los centros de datos se instalasen en Brasil y les suspendimos todos los impuestos sobre la compra de equipos, pero creo que ahora vamos a tener que obligarlos a almacenar los datos aquí". Bernardo señaló que además de obligar a las empresas a archivar sus datos en el país, el gobierno también va a invertir en infraestructura de  redes locales y a promover una reforma en la gestión internacional de internet, para que sea asumida por la ONU y no por Estados Unidos.

"El problema es que la internet tiene reglas de gestión exclusivamente dictadas por Estados Unidos. Defendemos una gestión multilateral y multisectorial. Países y sociedades tienen que estar representados, pero los Estados Unidos se resisten mucho y frenan cualquier intento de discusión sobre el asunto", puntualizó.

La probable exigencia de Brasil de radicar localmente los datos, de todas formas, no hace sino agregar una razón más a las dudas más que razonables de externalizar datos: localizarlos fronteras adentro no cambia el problema, sólo lo sujeta a las particulares exigencias de las agencias nacionales. Es decir: quien piense en externalizar, piense de nuevo. Y no sólo con un abogado, sino con un analista político.

Java legacy, II

A propósito de las afirmaciones sobre la declinación de Java, mayores hacia inicios de año que ahora, Martijn Verburg, en su revista de Java para 2012, se refiere al tema y lo refuta claramente:

The community continues to thrive despite many main stream tech media reports of ‘developers leaving the Java platform’ or ‘Java is dead’. There are more Java User Groups (JUGs) than ever before, consisting of ~400,000 developers world wide.
Notably, one of them, the London Java Community won several awards including the Duke’s Choice award and JCP Member of the Year (along with SouJava – the major Brazilian JUG).
The conference circuit is bursting at the seams with large, sold out in advance, world-class Java conferences such as JFokus, Devoxx and of course JavaOne. In addition to this the host of regional conferences that often pack in an audience of over 1000 people all continued to do well.
Oracle’s Java Magazine was launched and has grown to over 100,000 subscribers. Stalwarts like JaxEnter, Coderanch and the Javaposse continue to grow in audience sizes.

OpenJDK

Further OpenJDK reforms happened over 2012 and a new scorecard is now in place for the wider community to give feedback on governance, openness and transparency.
2012 also saw a record number of individuals and organisations joining OpenJDK. In particular, the port to the ARM processor and support for running Java on graphic cards (Project Sumatra) were highlights this year.

Java Community Process (JCP)

The Java Community Process (JCP), Java’s standards body also continued its revival with record numbers of new sign-ups and a hotly contested election. As well as dealing with the important business of trademarks, IP and licensing for Java, a re-focus on the technical aspects for Java Specification Requests (JSRs) occurred. In particular the new Adopt a JSR programme is being strongly supported by the JCP.

Java and the JVM

The JVM continues to improve rapidly through OpenJDK – the number of Java Enhancement Proposals (JEPs) going into Java 8 is enormous. Jigsaw dropping out was a disappointing but given the lack of broader vendor support and the vast amount of technical work required, it was the correct decision.

JEE / Spring

JEE7 is moving along nicely (and will be out soon), bringing Java developers a standard way to deal with the modern web (JSON, Web Sockets, etc). Of course many developers are already using the SpringSource suite of APIs but it’s good to see advancement in the underlying specs.

Rapid Web Development

Java/JVM based rapid web development frameworks are finally gaining the recognition they deserve. Frameworks like JBoss’s SEAM, Spring Roo, Grails, Play etc all give Java developers parity with the Rails and Django crowd.

Mechanical Sympathy

A major focus of 2012 was on Mechanical Sympathy (as coined by Martin Thompson in his blog). The tide has turned, and we now have to contend with having multi-core machines and virtualised O/S’s. Java developers have had to start thinking about how Java and the JVM interacts with the underlying platform and hardware.
Performance companies like jClarity are building tooling to help developers understand this complex space, but it certainly doesn’t hurt to get those hardware manuals off the shelf again!

Y cuando Martijn se refiere a las perspectivas de 2013, la expectativa persiste, con Java 8 en deliberación. Pero mejor vea el artículo, o siga Java Code Geeks. Al menos en mi caso, encuentro usualmente excelente material práctico con ellos.

Silverlight: Crónica de una muerte anunciada

Tim Anderson,  (¿ex?) entusiasta de Silverlight, informa que el sitio oficial del producto (Silverlight.net), ha desaparecido, y que ahora redirecciona a MSDN. La degradación (en términos militares) del producto queda evidente en que, si a grandes rasgos los contenidos principales fueron migrados, muchos contenidos dependientes y relacionados ahora conducen a enlaces perdidos ("shattered into a million broken urls"). Tim piensa en términos condicionales acerca de lo que Silverlight hubiera podido ser pero no fue. Algunos lectores apuntan otros casos de discontinuidad. Una vez más, para mí esta declinación planificada (¿obsolescencia programada?) refuerza la idea de que el software debe construírse a salvo de los proveedores de productos o plataformas, a nivel de modelo, de tal forma que sea capaz de sobreponerse a las conveniencias ajenas. Dejemos hablar a Tim:

There has been some Twitter chatter about the closure of silverlight.net, Microsoft’s official site for its lightweight .NET client platform. multimedia player and browser plug-in.
I am not sure when it happened, but it is true. Silverlight.net now redirects to a page on MSDN. Some but not all of the content has been migrated to MSDN, but Microsoft has not bothered to redirect the URLs, so most of the links out there to resources and discussions on Silverlight will dump you to the aforementioned generic page.
One of the things this demonstrates is how short-sighted it is to create these mini-sites with their own top-level domain. It illustrates how fractured Microsoft is, with individual teams doing their own thing regardless. Microsoft has dozens of these sites, such as windowsazure.com, windowsphone.com, asp.net, and so on; there is little consistency of style, and when someone decides to fold one of these back to the main site, all the links die.
What about Silverlight though? It was always going to be a struggle against Flash, but Silverlight was a great technical achievement and I see it as client-side .NET done right, lightweight, secure, and powerful. It is easy to find flaws. Microsoft should have retained the cross-platform vision it started with; it should have worked wholeheartedly with the Mono team for Linux-based platforms; it should have retained parity between Windows and Mac; it should never have compromised Silverlight with the COM support that arrived in Silverlight 4.
The reasons for the absence of Silverlight in the Windows Runtime on Windows 8, and in both Metro and desktop environments in Windows RT, are likely political. The ability to run Silverlight apps on Surface RT would enhance the platform, and if COM support were removed, without compromising security.
XAML and .NET in the Windows Runtime is akin to Silverlight, but with enough differences to make porting difficult. There is an argument that supporting Silverlight there would confuse matters, though since Silverlight is still the development platform for Windows Phone 8 it is already confusing. Silverlight is a mature platform and if Microsoft had supported it in the Windows Runtime, we would have had a better set of apps at launch as well as more developer engagement.
I posted that Microsoft’s Silverlight dream is over in October 2010, during Microsoft’s final Professional Developers Conference, which is when the end of Silverlight became obvious. It lives on in Windows Phone, but I would guess that Windows Phone 8.5 or 9.0 will deprecate Silverlight in favour of the Windows Runtime. A shame, though of course it will be supported on the x86 Windows desktop and in x86 Internet Explorer for years to come.