El concepto "Legacy" y la zanahoria "microservice"

 Lo que sigue es un artículo "viejísimo", del 25 de abril de este año. Lo copiaré y comentaré si es necesario, porque sigue siendo de rigurosa actualidad, tanto en el universo de IBM i, como en general:

Beware The Hype Of Modern Tech

Many IBM i shops are under the gun to modernize their applications as part of a digital transformation initiative. If the app is more than 10 or 15 years old and doesn’t use the latest technology and techniques, it’s considered a legacy system that must be torn down and rebuilt according to current code. But there are substantial risks associated with these efforts – not the least of which that the modern method is essentially incompatible with the IBM i architecture as it currently exists. IBM i shops should be careful when evaluating these new directions.

Amy Anderson, a modernization consultant working in IBM’s Rochester, Minnesota, lab, says she was joking last year when she said “every executive says they want to do containerized microservices in the cloud.” If Anderson is thinking about a future in comedy, she might want to rethink her plans, because what she says isn’t a joke; it’s the truth.

Many, if not most, tech executives these days are fully behind the drive to run their systems as containerized microservices in the cloud. They have been told by the analyst firms and the mainstream tech press and the cloud giants that the future of business IT is breaking up monolithic applications into lots of different pieces that communicate through microservices, probably REST. All these little apps will live in containers, likely managed by Kubernetes, enabling them to scale up and down seamlessly on the cloud, likely AWS or Microsoft Azure.

The “containerized microservices in the cloud” mantra has been repeated so often, many just accept it as the gospel truth. Of course that is the future of business tech! they say. How else could we possibly run all these applications? It’s accepted as an article of faith that this is the right approach. Whether a company is running homegrown software or a packaged app, they’re adamant that the old ways must be left behind, and to embrace the glorious future that is containerized microservices running in the cloud.

 The reality is that the supposedly glorious future is today is a pipe dream, at least when it comes to IBM i. Let’s start with Kubernetes, the container orchestration system open sourced by Google in 2014, which is a critical component of running in the “cloud native” way. (...)

While Kubernetes solves one problem – eliminating the complexity inherent in deploying and scaling all the different components that go into a given application – it introduces a lot more complexity to the user. Running a Kubernetes cluster is hard. If you’ve talked to anybody who has tried to do it themselves, you’ll quickly find out that it’s extremely difficult. It requires a whole new set of skills that most IT professionals do not have. The cloud giants, of course, have these folks in droves, but they’re practically non-existent everywhere else.

ISVs are eager to adopt Kubernetes as the new de facto operating system for one very good reason: because it helps them run their applications on the cloud. (...) 

For greenfield development, the cloud can make a lot of sense. Customers can get up and running very quickly on a cloud-based business application, and leave all the muss and fuss of managing hardware to the cloud provider. But there are downsides too, such as no ability to customize the application. For the vendors, the fact that customers cannot customize goes hand in hand with their inability to fall behind on releases. (Surely the vendor passes whatever benefit it receives through collective avoidance of technical debt back to you, dear customer.)

The Kubernetes route makes less sense for established products with an established installed base. It takes quite a bit of work to adapt an existing application to run inside a Docker container and have it managed in a Kubernetes pod. It can be done, but it’s a heavy lift. But when it comes to critical transactional systems, it likely becomes more of a full-blown re-implementation than a simple upgrade. There are no free lunches in IT.

When it comes to IBM i, lots of existing customers who are running their ERP systems on-prem are not ready to move their production business applications to the cloud. Notice what happened when Infor stopped rolling out enhancements for the M3 applications for IBM i customers. Infor wanted these folks to adopt M3 running on X86 servers running in AWS cloud. Many of them balked at this forced re-implementation, and now Infor is rolling out a new offering called CM3 that recognizes that customers want to keep their data on prem in their Db2 for i server.

Other ERP vendors have taken a similar approach to the cloud. SAP wants its Business Suite customers to move to S/4 HANA, which is a containerized, microservice-based ERP running in the cloud. The German ERP giant has committed to supporting on-prem Business Suite customers until 2027, and through 2030 with an extended maintenance agreement. After that, the customers must be on S/4 HANA, which at this point doesn’t run on IBM i.

Will the 1,500-plus customers who have benefited from running SAP on IBM i for the past 30 years be willing to give up their entire legacy and begin anew in the S/4 HANA cloud? It sounds like a risky proposition, especially given the fact that much of the functionality that currently exists in Business Suite has yet to be re-constructed din S/4 HANA. Is this an acceptable risk?

Kubernetes is just part of the problem, but it’s a big one, because at this point IBM i doesn’t support Kubernetes. It’s not even clear what Kubernetes running on IBM i would look like, considering all the virtualization features that already exist in the IBM i and Power platform. (What would become of LPARs, subsystems, and iASPs? How would any of that work?) In any event, the executives in charge of IBM i have told IT Jungle there is no demand for Kubernetes among IBM i customers. But that could change.

Particularmente interesante es el comentario acerca de los planes de Jack Henry & Associates:

Jack Henry & Associates officially unleashed its long-term roadmap earlier this year, but it had been working on the plan for years. The company has been a stalwart of the midrange platform for decades, reliably processing transactions for more than a thousand banks and credit unions running on its RPG-based core banking systems. It is also one of the biggest private cloud providers in the Power Systems arena, as it runs the Power machinery powering (pun intended) hundreds of customer applications.

The future roadmap for Jack Henry is (you guessed it) containerized microservices in the cloud. The company explains that it doesn’t make sense to develop and maintain about 100 duplicate business functions across four separate products, and so it will slowly replace those redundant components that today make up its monolithic packages like Silverlake with smaller, bite-sized components that run in the cloud-native fashion on Kubernetes and connect and communicate via microservices.

It’s not a bad plan, if you’ve been listening to the IT analysts and the press for the past five years. Jack Henry is doing exactly what they’ve been espousing as the modern method. But how does it mesh with its current legacy? The reality is that none of Jack Henry’s future software will be able to run on IBM i. Db2 for i is not even one of the long-term options for a database; instead it selected PostgreSQL, SQL Server, and MongoDB (depending on which cloud the customer is running in).

Jack Henry executives acknowledge that there’s not much overlap between its roadmap and the IBM i roadmap at this point in time. But they say that they’re moving slowly and won’t have all of the 100 or so business functions fully converted into containerized microservices for 15 years – and then it will likely take another 15 years to get everybody moved over. So it’s not a pressing issue at the moment.

Maybe Kubernetes will run on IBM i by then? Maybe there will be something new and different that eliminates the technological mismatch? Who knows?

The IBM i system is a known entity, with known strengths and weaknesses. Containerized microservices in the cloud is an unknown entity, and its strengths and weaknesses are still being determined. While containerized microservices running in the cloud may ultimately win out as the superior platform for business IT, that hasn’t been decided yet.

For the past 30 years, the mainstream IT world has leapt from one shiny object to the next, convinced that it will be The Next Big Thing. (TPM, the founder of this publication and its co-editor with me, has a whole different life as a journalist and analyst chasing this, called The Next Platform, not surprisingly.) Over the same period, the IBM i platform has continued more or less on the same path, with the same core architecture, running the same types of applications in the same reliable, secure manner.

The more hype is lavished upon containerized microservices in the cloud, the more it looks like just the latest shiny object, which will inevitably be replaced by the next shiny object. Meanwhile, the IBM i server will just keep ticking.

 Sin duda han habido cambios espectaculares en unos pocos años, los últimos cuatro o cinco, y existen herramientas y recursos disponbiles de gran potencia. Pero para una empresa o institucion en marcha, un cambio tiene que ser pesado con cuidado, evitando el riesgo de caer en el vacío. ¿Un cambio que requiere nuevas metodologías, nuevos lenguajes, nuevas platatformas, nuevas comunicaciones? ¿desarrollos con lo último de lo último, sin contar con la prueba de recursos robustos y experimentados por varios años?

Elemental, Watson

 Leyendo publicaciones técnicas hoy, tan pronto como levantan la vista al nivel de arquitectura, parecería que lo único que existe es una arquitectura basada en microservicios, y lo demás es monolitico y repudiable (o peyorativamente, simplemente monolitos de la prehistoria). Dice Atul Mittal, en Medium:

Is it always necessary to have Microservice Architecture instead of Monolithic Architecture?

The answer is NO, BIG NO. You should very understand the efforts and the value your product brings in. Generally, at first, implementing Microservice Architecture is a very tedious task, you need to have a separate Team/Architecture for each component that you need to have in your Application and a lot of thought process goes into that which might not be a viable option for small companies or Application built in very less budget, so there comes a saviour way to create Applications in “Monolithic” fashion or you can also say “traditional” way of creating Applications. If there are not so many components in that case also, you can think to adopt a “Monolithic’ way of doing things. But keep in mind, to modularize your application as much as possible so that later in case you want to redesign it in a “Microservice” way you don’t face many challenges in doing so.

Segunda ola de modernización en el System i

En tiempos de grandes reacomodamientos, el System i no está ajeno a esto, salvo que aceptara caer en la intrascendencia. Tras la ola de iniciales inclusiones, ahora el objetivo es mobile, escuchando a los clientes, como el artículo enlazado comenta (IBM i Fundamental Strategy Unchanged, Always Changing, Dan Burger). 

Hace ya mucho tiempo que IBM no es el motor de los cambios y tendencias tecnológicas. Aunque se debería decir mejor todavía, que el curso de los acontecimientos escapa actualmente a la voluntad de casi todos sus actores, y evolucionan (los acontecimientos) más rápidamente que la capacidad industrial de las compañías tecnológicas de marchar a su paso o adelantarse. Y sin duda este es el caso de IBM: recursos finitos de investigación, y tiempos de investigación y  desarrollo que quedan desactualizados por los acontecimientos.
Pero hay algo más...¿hasta qué punto la adopción de las nuevas tecnologías acompaña su surgimiento? ¿cuánto de lo que vemos como posibilidad es realidad?  ¿Cuántas empresas nacionales están al día, cuántas modificaron sus procesos a fondo? Probablemente se podríadecir que casi ninguna, o ninguna...lo que tenemos es una capa superior (¿o superficial?) de un puñado de aplicaciones modernas, apoyadas en una combinación, o mezcla, infernal de aplicaciones de las más variadas épocas y tecnologías. Y que a la hora de hacer una compra por el móvil, el logro de esa transacción depende de una cadena de sucesos originados por procesos de la generación anterior, o de dos , o de tres generaciones anteriores...
¿Dinosaurios? probablemente no; simplemente los tiempos del ciclo de vida de una institución (empresa final, compañia de software, la que sea) siguen un ritmo distinto a la acumulación actual de nuevas posibilidades.
Y así, el System i no escapa a esto, por su propio tipo de función.
Nota: Quizá el título de esta nota no es el adecuado. Probablemente mejor sería decir "modernización y realidad".

ERPs en el huracán

Insensiblemente, cada día, cada semana, cada año, estamos viendo conformarse cambios en el alcance de la tecnología informática, las comunicaciones y el manejo del conocimiento que marchan hacia un modelo que parece integrar todo con todo. Están quedando desactualizados todos los conceptos que por cuarenta años han regido cada disciplina vinculada al manejo de la información, y probablemente la mejor actitud ante esto sea mantenerse abiertos y atentos a las tendencias. Si la tecnología móvil incorporó en menos de una decena de años varios miles de millones de usuarios, el ya casi con nosotros Internet de las cosas promete romper todas las barreras y escenarios en que comunicación, tecnología y conocimiento aparecen asociados. Esta totalmente masiva apertura ha dejado en un terreno irrelevante la discusión por sistemas operativos, lenguajes, técnicas, recursos, y áreas de enfoque. Hoy nuestra pregunta sería: ¿qué podemos hacer, hasta donde podemos llegar?
 En el marco de estas fuertes transformaciones del manejo de la información, los llamados ERP también están siendo alcanzados: Tras haber alcanzado ayer nomás un estatus de emperadores reinantes en el mundo empresario, los actuales cambios los están recortando a jirones, ante nuevas necesidades y nuevas velocidades de respuesta. Los actuales ERPs sin duda son capaces de atender el ciclo central de grandes áreas de negocio, quizá especialmente en el mundo de las manufacturas y en el contable, pero su capacidad de flexibilizarse ante nuevas exigencias es muy baja.
Sirva esto de introducción al excelente artículo de Alex Woodie sobre este punto: Six Signs Of The Long, Slow Decline Of  ERP. Woodie habla de "declinación de los ERPs", no sólo desde el punto de vista de la empresa usuaria, sino también desde el propio interés del fabricante del software. Así, menciona seis signos de esta declinación:

• El costo de las licencias, por resistencia de los usuarios, y por la creciente competencia de otras alternativas, especialmente desde la nube
• La propia migración hacia la nube
• Los interminables costos de sucesivos proyectos.
• Las escasas novedades incorporadas (se puede decir que cada área ocupada por un tipo de ERP deviene un commodity).
• El movimiento del enfoque hacia nichos más lucrativos (léase Big Data).
• ...y la deconstrucción de las suites, especialmente debido a la aparición de nuevas soluciones enfocadas en áreas específicas.

 Woodie mide el impacto de la declinación del uso de ERPs en el área de su interés, los equipos de rango medio, particularmente el IBM i (AS/400 en un pasado remoto), suponiendo que una disminución de la importancia de este software traerá una caída paralela de los equipos en que este software se ejecuta. Me permito dudar de esta correlación: el universo del manejo de la información no se ha simplificado, sino todo lo contrario, y difícilmente una empresa delegará todo su patrimonio a ninguna nube, salvo que sea propia.
Hay que pensar todo de nuevo...

Nuevas capacidades del System i (AKA AS400)

Se llame System i, AS400, o cualquier otro nombre intermedio, el i no es un equipo estancado, sino todo lo contrario: robusto como siempre, y evolucionado al paso de las tecnologías. Como un breve recordatorio, Alex Woodie, en The Four Hundered, enumera las nuevas características sumadas entre 2014 y 2015:

1. Native Flash Storage

IBM added support for native flash storage in the latest round of technology refreshes, which were IBM i 7.1 TR 10 and i 7.2 TR 2. This enables native use of solid state drives (SSDs) based on flash technology.

Prior to this, getting flash storage running on an IBM i-based Power Systems server was accomplished by way of the Virtual I/O Server (VIOS). Not all IBM i shops are thrilled with VIOS, which is an AIX program and can muddy the troubleshooting of performance issues. Thanks to VIOS and the overall adoption of virtualization in the IT world, there are rumblings from the natives that we've gotten too far away from the data.

But thanks to native support for flash, IBM i shops can now benefit from the ridiculous performance boost that NAND technology can deliver, especially for busy IBM i applications that are I/O bound with traditional DASD. And it can do so without going down the VIOS/AIX rabbit hole, which still looks intimidating to smaller shops.

2. Row and Column Access Control

This security feature was added with the release of IBM i 7.2 in 2014 to prevent unauthorized users from accessing huge swaths of data. As IBM's DB2 for i guru Mike Cain explains, RCAC was added at the request of IBM i customers to protect sensitive data.

"Prior to RCAC, the security scheme was provided through the object-based security measure," Cain says in this video on the RCAC Redbook landing page. "This really means that someone. . . could get access to all of the rows or records, or they would have no access to the row or file."

Since there was no prior way for DB2 for i to subset the record access--absent defining it at the application level, which leaves the data vulnerable still to ODBC/JDBC--IBM built it, and that's RCAC. "DB2 for RCAC provides a new and robust solution that allows for the governance and control of data through all interfaces, whether those interfaces are SQL or whether they're native record-level access," Cain says.

Simply put: If you need to dole out data based on a user's specific role and don't want to completely rebuild your database schema to prevent snooping, then you need RCAC, which means you need IBM i 7.2.

3. JSON

IBM added a technology preview for JavaScript Object Notation (JSON) in IBM i 7.2 TR2 and IBM i 7.1 TR10, which shipped in the spring.

JSON is a lightweight, human-readable data format that's become the default way that Web applications store and share data. Compared to XML--which 10 years ago paved the way toward self-definable data--JSON is both easier for programmers to use and faster to load.

Considering the rising adoption of JavaScript frameworks like Dojo, Ext JS, and jQuery among IBM i developers for front-end Web development, it was a natural for IBM i to add support for JSON in the database. (While JavaScript doesn't require JSON, there are advantages to using them in combination.)

The JSON Store Technology Preview that IBM shipped with the latest TRs allow JSON documents to be stored and retrieved using DB2 for i database tables. For a good primer on the three ways developers can utilize JSON, check out this recent developerWorks article.

4. Node.js

IBM unveiled support for last October with IBM i 7.1 TR9 and IBM i 7.2 TR1.

You're probably aware of how JavaScript can accelerate development of Web clients. The frameworks mentioned above bring a host of out-of-the-box UI widgets that developers can easily drop into their development environment. What Node.js does is extend that ease-of-use to the server. Node.js (or simply "Node" to those in the know) is an open-source runtime environment for server-side applications written in JavaScript. The framework has been widely adopted because it takes much of the complexity out of building and running scalable, data-intensive Web applications.

The addition of Node.js is a good example of IBM reacting to changing trends in application development (the addition of support for Ruby is another example). To learn more about Node.js, check out Aaron Bartell's LinkedIn story about his first experience with the framework.

5. REST Web Services

IBM's support for Representational State Transfer (REST) Web services, which IBM shipped in December with the group PTFs for IBM i 7.1 TR9 and IBM i 7.2 TR1, can be grouped into the same vein as JSON and Node.js: Keeping the platform relevant to a new class of developers and a new programing style.

If JSON has become the defacto data integration standard on the Web (largely replacing XML), then REST has become the defacto program integration standard for Web-based applications--largely replacing the XML-based service oriented application protocol (SOAP) that came before it.

If you want to connect your IBM i app so it can talk to hosted cloud service, such as Salesforce or Netsuite, you're going to be doing it via REST. IBM i developers who want to keep their apps current would do well to adopt REST, not only to partake of the rich ecosystem of REST-enabled services that are already out there, but to contribute back to it too.

Como se ha dicho otras veces, el problema no es el 400, sino la apertura de ideas de quienes toman decisiones sobre su uso. Usado como servidor, suele quedar atado al criterio más bien conservador en el manejo de la lógica de negocios escrita en los servidores.

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.

Futuro del 400..(o como se llame en 2020)

Linea de tiempo planificada para el System i - (En IBM System Magazine)

Steve Will, Arquitecto Jefe del System i,  publica en IBM System Magazine (30 de marzo) un artículo explicando la planificación de futuras versiones del System i (AKA AS400, i Series, System i...), que extiende el ciclo de vida de los sistemas hasta dos próximas versiones como planes inmediatos, llevando su ciclo de vida hasta más allá de 2025: la corriente versión aparece planeada hasta 2020/2021, y confirma que están trabajando en dos siguientes versiones (Next i+1/Next i+2). La primera, con cambios que expanden características ya en desarrollo, y la siguiente, determinada por cambios mayores no contenibles en la primera.

(...) we have two major releases under development right now. The 7.2 release came out less than a year ago, and we’ve been working hard on its following major release – called “i next” on this chart. But, we have items that we know cannot fit into “i next” but which require a major release, so we are working on the one after that, “i next +1.” 

 Lo más importante del artículo de Will es la indicación del compromiso de IBM con el sistema, y de su potenciación en el marco de la evolución tecnológica actual:

The key to understanding this next chart is to recognize when there is a known, committed date and when there is just a direction. A known date is represented when the horizontal line has a vertical end. For example, IBM i 6.1 was released in 2008, and its announced end of service is in 2015; both ends of that line are vertical. But while IBM i 7.2 came out in 2014 (vertical left end) the end of service date is indicated by an arrow, meaning we have not announced anything.

However, if 7.1 and 7.2 are each supported as long as 6.1 and V5R4 were, then 7.2 is going to be supported out into the 2020s.

And, very importantly, I told you that we have two more releases actively under development right now. When will they be released? Well, the ends of those lines are arrows, so we’re not saying yet. The availability dates could still change, but clearly, we don’t tend to deliver new releases any sooner than two years these days, and sometimes it’s longer than that. So, “i next” and “i next +1” will come out sometime, and if they also are supported for seven years, well, we’re more than 10 years out into the future now.

Furthermore, on the previous chart, we discussed that new capabilities are coming out in between releases. This means that the “Support” chart does not indicate only “support” but also a timeline for delivery of new function via TRs.

 Frente a la socarrona afirmación (repetida frecuentemente) de la obsolescencia del equipo, creo que realmente tendríamos que pensar más en la obsolescencia de las perspectivas con que se planean desarrollos sobre la plataforma: cada vez me siento más inclinado a abandonar definitivamente cualquier referencia al "400", considerando la distancia entre aquello que estaba disponible en el 400 hace veinte años, y lo que es posible hacer hoy en el "i":

We’re adding new capabilities in virtualization, cloud, I/O, DB2, mobile, open standards and much more. Staying current with new technology is a clear indication we are investing and plan to be around for a long time.

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.

.NET 4, end-of-service...

En el mismo artículo de Ed Bott mencionado antes, también se adelanta la finalización de soporte de el framework .NET 4, 4.5, 4.5.1 y 4.5.2 a partir de enero de 2016:

We will continue to fully support .NET 4, 4.5, 4.5.1, and 4.5.2 until January 12, 2016, this includes security updates as well as non-security technical support and hotfixes. Beginning January 12, 2016 only .NET Framework 4.5.2 will continue receiving technical support and security updates. There is no change to the support timelines for any other .NET Framework version, including .NET 3.5 SP1, which will continue to be supported for the duration of the operating system lifecycle.

La nota semioficial de Microsoft se puede leer en el blog .NET Framework. Por si no lo había notado:

The quick pace at which we’re evolving and shipping means the latest fixes, features, and innovations are available in the latest version and not in legacy versions. To that end, we are making it easier than ever before for customers to stay current on the .NET Framework 4.x family of products with highly compatible, in-place updates for the .NET 4.x family.

Internet Explorer, End-Of-Service

Tomado de The Ed Bott Report: Microsoft anunció este 7 de Agosto, cambios importantes en su política de soporte y actualización de sus versiones de Internet Explorer: a partir del 12 de enero de 2016, no habrá más soporte ni actualizaciones para IE 8, en cualquier versión (escritorio o servidor). Ni qué decir de versiones previas, aunque todos los días tenga noticias de copias de versiones anteriores.
Pero los cambios y finales de servicio también afectan a las versiones 9 y 10 de IE, limitados hasta su cese de soporte a versiones cercanas al fin de servicio también: Windows Vista o Windows Server 2008 y 2012, según una tabla algo dislocada, que debe revisar quien tenga compromisos con IE. En fin, la única versión con soporte asegurado en este momento es IE 11, en aquellas versiones de Windows que lo puedan soportar: Windows 7 y 8, Windows server 2008 y 2012, en sus R2. Un poco atravesado, pero coherente con el curso transicional en que se encuentra Microsoft. Pero además, IE 11 tiene sus particularidades: está funcionando la versión 11 como tal? Al menos en mi experiencia, internamente está funcionando en modo de compatibilidad con IE 8; y el mismo aviso de Microsoft de este pasado día 7, recomienda usarlo en modo Empresa (Enterprise mode, disponible desde abril de este año):

"Enterprise Mode…offers enhanced backward compatibility and enables you to run many legacy web apps during your transition to modern web standards. 
Today we are announcing that Enterprise Mode will be supported through the duration of the operating system lifecycle, to help customers extend their existing web app investments while staying current on the latest version of Internet Explorer. On Windows 7, Enterprise Mode will be supported through January 14, 2020. Microsoft will continue to improve Enterprise Mode backward compatibility, and to invest in tools and other resources to help customers upgrade and stay up-to-date on the latest version of Internet Explorer."

Pero, repito, al menos en mi experiencia, IE 11 funciona mejor en modo compatibilidad, que como IE 11. Llevo semanas tratando de testearlo en modo Edge, y recolectando problemas...hasta que concluímos que será mejor usarlo tal como está, en compatibilidad con una versión anterior, sea la 8, en mis casos recolectados, o en modo Enterprise, como recomienda Microsoft (aún no veo esta opción de emulación en mi instalación).
Concluyendo, sume a su calendario de actualizaciones de Microsoft, los cambios en marcha en IE. Revise sus aplicaciones, y mida el impacto sobre sus paquetes de Office, si los tiene (y sospecho que si usa IE, es porque usa Office).

¿Se debería actualizar? Por muchas razones, seguramente; valga la recomendación de Microsoft:

Developers benefit when users stay current on the latest Web browser. Older browsers may not support modern Web standards, so browser fragmentation is a problem for Web site developers. Web app developers, too, can work more efficiently and create better products and product roadmaps if their customers are using modern browsers. Upgrading benefits the developer ecosystem.

Users also benefit from a modern browser that enables the latest digital work and life experiences while decreasing online risks. Internet Explorer 11, our latest modern browser, delivers many benefits:

• Improved Security – Outdated browsers represent a major challenge in keeping the Web ecosystem safer and more secure, as modern Web browsers have better security protection. Internet Explorer 11 includes features like Enhanced Protected Mode to help keep customers safer. Microsoft proactively fixes many potential vulnerabilities in Internet Explorer, and our work to help protect customers is delivering results: According to NSS Labs, protection against malicious software increased from 69% on Internet Explorer 8 in 2009 to over 99% on Internet Explorer 11. It should come as no surprise that the most recent, fully-patched version of Internet Explorer is more secure than older versions.
• Productivity – The latest Internet Explorer is faster, supports more modern Web standards, and has better compatibility with existing Web apps. Users benefit by being able to run today’s Web sites and services, such as Office 365, alongside legacy Web apps.
• Unlock the future — Upgrading and staying current on the latest version of Internet Explorer can ease the migration to Windows 8.1 Update and the latest Windows tablets and other devices, unlocking the next generation of technology and productivity.

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.

El objeto CDO y Office: ¿obsolescencia programada?

 Revisando algún otro asunto (algún fallo ajeno en el uso de MAPI), topé con un anuncio que en particular nos afecta en más de una instalación; digamos que en general puede afectar a cualquier usuario de Plex, pero supongo que su alcance es más amplio, más allá de la estrategia propia de Plex, para cualquier instalación basada en mensajería de Microsoft. El anuncio tampoco es nuevo: refiere a Office 2010: Collaboration Data Objects (CDO) 1.2.1 no es soportado con Outlook 2010 y versiones posteriores. CDO es una librería basada en el modelo COM de Microsoft, accesible por medio de C, C++, VBA, VB, C#, usada ampliamente para el envío de mensajería en sistemas Windows. En el mismo sitio del anuncio CDO es definido como  a client library that provides a thin wrapper over Extended MAPI functionality. This library is typically used to add email messaging functionality to custom programs. This library allows those programs to perform functions such as sending email through MAPI, working with calendars, and accessing various data in Microsoft Outlook or in Microsoft Exchange.

Posiblemente el API de MAPI haya sido intermediado por el uso de CDO ampliamente desde su aparición; bien definido, bien documentado, consistente, capaz de ser invocado desde casi todos los lenguajes ejecutables en Windows, y particularmente desde las propias implementaciones de Microsoft para el lenguaje de propósito especial de Office (VBA).
Sin embargo, a partir de Office 2010, nos encontramos que CDO no es instalado, y es desaconsejado su uso para interactuar con Office a partir de esta versión, debido a cambios de arquitectura en la suite de oficina:  

Microsoft Outlook 2010 and later versions include many architectural changes to the client-side MAPI subsystem. Of particular concern are scenarios in which Outlook is configured to use multiple Exchange accounts. Also, CDO 1.2.1 is a 32-bit client library and will not operate with 64-bit versions of Outlook. Given all these factors, CDO 1.2.1 is not supported for use with Outlook 2010 or Outlook 2013, and we do not recommend its use with Outlook 2010 and later versions.

¿Podemos considerar esta decisión una violación de los principios de arquitectura del modelo COM? Una vez más, el concepto de compatibilidad y continuidad del soporte de Microsoft opta por la vía rápida: se elimina su instalación, se ralea la información y documentación a partir de ahora "legacy", y se recomienda calurosamente el cambio a la nueva versión. Microsoft tiene una solución a su patrimonio de funciones construidas usando CDO:

Programs that use CDO should be re-designed to use other Application Programming Interfaces (APIs) instead of CDO (...) Developers should use the Outlook 2010 and later object model instead of CDO 1.2.1. Also, developers can still use Extended MAPI (which requires unmanaged C++) in some scenarios where CDO was required. However, if it is possible, we generally recommend that the Outlook object model be used instead of Extended MAPI. Microsoft product support can help developer customers migrate custom programs from using CDO 1.2.1 to using other APIs. However, Microsoft will not provide support for any scenarios in which CDO 1.2.1 is used with Outlook 2010 or Outlook 2013. 

Simple, entonces: busque todos los casos en que usara CDO, y rediseñelos para usar el modelo de objeto Office. Justo cuando Microsoft está en transición entre Win32 y WinRT, para descubrir que dentro de un par de años WinRt determina otro modelo de objeto, y, sin más trámite, todo su patrimonio sea discontinuado de nuevo.
Sin duda usted podrá seguir usando CDO, en un marco limitado, recurriendo a modificaciones de la instalación, a condición de cómo administre su instalación de Exchange (vea el punto More information en la página del anuncio de Microsoft). Pero no será soportado, y cada día encontrará menos documentación para arreglárselas por su cuenta. Si lo va a seguir utilizando, tome una medida de precaución: conserve como documento off line todo lo que pueda conseguir todavía de guía de referencia y soporte de Microsoft. Como en muchos casos, pronto encontrará que las (escasas) referencias que se conserven, lo conducirán a páginas muertas. ¿CDO funciona? digamos que sí. Lo que ha cambiado es Office, y la compatibilidad hacia atrás parece que es secundaria: cambie de modelo de API. La mejor explicación acerca de las razones del conflicto de versiones la he encontrado en lo analizado por Matt Stehle, en los MSDN blogs. Matt apunta a la existencia de dos modelos de manejo de memoria: el de MAPI/CDO, y el de .NET, que pueden producir intermitentes problemas de asignación de memoria:

MAPI has its own memory management model that conflicts with and is incompatible with the .NET runtime. This the primary reason that MAPI and CDO 1.21 are not supported running in a .NET process. The common symptoms you will see are seemingly random Access Violations and very often memory leaks (especially with CDO 1.21). There is no methodology for avoiding or managing these symptoms by using interop libraries or managing references in a particular fashion in your .NET code – it just won't work.
The trap is that CDO 1.21 and .NET can "appear" to work and you can get pretty far in your dev cycle before you run into problems. Many times we see this come up in soon after a solution is released to production, in late cycle performance testing, or in a pilot program. Opening a critical case with Microsoft when you have end users complaining of crashes or project managers short on budget is not a good time to find out that your solution is unsupportable.

Matt se extiende sobre el alcance de éste conflicto, reconociendo que realmente sólo a partir de Office 2007 existen mejores reemplazos de CDO, y que por lo demás, ambos serán excluyentes (The simple answer is you either need to not use .NET or not use MAPI or CDO 1.21). Puede leer la nota completa de Matt en su blog. No se arrepentirá, especialmente si sigue la acotación que apunta Matt a lo que Patrick Reehan dice acerca de qué significa "no soportado" para Microsoft.

En nuestro caso, el impacto sería reducido (por otra parte en ningún caso los servidores de Exchange han provocado conflictos todavía), porque CDO/MAPI están sumamente encapsulados, y no conviven procesos .NET con CDO. Todo nuestro manejo de mensajería pasa por un solo objeto, y las interfases entre un modelo y este objeto son exclusivamente de datos, sin ningún condicionamiento técnico. Bastará con redefinir las actuales llamadas, adecuándolas a los nuevos requerimientos, y recompilarlo y distribuirlo. No hará falta tocar nada más. ¿Pero esto es así en todos los casos? seguramente no, y probablemente en muchas empresas habrá (o hubo) trabajo inesperado.

A propósito de una API de c++

Hace algunos días me pidieron que estudiara alguna manera de validar que una fotografía cumplía con ciertos requisitos de densidad y medida en pixeles: un requerimiento simple, que exige acceder a metadatos de la imagen. Desde el punto de vista de nuestros modelos de Plex, esto significa usar un API, ya que no existen dentro del conjunto de funciones propias del producto, ni tampoco en ninguno de sus patrones de tecnología, alguna función preelaborada que permita obtener esa información.
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para  .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.

Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...

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.

RPG antes y ahora

Este año se cumplieron veinticinco años de la aparición del As400/iSeries/System i o cualquier otro nombre que se propongan agregarle. De su robustez y excelente diseño dan testimonio dos artículos recientes: uno dedicado a recordar sus primeros ensayos y nacimiento, y otro evaluando el estado actual del RPG como lenguaje moderno. El primero, escrito por Mel Beckman, recuerda su inicio como programador, participando en beta tests del equipo en una empresa cercana a Rochester. Sólo rescato dos párrafos:

Despite the plethora of early bugs, we RPG programmers quickly began to see their frequency decreasing as the S/38 OS, called CPF (Control Program Facility) stabilized. S/38’s single-level store, object-oriented architecture, and integrated database really did seem to make programs more reliable, heading off the most common coding gaffs and preventing wholesale machine crashes. As the S/38 matured, it gained a reputation for solid reliability in the finance and healthcare industries, which are still strong markets for the system’s descendent, today’s IBM i. Throughout the S/38’s evolution to AS/400, iSeries, and ultimately Power hardware architectures, IBM has been able to preserve customer’s investment in business logic and data storage.
I had no idea then just how powerful the S/38’s innovations would turn out to be. They enabled IBM, and its many customers, to transport an immense amount of binary code and data into the future – not just twenty-five years, but thirty years, with very few disruptions. IBM promised, with both the S/38 and the IBM i, to protect users’ business investment in applications, processes, and logic.
In the intervening decades, many other systems have come and gone, dragging their user populations into oblivion with them. Only IBM i has preserved a continuous architectural path that is still going strong today. In 2013 it’s clear that IBM alone kept it’s promise.

El segundo artículo es un editorial del IBM System Magazine, escrito a propósito de las celebraciones de los 25 años del equipo (sistema operativo + recursos + hardware), puntualiza el estado actual del RPG, que de ninguna manera es ya lo que inicialmente fue (generador de reportes):

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.
While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.
In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.
If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.
Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.
Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.
Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

Como los autores dicen, mientras hemos visto pasar y desaparece equipos, lenguajes y arquitecturas, el diseño conceptual del AS400 sigue vigente y en primera línea. Centenares de miles de instalaciones lo demuestran. Quizá aún a pesar de algún directivo de la propia IBM, que a veces parece dudar de su producto.

¿Java Legacy?

Esta es una noticia "vieja": InfoQ comenta la migración de Twitter de Ruby a Java a propósito de la exitosa travesía de Twitter durante las elecciones estadounidenses. Twitter resistió 327.452 tweets por minuto, hasta 15.107 tweets por segundo en algunos momentos, sin caídas de proceso ni congestionamientos. InfoQ atribuye (en parte) esta mejora a la migración desde Ruby hacia java:

[ dice Mazen Rawashdeh, VP de Infrastructure Operations Engineering en Twitter]Part of the reason Twitter was able to sustain this level of traffic was down to a set of changes the company has been making to their infrastructure, including, as InfoQ previously reported, a gradual shift away from Ruby to a set of services written in a mixture of Java and Scala and running on the JVM.

InfoQ historia este proceso gradual de migración:

Twitter was at one time thought to be the largest Ruby on Rails shop in the world, and has made a substantial investment in its Ruby stack, going as far as developing its own generational garbage collector for Ruby called Kiji, which, unlike the standard Ruby collector, divides objects into generations and, on most cycles, will place only the objects of a subset of generations into the initial white (condemned) set.
In 2010, however the firm announced that it was shifting some of its development focus. For the front-end the firm followed the HTML5 trend of shifting rendering code into browser-based JavaScript, and, in so doing, it ceased to gain much benefit from Rails' templating model for building web pages. Then, citing both performance and code-encapsulation as drivers, the engineering team re-wrote both its back-end message queue and tweet storage engine in Scala.

 Respecto a los clientes móviles, Rawashdeh dice: As part of our ongoing migration away from Ruby we've reconfigured the service so traffic from our mobile clients hits the Java Virtual Machine (JVM) stack, avoiding the Ruby stack altogether.

Respecto a su motor de búsqueda, también el cambio se inclinó por java: in 2011 the engineering team announced that they had replaced the Ruby on Rails front-end for search with a Java server they called Blender. This resulted in a 3x drop in search latencies.

En años anteriores se comenzó a hablar de Java como un lenguaje legacy, y de su toma por parte de Oracle, como su sentencia de muerte. Sin embargo, ha corrido agua, y la muerte no se produce: Java 7 en marcha, y preparativos para Java 8. En mi experiencia personal, con un uso más extenso de Java, observo estabilidad, confiabilidad, y buena performace. Cada vez que he tenido problemas con la JVM se ha debido a fallos en la preparación de funciones, y he podido contar con buena ayuda de la  consola de java en primer lugar, y de la documentación y la buena capacidad de manejo de errores. Tanto como soporte servidor, como en funciones cliente, la respuesta ha sido normal. Como máquina servidora para aplicaciones web basados en HTML + Javascript, su servicio es transparente y robusto. Y esto, sin contar con su ubicuidad: en cierto modo, "multiplataforma" en mi caso implica Java. En fin, mi experiencia es coincidente con esto dicho en InfoQ.

Buena presentación sobre MDE

Jordi Cabot publica hoy en Slideshare una muy interesante presentación sobre MDE/MDD, que, si bien hace una introducción general al tema, le dedica lo fundamental a las líneas de investigación y a los puntos problemáticos para lo que define como versión 2.0 de MDE. Dentro de las líneas de trabajo presente y futuro dos aspectos que veo particularmente interesantes son la actividad relacionada con  ingeniería reversa dirigida por modelos (mención especial de MoDisco), y el  manejo de muy grandes modelos, que parece ser un asunto de difícil solución en el marco de las premisas actuales de MDE/MDD.
La presentación es suficientemente detallada y amplia como para que pueda despertar la inquietud de aquellos que todavía dudan del valor de MDD/MDE, y más aún para quienes ya están embarcados en alguna forma de desarrollo basado en modelos. El camino es ancho y abierto...
No lo voy a reproducir: cualquiera puede ver la presentación en Slideshare.

Otro enfoque crítico sobre Windows 8

A las diversas razones que exponen distintos analistas acerca de los problemas críticos que podría experimentar Windows 8, Tim Worstall agrega otro: Windows Metro exige que los viejos usuarios de Windows deban aprender una nueva manera de relacionarse con su sistema operativo. Si se debe aprender algo nuevo, pudiera ser que se optara por algo con un costo menor o directamente gratuito:

Yes, it looks like a good enough tablet operating system. And it’s also quite fine as a desktop operating system. But there’s a problem with the way in which every user now has to learn to use the operating system all over again. And what should worry Redmond a great deal more than some journo like me remarking upon this is the way that at least one fund manager has sold his stock in the company as a result of his confusion over their plans.
(...) The essential point is that at the heart of the Microsoft value equation is their near lock on desktop operating systems.
Even if we all stopped writing new code for Windows (as, to some extent is true, we have done, much writing is now being done in Python and so on which is not platform or OS specific) right now then there are vast numbers of legacy systems out there that will continue to require Windows licenses for decades to come.

But Windows 8 asks everyone to relearn how they interact with a computer. Yes, there’s still that legacy systems tailwind helping the company. But if everyone now has to learn a new OS then why would everyone learn the new Windows? The very change they’re bringing in means that people will be open to changing to a non-Windows platform.

I could argue this from an entirely personal perspective. Sure, I use a computer as the essential tool for making my daily bread and butter. I use Windows simply because that’s what every cheap computer on the market comes pre-loaded with. Plus I’ve near 20 years experience of using one form of Windows or another (no, really, I had Windows 1.0 at one point). But I don’t actually use “Windows” if you see what I mean. I use something that opens a word processor, I use something that will allow a browser to run. And that really is about it. I’m sure my experience of computing is similar to the vast majority of people out there too. We’re no more interested in which OS we use than which spark plugs are in our car’s engine. As long as it works then we’re happy.

Which is the danger of presenting us with an entirely new way (the Metro interface which pretty much insists that you access as if you’re on a tablet) of interacting with the computer. If we’ve got to learn all this new stuff well, why not go off and use some other OS that doesn’t force us to do so? Or one that we don’t have to pay for?

It’s entirely possible even that Metro, the tablet interface, really is a better and more intuitive method of interfacing with a computer. But who cares? Maybe changing where the pedals on a car are is a really good idea too. But can you imagine trying to bring in such a change while still keeping your market share?

 Windows 8 consiste en una paradoja: En su mercado consolidado, el escritorio, Windows 8 no solo no agregará más nada sustancial (Win32), sino que lo considerará "legacy", con todo lo que ello implica. Y sus novedades, su nueva visión (WinRT), las pondrá en un mercado, el móvil, en el que  tiene un peso prácticamente nulo, y donde debe hacerse un lugar entre dos grandes competidores. Una apuesta al filo de la navaja.

¿Windows 8 en el filo de una navaja?

Por primera vez, leo en un comentarista la posibilidad de que Windows 8 pudiera convertirse en una falla catastrófica de Microsoft. En realidad, una relectura de la gran cantidad de información publicada en los últimos días muestra signos no muy tranquilizadores. El más reciente, la campaña algo acuciante en busca de desarrolladores y empresas que soporten Metro y Windows Phone 7 y 8, en sus aplicaciones y lenguajes, y la continuada ratificación de la limitación o extinción de soporte de .NET y Silverlight, respectivamente. Por largo tiempo, se percibía que la irrupción masiva de dispositivos móviles representaba una amenaza cierta a la hegemonía de mercado de Microsoft. Si Metro era la respuesta de la empresa a este desafío, hoy da la impresión de que pudiera ser un fiasco mayor, que comprometa su posición en todos los frentes. Pareciera que fue lanzado sin abrir suficientemente su arquitectura a proveedores y socios de negocios, de tal forma que hoy pudiera no contar con suficientemente respaldo de quienes deberían soportarlo. Así sucede aparentemente en el mercado de ARM. Dice Patrick Moorhead en Forbes:

As we head toward the availability of Windows 8 in Q4, the amount of information available about X86-based platforms dwarfs that of ARM-based platforms from NVIDIA, Qualcomm, and Texas Instruments.  One example is the Consumer Preview (CP).  The Windows 8 CP on X86 (Intel/AMD) was and still is openly available for any consumer on the planet to try, without exaggeration.  In contrast, there’s Windows 8 on ARM (WOA) where, without an NDA, no one can even touch a system.  There can be a few reasons for that, including secrecy, the unique ARM software images required, it just isn’t ready yet, or a combination of all.  With approximately six months until launch, is Microsoft ready for Windows 8 on ARM? (...) Microsoft has written a lot about this on their Building Windows 8 blog, but the questions still remain on specificity.  Specifically which hardware peripherals work well, which ones work but without all features and which ones just don’t work.  This means USB printers, webcams, scanners, digital cameras, SD-cards, game controllers, displays, headsets, speakers, etc.  Sure, drivers are being written now and will be updated well after launch, but without anything definitive, what are OEMs and channel partners to plan?  The channel needs to prepare appropriately with the right peripherals that are compatible with WOA systems. (...) We’re six months from launch and channel partners and OEMs should know this already to prepare for the holidays.

Más aún, está claro que Windows 8 no será compatible hacia atrás para ARM: <<For some it may be an obvious thing to state, but Windows 8 on ARM will be a completely blank canvas with no compatibility mode for any software running on previous x86 versions of Windows. If a developer wants an older app to run on Windows 8 ARM, they need to develop a new version specifically for the platform>>
Mary Jo Folley escribe el 3 de abril acerca de la llamada de Microsoft a escribir aplicaciones y adaptar lenguajes a WinRT, destacando que <<Microsoft officials have been encouraging developers to consider HTML5/JavaScript and C++ when writing new Metro-style apps. However, as Development and Platform Evangelist (DPE) Jerry Nixon recently noted, it’s the managed languages and .Net that seem to be where most of the Windows 8 developer interest is — at least when measured in terms of developer questions and comments on the MSDN forums (...) I guess it shouldn’t be too surprising, however, that devs prefer using what they already know>>. La propia comunidad de desarrolladores de Microsoft se encuentra desorientada, y probablemente defraudada, sometida a un cambio no esperado, y sometida a la presión de la obsolescencia de todo su desarrollo previo.
 En fin, estos son algunos elementos de los últimos días que marchan en una dirección concurrente. Bajo estos antecedentes, Adrian Kingsley-Hughes, agrega el problema del hardware, para componer un escenario más que complicado para Microsoft:

ZDNet’s Mary Jo Foley wonders when are we going to start seeing ‘reimagined’ hardware that will make using the touch-centric Windows 8 less painful and more compelling.

“The problem is,” writes Foley, “without these next-gen PCs and tablets, it’s hard for me - and I’d think others, too - to really grok how Windows 8 is going to work from running it on PCs and tablets that were designed for a non-touch-centric operating system like Windows 7.”

Yeah, that is a bit of a problem. Especially given that we’re probably six months or so away from Windows 8 being released. So, where is all this cool new hardware?

Don’t hold your breath for it just yet.
We can be certain of one thing. There will be Windows 8-specific hardware, in the form of tablets, ultrabooks and touch-enabled PCs, available at the launch of the operating system. The problem isn’t going to be the availability of hardware, but the price point of the hardware.
Touch adds dollars to a system — especially to the price of a PC, where the market hit rock bottom a long time ago — and it is adding cost at a time when both consumer and enterprise buyers are most sensitive to price. To make matters worse, OEMs currently have no idea how the mass market will react to Windows 8. It could flop like Vista, in which case demand for touch-enabled hardware is going to be very soggy and OEMs will be left struggling to offload hardware. Alternatively, it could be a runaway success like Windows 7 was, in which case it will be harvest time for the OEMs.
Problem is, failure is still very much an option, and the idea of Windows 8 being a catastrophic failure is a massive turn-off for hardware makers; doubly so when they are expected to pour significant capital into design, development and production of Windows 8-specific systems. Failures of devices such as Motorola’s Xoom and RIM’s PlayBook are still on the minds of all OEMs.
Another problem is the incumbent desktop and notebook PC. While Microsoft is undoubtedly embracing touch computing with both hands, we’re still not sure what the game-plan is here. Microsoft has made a lot of noises about how touch is the future because it is better and easier to use, but many others and I still remain unconvinced.
The keyboard and mouse are far too entrenched in computing to be swiped away overnight. I firmly expect that the majority of systems that will ship with Windows 8 over the new operating system’s lifespan will be traditional, non-touch systems featuring keyboards and mice, and the OEMs must also suspect this.
Then there are Windows 8 tablets. It’s here I feel that Microsoft’s new operating system will shine the brightest, but it’s still far too early to say that there’s any guarantee of success. The biggest problem facing OEMs here is that they have to deliver a product that competes favorably with the iPad when it comes to a number of metrics - form factor, weight, battery life and, probably most significant of the lot, price.
If the OEMs can’t get all their ducks in a row here, it could be a bloodbath.
Why are we not seeing some OEMs take a leap of faith now and start releasing touch-enabled hardware powered by Windows 7 in advance of Windows 8? Simple. That would be a bloodbath too. Windows 7 is an appalling choice for touch-enabled hardware. This means that OEMs don’t really have the option of shipping touch-enabled hardware now with the promise of a free upgrade down the line to Windows 8.
Windows 8 will reimagine hardware, just not that much. There will be touch-enabled systems available, but they will command a premium price and appeal to a niche market. The traditional desktop and notebook will continue to be the main platform for Windows 8. There will also be Windows 8-powered tablets, but it remains to be seen just how well these will stack up against the iPad.
Uncertain times lay ahead for the OEMs.

 En estas condiciones, consultoras y empresas planeando su estrategia futura, deberían ser muy prudentes en sus movimientos.