Patentes, innovación, y el perro del hortelano...

Quiero reproducir la nota de Mariano Amartino sobre el problema de las patentes en Estados Unidos, modelo que comienza a proliferar bajo diversas formas en otros lugares...Un modelo que se asemeja a otro caducado hace doscientos años...

Las patentes de software en USA ya paralizan emprendedores
Interesante artículo de The Guardian: App developers withdraw from US as patent fears reach ‘tipping point donde se muestra que para un desarrollador independiente ya es casi imposible desarrollar una nueva aplicación de software sin estar pisando o rozando una patente propiedad de algun gigante o de un troll de patentes.

Recuerdo haber escrito irónicamente como Intellectual Ventures era “La fábrica del futuro” y como su modelo era sentarse a imaginar cosas y patentarlas sin intención de usarlas… solo tenerlas en un portfolio capaz de ser usado para atacar legalmente a los que crearan productos relacionados.

Pero tal vez, lo que nunca imaginé era que en algún momento esto iba a molestar tanto al ecosistema de emprendedores que en medio de demandas cruzadas se iba a obligar a IV a mostrar el nombre de sus inversores y algunas sopresas aparecen en ese listado: Apple, Microsoft, Amazon, American Express, Cisco, eBay, Google, Intel, Nokia, Sony… y al menos una docena de universidades están apoyando este modelo de la forma más explícita posible: con cash puro y duro. [Listado completo de inversores en este PDF]
Y entonces lo que uno ve es que el famoso mantra de fomentar la innovación que muchos dicen es una simple mentira ¿como se va a fomentar la innovación si ponen fondos en la expresión máxima de un Patent Troll? ¿como van estas empresas a “foster the entrepreneurship” cuando están cerrando caminos a innovadores para patentar ideas con el fin último de tenerlas dormidas y demandar a terceros? Eso no es innovación y eso muestra que el Gobierno de USA (en momentos que busca hasta tener Visas para Emprendedores) no entiende el nivel de estancamiento que tiene su modelo económico.
Coincido con Chris Sacca cuando dice que este es un modelo mafioso que recién ahora se empieza a hacer conocido… de hecho para el que no lo sabía la gente de Intellectual Ventures tiene 1100 sociedades anónimas CREADAS para demandar a emprendedores.
Lo perverso en esto que las patentes de software (y otras) nacieron para darle al pequeño inventor la posibilidad de tener una ventaja intelectual frente a los gigantes que los copiaban y solo hubo dos cambios en el proceso de patentamiento que lo convirtieron en un modelo anti-innovación:

a) Los tiempos se hacen lo más largo posibles al punto de ser ridículos
b) No se exige una aplicación real para aprobarlo ni se revisa el arte previo

Para poner un ejemplo, si tengo una persona sentada en un escritorio y piensa: “mmmm en el futuro se va a poder manejar una interfaz de usuario sin tocar una pantalla o un dispositivo físico, la orientación de nuestra mirada va a servir para ejecutar comandos” y si Julio Verne hubiera ido a la oficina de patentes de USA hoy la aviónica de Lockheed-Martin para los F22 no se podría aplicar porque:

a) Esa patente era perpetua
b) La tecnología necesaria para que ESE pedazo de innovación aparezca recién estuvo disponible hace poco

Cuando la idea de negocio es sentarse e imaginar el futuro (sin saber como funciona) patentarlo y esperar que otros creen los bloques que pueden hacer esas patentes una realidad para ir a demandar por millones de dólares a cualquiera que quiera emprender o crear algo nuevo… es que el sistema está podrido.

Duda: ¿te parece que exagero? Lean sobre France Brevets o miren Patent Absurdity

LeanEssays: How Cadence Determines Process

Leído en el blog de Mary Poppendieck...

LeanEssays: How Cadence Determines Process: "If you want to learn a lot about a software development organization very quickly, there are a few simple questions you might ask. You might..."

Webclient mobile es ahora open source

La newletter de CM First publicada hoy comunica que la elaboración de las nuevas plantillas destinadas al soporte de aplicaciones móviles se convierte en un proyecto open source. Es decir, abierta fundamentalmente a la comunidad de usuarios y desarrolladores de Plex/Webclient, porque de todas formas trabajar con ellas exige disponer de una licencia. Sin embargo, esta decisión representa otro paso destinado a abrir el desarrollo de patrones, semejante al que diera AllAbout hace un par de años abriendo el desarrollo de su desarrollo sobre XML. La arquitectura de Plex en su basamento en patrones y el desarrollo creciente de su API están permitiendo abrir sus posibilidades y extender su alcance. Los patrones para dispositivos móviles (teléfonos y tablets) se han iniciado con una base importante, y se potenciarán con participación abierta. Hay muchos otros campos donde aplicar este concepto.
El nuevo proyecto, en Google.Code.

Sugerencias que da un proyecto

Bob Fields, de Walt Disney World, comenta en The Model Driven Software Network, la  estrategia de la compañía para el desarrollo de sus aplicaciones usando Java, Eclipse, Rational, Maven. Una experiencia que recién comienza a describir, pero que ya presenta aspectos de interés si la sobrevolamos un poco, sea en general como medio de articular una línea de trabajo con MDD, o, siendo más específico, desde el punto de vista de Plex. Dice Bob:

(...) My main passion as an architect is in finding ways to improve the software development process through automation. I have championed the adoption of Apache Maven at WDPR, but much work remains before we have full adoption and integration over all phases of the lifecycle.(...) I led the effort to adopt an MDA tool several years ago. After investigating a number of alternatives (two no longer exist: OptimalJ and ArcStyler), we settled on the open source tool AndroMDA because of the maven implementation plus the mature output capabilities using velocity templates: Java, Spring, Hibernate, EJB, EJB3/JPA, Struts, JSF, WebServices, jBPM/Drools, dotNet NSpring/NHibernate/ASP.

 Es decir, articular una herramienta MDD con el mayor espectro posible de salidas, incluyendo todo en algún tipo de herramientas que permita articular y automatizar cuanto sea posible del ciclo de vida del sofware. En el caso de Plex, muchas sugerencias para extender y abrir el desarrollo, adelantándose a lo que en un momento determinado sea posible hacer con la IDE. Lo que iniciara Webclient (puente con Eclipse + Web), ampliado.

Win8, Silverlight, y otra razón en favor de MDD

Las primeras presentaciones de Windows 8, todavía muy preliminares, han contribuído a crear un revuelo mayúsculo en al menos parte del mundo de desarrolladores de Microsoft, básicamente en la comunidad de Silverlight, y hasta cierto punto también en la comunidad .NET. Según parece (a casi dos años todavía de su lanzamiento), Windows 8 será profundamente distinto, tanto en su diálogo con el usuario, como en las herramientas con las que construirá su interfaz con él. La respuesta pública ha tenido dos caras: de parte del mercado comprador (hogar y socios de negocios interesados en salir al paso de la competencia en tablets y teléfonos inteligentes), expectativas positivas. De parte de la comunidad de socios y desarrolladores que construyen para su arquitectura actual, quejas y desconfianza. ¿Por qué? porque intuyen, tanto a través de las presentaciones, como por lo que no se dice, que las herramientas actuales ya no estarán en el centro del negocio, sino que pueden caer a un mercado secundario, mientras el foco se desplaza a aplicaciones montadas sobre HTML5, CSS3 y javascript. Justin James, en Techrepublic, es uno entre otros muchos, que describen este estado:

There is an absolute firestorm around HTML5-based apps in Windows 8 and where it leaves native app technologies like WPF, Silverlight, and WinForms. I have no idea what is happening for sure, and I guarantee you that all of my Microsoft contacts either do not know or would not tell me if they did, and I respect that. Here is what I do know:

• Windows 8 appears to have an application building engine based on HTML5 technologies (I’m including JavaScript and CSS3 in that umbrella).
• Microsoft stopped pushing Silverlight as a Web app add-in a while ago, and said it was for “out of browser,” cross-platform, and special purposes (like WP7 development).
• WinForms got backburnered with the release of WPF.
• The pace of Silverlight development has slowed significantly as the technology matures.
• Silverlight has been a big success in writing internal applications, and Silverlight is not the pain point in writing WP7 apps (the APIs and their lack of support for many scenarios are).
• Microsoft has displayed a worrisome habit of dropping technologies just as they seem to be fulfilling their potential.
• Silverlight has been increasing its capability for quite some time, heading towards convergence with WPF. The big barrier has been the size of the download; the Silverlight team stated a while back that the installer should never be bigger than Flash’s.

Based on what I know and the current trends, I do not think Silverlight is going away any time soon, but I do think Microsoft is seeing HTML5 as “Silverlight Lite.” Since Silverlight is already “WPF Lite,” It’s conceivable that WPF and Silverlight will merge, basically putting the out-of-browser capability onto WPF, and either taking out the stuff that doesn’t go across platforms or just having two WPF profiles (just as Silverlight has a phone profile that is less capable than the full Silverlight platform). Then, Microsoft can feel free to push its HTML5 apps to folks that like the Silverlight idea but don’t feel comfortable with the technology. This is 100% pure conjecture on my part though. Mary Jo Foley has some interesting information as well, and Laila Lotfi has a good analysis of the situation.

Pongamos esta situación entre paréntesis: falta mucho para que se desenvuelva completamente la ¿nueva? estrategia de Microsoft. En poco más de dos años, se ha producido una explosión de ofertas de arquitecturas, sistemas operativos, y estilos y alcance de aplicaciones. Claramente esta situación clama por otro estilo de desarrollo. Jugarse hoy por una arquitectura puede ser suicida, pero no dedicarse a ella también puede ser una decisión para arrepentirse largamente. Este panorama trae a primer plano a las herramientas que basan el desarrollo en modelos, construyendo la lógica de negocios, o la lógica a secas, en un terreno abstracto, con la capacidad de desplegarla luego en la arquitectura que haga falta. Así, si una arquitectura de pronto va a vía muerta (como quizá pase con Simbian), el patrimonio en aplicaciones desarrolladas no queda atada a la arquitectura, la plataforma, o el framework, sino que es viable desplegarlo en otra alternativa.
Frente a las ocasionales afirmaciones acerca de eventuales debilidades del desarrollo basado en modelos, me cuento entre quienes sostienen que este universo de múltiples galaxias, tiene su llave en MDD. Cuando he presenciado defensas de distintos frameworks, en un momento donde éstos se encuentran en general atados a un puñado de propietarios, he sostenido que jugarse por uno puede significar perder mucho, simplemente si el propietario es comprado o cambia de estrategia (y está claro que Simbian no es el único caso).
El carácter abierto de MDD permite que un ecosistema de herramientas de modelado se acompañe por otro que permita ofrecer generadores que transformen los modelos abstractos a las distintas arquitecturas, plataformas, frameworks y lenguajes. Si el estado hoy es imperfecto, hacia allí se moverá, perfeccionando las soluciones.

Conferencia CGN: Karsten Thoms sobre principios básicos

A falta de oportunidad de participar en la conferencia, dedicaré algunos días a comentar lo que de las presentaciones aparece como más interesante. Soy enemigo de los powerpoints, porque están pensados para servir de guía durante una conferencia o presentación, y acompañan la conversación del disertante, pero reflejan pálidamente lo que el autor conversó. En el caso de la presentación de Karsten Thoms, esta es tan espartana que podría dudarse de cuál fue su contenido. Sin embargo, los diez títulos hablan fuerte y claro. De entre ellos, quiero destacar los siguientes, que coincido en que determinan la factibilidad de usar un generador de código. Interpretaré libremente lo que Karsten explicara, basándome en sus sentencias minimalistas:

Mezclar artefactos cuyo código es generado con otros creados 'a mano' (Mixed Generated/Manual Code Artifacts). Este escenario implica que hay aspectos que, aunque fueran representables en un modelo, no pueden ser traducidos a código. Estos espacios no cubiertos derivan de un generador que ignora aspectos del modelo, y por lo tanto no es capaz de representar la totalidad. Aún cuando pudiera haber casos en que la parte manual (opaca para el modelo) pueda rescatarse, al no tener relación con la descripción abstracta, el esfuerzo de integración corre por cuenta del "codificador manual". Si aplicamos esta falta de integración a modelos complejos y grandes, el esfuerzo de seguimiento de la relación entre las dos partes es peligroso, y posiblemente motivo de fracaso.

No reestructure su código generado (Don‘t Refactor Your Code Generator Code). Aplicar una nueva capa de optimización de código al código generado es doble trabajo, y ganancia de corto alcance, ya que al no afectar al modelo, el código se reproducirá a la siguiente oportunidad. Si su ciclo de desarrollo se basa en iteraciones cortas, la refactorización puede ser agotadora (e inútil a futuro). Esto no quiere decir que no sea bueno refactorizar. Pero debe hacerse sobre el modelo, y sobre las reglas de transformación; es decir, una refactorización bien distinta. El código debe derivar optimizado, no rehecho a posteriori.

Hay otros tres puntos que resultan especialmente interesantes, pero en este caso, trataré de conocer directamente su posición sobre ellos:

• Missing Reference Models /Implementations

• Don‘t Participate Developers

• Requiring The IDE For Execution

 Para seguir a Karsten, su blog.

Esperando noticias de la conferencia...

Entre el 1 y el 3 de junio se desarrolló la conferencia anual de Plex. No habiendo participado, espero las noticias...En unos días, más detalles de lo que el programa anticipaba.
No es la única conferencia de la que espero noticias: también una semana antes se completó la conferencia de Code Generation Network. En este caso, algunos adelantos han dado Pedro Molina, Marco Brambilla, Angelo Hulshout y  Johan den Haan, entre otros. Lamentablemente, estas semanas, poco tiempo para dedicar por anticipado...

Argentina y los emprendedores

Entre tantas cosas que andan mal en Argentina, si hay algo que da aliento, es su capacidad de generar emprendedores, creadores de nichos de oportunidades. Frente a una clase dirigente esclerosada, la sociedad pugna por mejores horizontes. El diseño y el desarrollo de la industria del software se han convertido desde el estallido de la crisis del 2001, en una fuente de buenas noticias nacionales. La Nación comenta hoy el último caso (nota de Francisco Jueguen):

Arrancó como todo pequeño emprendimiento en la Argentina: con muchas ganas, ideas geniales, poco presupuesto y oficinas transitorias en un Starbucks. Dos años después de un primer buen cliente, incontables y trasnochadas horas de trabajo, y una oportunidad única en el mercado, despertó el interés del gigante.
En Altodot, una firma local de desarrollo de aplicaciones para redes sociales, sólo trabajan 15 personas. Pero desde hace dos semanas, esta pequeña compañía tecnológica acumula un capital exclusivo que sirve para rellenar su disfuncionalmente reciclada oficina ubicada en lo que hoy se llama Palermo Valley.

Es que tienen un fan. Pero no es un fan cualquiera. No es un cliente, un usuario o un simple interesado en el mundo del desarrollo tecnológico. Ese nuevo fan es Facebook, la red social más importante del planeta, que hace unas semanas decidió "recomendar" por primera vez a una compañía en la región. Y la elección fue argentina.

"Para nosotros es un logro muy importante, sobre todo en el reconocimiento a nivel imagen", afirma Antón Chalbaud, el CEO de Altodot, al comentar la inclusión de la empresa que conduce al prestigioso Programa de Referidos de la red social que aglutina a 600 millones de usuarios.
Este programa agrupa a una exclusiva red de empresas seleccionadas por Facebook a través de un exigente, minucioso y largo proceso. Pero la recompensa es grande. Una vez elegidas, se las define como aquellas que realmente "tienen la habilidad de entender los mecanismos sociales y las posibilidades técnicas en la plataforma".
"Aunque no es una certificación", dice Chalbaud, son 90 las firmas en el mundo referidas por la exitosa empresa de Mark Zuckerberg para trabajar con desarrollos y aplicaciones sobre Facebook.

El joven empresario, nunca recibido de la carrera de Administración de Empresas de la Universidad de San Andrés y con un posgrado en el IAE, es un hombre de experiencia en el mundo de la tecnología. Fundó su primera puntocom en 1999 y pasó tres años detrás del managment de Sónico, una red social nacida en el país. A fines de 2009, fundó Altodot junto con otros socios. "Los primeros meses calentamos motores. En 2010, facturamos 500.000 dólares y las proyecciones de este año son de 1,5 millones", explica, enfundado en una remera rosa en la que se integra su nuevo proyecto, The Fan Machine, con Facebook y con Twitter.

"Estamos cambiando el foco de la compañía. Venimos de ser una empresa de servicios y queremos transformarla en una que desarrolle producto. Ahora estamos lanzando una plataforma social de marketing [ www.thefanmachine.com] en español, inglés y en portugués", indica Chalbaud.

"La idea es ayudar a las compañías pequeñas o grandes, a través de esta herramienta, a que sea más fácil conseguir una mayor cantidad de fans tanto en Facebook como en Twitter", relata. "Si tenés una fan page , podés agregar aplicaciones que te ayuden a tener más fans y eso se hace muy fácil, en minutos, y, hoy por hoy, de manera gratuita", completa. La plataforma está actualmente en beta (en modo de prueba).
La noticia llegó hace sólo dos semanas. Chalbaud estaba disertando en un seminario de exportación de tecnología en los Estados Unidos. Sobre la mesa, su teléfono vibró. Leyó el e-mail y una eterna sonrisa se le dibujó en su cara. Había pasado la prueba y era parte de la red de empresas de desarrollo recomendadas por Facebook. Envió el correo a toda la empresa y estuvo a punto de contarlo en el seminario.
"Fue bastante loco. Por suerte no lo se conté a todo el auditorio. Después leí el e-mail hasta el final y no lo podía comunicar hasta que no lo hicieran ellos. Hubiera armado un lío bárbaro", dice, aún con una sonrisa en su cara.
"Esto significa que trabajamos bien y que saben lo que estamos haciendo. Que somos de esas compañías que desarrollan soluciones instalables, innovadoras y que cumplen con las continuas modificaciones de los términos y condiciones que te impone Facebook", explica el CEO de Altodot, que tiene clientes en Chile, Perú, Colombia, México, Estados Unidos y que está empezando a instalarse en Brasil.
"Hoy nuestro foco está puesto en el marketing. Entendemos muy bien cómo funciona Facebook como medio de comunicación social para promover distintas acciones, comunicar un mensaje o vender un par de zapatillas", cuenta Chalbaud, y cierra: "En ese sentido, estamos orgullosos de que el dueño del circo nos recomiende".

InfoQ: hablando de desarrollo basado en patrones

InfoQ, a través de una entrevista de Dave West a Lee Ackerman y Celso Gonzalez, autores de "Patterns-Based Engineering: Successfully Delivering Solutions via Patterns", trae a foco el uso de patrones. La breve promoción del libro recuerda algunos de los valores más importantes de su uso. De allí quisiera destacar dos elementos comentados:
1, La importancia y posibilidad de reuso de patrones:

InfoQ:  The very first benefit of PBE [Pattern based engineering] in chapter 17 is increased productivity via reuse.  Reuse was the great promise of object-oriented development.  It did not pan out.  Why will pattern-based reuse have a better chance of succeeding?
We struggle with the idea that reuse has not panned out. We’d agree that the idea of reuse was oversold and oversimplified. However, we need to keep in mind the significant amount of reuse that has been achieved by using OO concepts and related ideas (e.g. frameworks, libraries, components, etc).
Patterns not only help us in sharing and consuming best practices, but also take us forward in the next step of coarse-grained solutions. And in taking that next step forward, it’s not that the components are larger in size, but that they provide points of variability that allows us to customize the pattern as we apply it to our situation.

With that in mind, one big difference between patterns and OO reuse is that patterns are reuse of design in contrast to reuse of code. Due to its higher level of abstraction, patterns are often more reusable than code.

And last, but not least, we also need to focus on pattern consumption. Today there are already thousands of patterns available for reuse. However, we struggle to find the right pattern at the moment of need. As we improve our ability to find patterns (according to requirements, relationships, workflow) we will see a subsequent increase in reuse and ROI.

2, Patrones y desarrollo basado en modelos (MDD):

InfoQ:  PBE is an example of Model-driven development (MDD) mostly as a result of using the engineering metaphor as a philosophical base.  Throughout the book you mention the possibility of automating PBE and the use of patterns.  To what extent do you share the core intent of MDD - create a formal model and mathematically transform that model into correct and executing code?
We’d actually start with a simpler definition of MDD, whereby we focus on using model as abstractions – hiding details that are not necessary at a particular moment in time. Automation can be a boon to productivity – but is not a necessity in performing MDD. We could use pen and paper, white-boards, or simple software applications that allow us to model.

When working with PBE we encourage and support the use of both pattern specifications and pattern implementations. Pattern specifications are the formal, written documentation such as what we find in GoF book and many others. A pattern implementation is the codification and automation of a pattern in tooling. There are a number of ways that this can be accomplished and many tools that support the creation of such automations.

Tooling to create and work with pattern implementations is continuing to mature. To date, the most impressive results that we have seen have been through the use of Java Emitter Templates (as found in Eclipse). The tool simplifies the effort that goes into analyzing exemplars – those reference solutions that will serve as the basis for the automation. In analyzing the exemplar, JET simplifies the pattern creation process and makes this capability something that anyone can learn to use. Ease of use, and speed of delivery are some of the important aspects of driving adoption of pattern implementations.

We’d also caution against unreasonable expectations of having a bit of modeling, a few patterns, and then being able to generate 100% of a solution. Such thinking at this point will lead to issues in over investment in pattern development and modeling. Better to look to build out a pattern repository, use compound patterns and recognize a role for seeding the code and incorporating user regions where code can be augmented after generation.

Para quienes usan Plex, como es el caso mío y de parte de los lectores aquí, el uso de patrones es uno de los puntos más fuertes en la obtención de productividad. Plex es una demostración cabal de que el desarrollo de patrones de variado alcance es posible y altamente productivo. Varias de las empresas asociadas a su uso han basado su crecimiento en la construcción de un grupo de patrones de valor crítico en algún área tecnológica. Más aún, se podría decir que Plex difícilmente hubiera sobrevivido sin su capacidad de extensión a través de patrones reusables. (Y la apertura de su Model API, que merece trato aparte).
En estos días, la Wiki de Plex ha extendido su entrada sobre patrones, publicando algunas de las soluciones existentes. No se publican allí, pero merecen artículos separados, dos de los sistemas de patrones que particularmente lo han potenciado en los últimos cinco o seis años: los patrones para desarrollo web de Websydian y Webclient. Doy fe de que funcionan.

Dimensionando la computación en la nube...

Brian Gracely en Dzone abre interrogantes y perspectivas acerca del impacto de lo que cloud computing tendrá en el mundo tecnológico presente y futuro. Vale la pena seguirlo:

(...)  let's start looking at what changes for various people in the Cloud Computing value-chain:
CIO: Your job has probably never been more complicated than it is today. Your vendors/partners are engaging in coopetition like never before. The technology is changing incredibly fast and you're struggling to keep/grow internal talent. Plus your internal users are getting much smarter and may be looking for ways to avoid your services. External services are now available with completely new consumption models, but they also bring a new forms of risk that aren't very well understood yet. And all your colleagues are talking about "cloud projects" and you may not know exactly where to start, or expand. And the start-ups in your industry don't have the existing IT legacy to deal with, so they are approaching the use of IT in strategic ways that you've probably never dealt with before.
IT Operations: If you're like most IT organizations, you're spending 70-80% of your time and budget keeping the internal systems operational. That doesn't leave much time to deal with the pace of change coming from all these cloud offerings, but the CIO is still pushing you for it. So how do you find the funding? How do you find the right skills (internally, retrain, cross-train, externally)? If you're considering a Private Cloud, this might be worth a listen. The key is to start looking at the best practices of the Public Cloud operators (here, here, here and here) and see what best-practices you can bring in-house (where it makes sense) and where external services might make more sense.
Server, Storage, Network teams: In the past, your world was challenging enough keeping up with all the technology, protocols, architectures, etc. Now the divisions between your groups are breaking down as virtualization technologies provide integration within platforms. Or maybe the emerging cloud stacks are abstracting functionality out of your hardware and moving it to application software. Some people look at this as an opportunity to broaden your skills and take a broader role as an "infrastructure specialist", while others believe that proliferating IT generalists is a bad idea.
Application Developers: Open-Source frameworks; the momentum of DevOps; infrastructure you can obtain with a credit-card and avoid IT bottlenecks. On the surface your world is looking pretty good because many of the barriers from your previous life (software licenses, IT operations, procurement delays, etc.) seem to be coming down. But not everything may be rosy. You've got to potentially design for external/public cloud infrastructure that may not be well understood. And maybe you'll design your applications to be portable between clouds? But you also have to consider new ways to audit applications and data, and potentially new ways to secure it and make applications highly-available.
Systems Integrators: Being able to integrate these complex systems, on-premise or off-premise, may become an even more valuable skill moving forward, especially if you're able to harness some of the open-source projects that allow you to add value. But is that currently your strength? Were you previously focused on solutions based on commercial vendor offerings? Are those vendors still using you as a primary channel, or are they looking to take customer business direct through their own clouds (here, here, here, or here)? Or should you be looking to partner with some of the existing Cloud providers for technology scale, and focus on localized relationships with customers?
Cloud Providers: We've already seen this space consolidating and changing quickly (Terremark/Verizon,  CenturyLink/Savvis, TimeWarner/Navisite) as well as outages that have customers questioning if they will deploy to public clouds. But they are moving quickly to roll-out new services and address demands from Enterprise and Government customers. Some are even pushing frameworks that could open up new innovation or undermine operational advantages. Each of them will need to decide if they want to provide commodity services, differentiated services, and which *aaS frameworks they need to support to drive customer demand.
Application "Stores" and Cloud Ecosystems: We're all familiar with App Stores like iTunes or Android, but will independent Application Stores begin to emerge for applications built on open frameworks such as Cloud Foundry? Will we see greater expansion of the services available from existing Cloud providers such as Salesforce.com, Google Apps or others to entice customers not to make themselves overly portable?
IT Vendors: Software stacks and open-source projects are knocking at your door, threatening to disrupt the foundation of businesses built on hardware platforms and commercial software offerings. Will these macro-level trends simply create downward pressure on margins vs. open-source alternatives, or does this spur a new wave of innovation that interacts with these new models in ways to balance the flexibility with stability and investment? Do your customers want solutions based on these newer models, which also changes their internal skills and buying models? Should you hedge your bets by setting up Cloud services directly, or do you continue your existing go-to-market approaches? How do you manage coopetition in partnerships where every vendor appears to be moving into 2 or more adjacent technology markets than they were in a few years ago?
As you can see, the potential for significant change in the overall value chain between technology providers, technology delivery mechanisms and technology consumers is extremely high. It has the potential to significantly change existing business models, but it's also highly dependent on a new set of skills emerging for operators, architectures and people in between.
But out of confusion comes opportunity if you're open to change and new ideas. We're just at the beginning of a significant change in our industry and how it effects business on many levels. How companies (vendors, providers, integrators and business consumers) navigate these changes and confusion will determine the winners and losers of the next 5-to-10-to-20 years in the IT space.

A propósito de liderazgos, Twitter

Alejandro Laso, en El Confidencial, enfoca el futuro de Twitter, viéndolo como un interrogante sobre su gerenciamiento, con dificultades todavía para hacer la empresa rentable. Dadas las condiciones presentes de guerra desatada por posiciones en los negocios en la web, Twitter está bajo mira...:

Puede presumir de tener 200 millones de usuarios que suben diariamente 50 millones de tuits. En el ‘boom’ de las redes sociales, Twitter ha logrado posicionarse como una de las más populares, aunque sus finanzas dejan mucho que desear. La plataforma de microblogging sólo generó unos ingresos de 30 millones de dólares durante 2010 por publicidad, una cantidad irrisoria al lado de los 1.275 millones que facturó Facebook -600 millones de usuarios- y los 5.737 millones de Google.
Y es que los comienzos de la red social de microblogging ya fueron complejos. La idea surgió a principios de la pasada década con otro nombre y otros protagonistas, pero poco más tarde fracasó porque Internet no tenía la suficiente madurez como para entender un concepto tan innovador. Tuvo que ser en 2006 cuando una pequeña start-up de Silicon Valley fundada por Jack Dorsey llamada ‘twttr’ –luego rebautizada como Twitter- rescató esas ideas originales, las mejoró hasta revolucionar la forma de comunicación con mensajes de 140 caracteres.
Su popularización vino de la mano de famosos, periodistas y profesionales influyentes que quisieron utilizar esta red para comunicarse. Gracias a ellos, la red de microblogging ha conseguido popularizarse y sumar millones de adeptos los últimos meses, aunque la compañía todavía se enfrenta al gran dilema de no saber cómo rentabilizarlos.
El problema es que su modelo de negocio es muy innovador y complejo al mismo tiempo. Para empezar Twitter no tiene nada que ver con Facebook. Es un sistema más complejo que además se ha convertido en una de las empresas pionera en orientar su modelo de negocio a los dispositivos móviles. Precisamente, esta decisión empresarial se ha convertido en la clave de su éxito. Gracias al ‘boom’ de los smartphones, la inmediatez de sus mensajes se ha convertido en un arma con la que Facebook todavía no puede competir. Twitter se ha abierto camino en un terreno virgen y en poco tiempo se ha convertido en una agencia de noticias, potenciando el periodismo social, y que ha favorecido que se produzcan hechos tan relevantes como las revueltas en el mundo árabe.
Sin embargo, la ventaja del uso en los ‘smartphones’ también se ha convertido en un ancla para las finanzas de Twitter. La publicidad a través de los teléfonos móviles todavía está en pañales y aún debe pasar un lustro para que las compañías realmente puedan encontrar la fórmula mágica para vender bien en este soporte. Entre el caos del universo de las ‘apps’, los usuarios siguen prefiriendo acceder a través de navegadores, donde la publicidad todavía no ha conseguido adaptarse. Quizá por eso la compañía ha hecho una oferta por Tweetdeck -una aplicación online orientada a Twitter-, con la que la pretende vender más anuncios en los dispositivos tradicionales.
Y por si el sistema de anuncios en móviles aún no está nada logrado, otras fuentes apuntan a que el verdadero problema de Twitter radica en su gestión. La revista Fortune asegura que la red social tiene problemas de liderazgo y se apoya en declaraciones de uno de sus empleados que asegura que el cargo de consejero delegado “parece una puerta giratoria” de la cantidad de personas que han pasado por ahí. El resultado es que en poco más de dos años, Twitter ha cambiado tres veces de CEO, un dato que haría que se le erizasen los pelos a cualquier dueño de una multinacional.
Hoy por hoy, el rumbo de sus 500 empleados todavía está pendiente de definirse. A la red de microblogging se le acaba el tiempo. Su número de usuarios a nivel mundial se ha disparado, pero algunas fuentes, como la consultora ComScore, aseguran que en Estados Unidos el crecimiento se está frenando. Mientras tanto la competencia sigue creciendo de forma sólida. La compra de Skype por parte de Microsoft y las futuras salidas a bolsa de LinkedIn y Facebook, se han convertido en una verdadera cuenta atrás para que Twitter encuentre su rumbo.

Un liderazgo cuestionado

Ben Brooks, un broker americano, publica transversalmente un comentario que va de Skype a la conducción de Steve Ballmer en Microsoft, demoledor para la valía de Ballmer como jefe de la empresa. ¿Será Ben Brooks el mejor juez del caso? Probablemente no, pero sus comentarios son en este caso bien encaminados. Sería una verdadera sorpresa que las cosas no se encaminaran como él lo imagina.
Brooks recapitula varios casos de errores de estrategia:
1. Skype, lo último

Ballmer’s acquisition of Skype for $8.5 billion dollars is not only a gross overpay, but a complete waste of money for Microsoft. Ballmer has yet to lay out a clear reason why Microsoft wanted Skype. He has only stated the obvious: integration in Microsoft products — which could have been done in a partnership instead of an acquisition. In fact, the acquisition by most accounts sounded more like a move by Ballmer to buy something that others ² may have wanted to own — just for the sake of others not owning it.
Beyond that is the fact that Microsoft has 89,000 employees — are you telling me that the company that put a computer in every home couldn’t create a Skype clone?
Not only could Skype have been made in-house, Skype should have been made in-house by Microsoft.
Even if it would have cost $1 billion dollars Microsoft would have been better off creating Skype in-house. Does anybody really think Apple spent anything close to $1 billion dollars building FaceTime?
This entire acquisition feels like a desperate move, made by a desperate man. As a shareholder I hope that the regulators stop the acquisition, but I highly doubt that will happen.

2. El Iphone:

Ballmer is now famous for saying:

There’s no chance that the iPhone is going to get any significant market share. No chance. It’s a $500 subsidized item. They may make a lot of money. But if you actually take a look at the 1.3 billion phones that get sold, I’d prefer to have our software in 60% or 70% or 80% of them, than I would to have 2% or 3%, which is what Apple might get.

We can get into talking tough and all that, but Ballmer — as the face of Microsoft — should have never made such a short sighted comment about any product released by a serious competitor like Apple. What is less quoted is the comments he made immediately following the above:

In the case of music, Apple got out early. They were the first to really recognize that you couldn’t just think about the device and all the pieces separately. Bravo. Credit that to Steve (Jobs) and Apple. They did a nice job.
But it’s not like we’re at the end of the line of innovation that’s going to come in the way people listen to music, watch videos, etc. I’ll bet our ads will be less edgy. But my 85-year-old uncle probably will never own an iPod, and I hope we’ll get him to own a Zune.

What is so shocking about this is that Ballmer recognizes that first to market is important — yet it took until 2010 to launch Windows Phone 7, three years after the iPhone.
Where is the “innovation” that Ballmer mentions in the music space — the Zune is effectively dead now and I bet his Uncle does have an iPod at this point. ³
This is the epitome of short sighted behavior by Ballmer and should have made the board and shareholders incredibly un-easy at the time and especially now. Instead it bolstered his support as a man who was going to squash the evil Apple bug.
Short sighted behavior like this can and should be forgiven if the person later recognizes his errors and immediately moves to correct it, yet again though it took three years to get a serious iPhone competitor out of Microsoft. They never created a music/video player that gained traction after the Zune faded into Wikipedia archives. That cannot and should not be forgiven.

3. Windows phone 7:

As I mentioned above Windows Phone 7 was seriously late to the party. Three years late means that most consumers Microsoft was targeting were on at least their second iPhone before Microsoft started to slowly ship Windows Phone 7. Add to that the basic lack of now common place smart phone features and you begin to see that Microsoft shipped a product that was competitive with the software from three years ago.
Windows Phone 7 may stand to be a long term success for Microsoft, but I doubt it. It is a product that in every way shows why Ballmer should not be in charge any longer. It was late and short sighted about the current market needs. In 2006 Windows Phone 7 would have blown away every technophile, this one included, in 2010 it is interesting and underwhelming.
I can assure you there are no crowds forming to get one.
It is the Zune all over again — a solid offering made far too late to make a substantial difference.

Brooks todavía continúa con otros casos representativos del cambio en el manejo de la empresa. Como corolario (y con el derecho que le otorga ser accionista -seguramente minoritario), propone el desplazamiento de Ballmer, y un cambio drástico de liderazgo:

Microsoft should be searching for a new CEO right now. The Skype acquisition damage can still be mitigated if the proper people are put in place to immediately leverage the Skype brand. A new CEO should be:

1. Passionate about technology: don’t you get the feeling that Ballmer doesn’t really care about the products that Microsoft makes, in the same way that Steve Jobs cares about how employee shuttle buses look and how and where color is applied? Any new CEO should love technology and that will begin to show at Microsoft like it did when Gates was still at the helm if the right person is hired. Ballmer seems to care more about being the biggest thing on the market instead of the products his company creates.
2. Forward thinking: Ballmer has shown his short sightedness time and time again, let’s get an executive with some vision. It is time that Microsoft starts creating new markets instead of trying to understand markets that their competitors are creating.
3. An outsider: this is going to be the hardest thing for Microsoft to realize, but they need to get some fresh eyes on the problem. At the very least it should be someone who has not spent more than the last five years with the company. Microsoft needs a fresh outside perspective. An insider will just keep following the GPS coordinates that have been set forth by Ballmer.

Una vez más, el tamaño de la corporación, y el peso consiguiente de su burocracia, parecen convertir a una empresa, Microsoft en este caso, en otro dinosaurio, apartado de su mejor época.

Una caja de herramientas para trabajar con Plex

Aviso previo: Esta nota ya fue publicada el 12 de mayo. Pero un fallo técnico de Blogger hizo que por ahora se haya perdido.Es probable que en unos días el artículo se restablezca. En prevención de que esto no suceda, se vuelve a publicar. Si Blogger lo repone, éste se borrará.

George Jeffcock anuncia hoy en el foro de Plex en CA una excelente caja de herramientas para trabajar con sus modelos, explotando el Model Api. Una demostración cabal de que Plex está entregando a través de su api una vía abierta para extenderlo libremente.
De la descripción en la Wiki:

If as a CA Plex developer you have found the following tasks a little difficult to achieve then it is hoped these tools can help:


· You can’t find a particular source code / message in your models so you end up creating the source code / message again, only to find the object weeks latter scoped to a function buried under 4 levels of scoping. You now have two or many… versions to maintain. See Search Large Properties


· You want to alter a field’s STATE but how can you tell which action diagrams could be impacted by a change? See Export Large Properties and Create List from Exported Large Properties


· A specific line of action diagram logic is wrong but is used across your model(s) but not inherited, how do you track down the changes? See Export Large Properties and Create List from Exported Large Properties


· You want to use text based change management tool to track changes. See Export Large Properties


· Upgrading and or simply been a while since you rebuilt your applications DLL (WINC) and or PGM (AS400) but don't trust your models and would rather build all the programs found in your installation directories/librarys then See Implemented Programs


· Model house keeping by comparing what DLL (WINC) and or PGM (AS400) are in you installation directories/libraries compared with what your model is configured to. You want to see what implementation names do not exist in your model or model objects that are set to implement No but are still in your installation directories/libraries.See Implemented Programs


· Want to quickly compare an action diagram between Versions/Levels. See Display Large Property


· Driven mad trying to remove local modifications from a panel while trying to understand a particular panel elements runtime behavior. See Display Large Property to view a panels large property.

Nota importante: Actualizando el estado de Stella Tools, no sólo la herramienta al día de hoy ha mejorado. Además, George ha abierto un artículo en la Wiki de Plex que puede constituír un buen punto de entrada para quienes quieran usarla.

Enfocándose en lo viejo...

Esto se ha comentado en el último tiempo muchas veces (incluso aquí), pero, qué bien que lo cuenta Adam Hartung. Adam, en Forbes, comenta la diferencia que existe entre las buenas cifras de ganancias de Apple, y las "buenas cifras" de Microsoft.

(...) Even though Microsoft earnings were up, it wasn’t because they are selling what customers really want to buy. Microsoft has caught the “Wal-Mart Disease” – constantly trying to do more of what it always did, hoping it can regain old results – even as the market keeps shifting.  In stalled companies, executives cut costs in sales, marketing, new product development and outsource like crazy in order to prop up earnings.  They can outsource many functions.  And they go the resorvoir of accounting rules to restate depreciation and expenses, delaying expenses while working to accelerate revenue recognition.  While Microsoft had higher earnings than last quarter, it wasn’t because customers were excited about their products!

When companies are growing, investors likes management to pump earnings (and cash) back into growth opportunities.  Investors benefit because their value compounds. In a stalled company investors would be better off if the company paid out all their earnings in dividends – so investors could invest in the growth markets.
But, of course, stalled companies like Microsoft and Research in Motion, don’t do that.  Because they spend their cash trying to defend the old business.  Trying to fight off the market shift.  At Microsoft, money is poured into trying to protect the PC business, even as the trend to new solutions is obvious. Microsoft spent 8 times as much on R&D in 2009 as Apple – in both dollars and as a percent of revenue – and all investors received were updates to the old operating system and office automation products.  That nearly $9B expense generated almost no incremental demand.  While revenue is stalling, costs are rising.
At Gurufocus.com the argument is made “Microsoft Q3 2011: Priced for Failure“.  Author Alex Morris contends that because Microsoft is unlikely to fail this year, it is underpriced.  Actually, all we need to know is that Microsoft is unlikely to grow.  Its cost to defend the old business is too high in the face of market shifts, and the money being spent to defend Microsoft will not go to investors – will not yield a positive rate of return.
(...) While much has been made of the ballyhooed relationship between Nokia and Microsoft to help the latter enter the smartphone and tablet businesses, it is far too late.  Customer solutions are now in the market, and the early leaders – Apple and Google Android – are far, far in front.  The costs to “catch up” – like in on-line – are impossibly huge.  Especially since both Apple and Google are going to keep advancing their solutions and raising the competitive challenge.  What we’ll see are more huge losses, bleeding out the remaining cash from Microsoft as its “core” PC business continues declining.
(...)
Many analysts will examine a company’s earnings and make the case for a “value play” after growth slows.  That’s a mythical bet.  When a leader misses a market shift, by investing too long trying to defend its historical business, the late-stage earnings often contain a goodly measure of “adjustments” and other machinations.  To the extent earnings do exist, they are wasted away in defensive efforts to pretend the market shift will not make the company obsolete.  Late investments to catch the market shift cost far too much, and are impossibly late to catch the leading new market players.  The company is well on its way to failure, even if on the surface it looks reasonably healthy.  It’s a sucker’s bet to buy these stocks.
Rarely do we see such a stark example as the shift Apple has created, and the defend & extend management that has completely obsessed Microsoft in the wake of this shift.  But it has happened several times.  Small printing press manufacturers went bankrupt as customers shifted to xerography, and Xerox waned as customers shifted on to desktop publishing.  Kodak declined as customers moved to film-less digital photography.  CALMA and DEC disappeared as CAD/CAM customers shifted to PC-based Autocad.  Woolworths was crushed by discount retailers like KMart and WalMart.  B.Dalton and other booksellers disappeared in the market shift to Amazon.com.  And even mighty GM faltered and went bankrupt after decades of defend behavior, as customers shifted to different products from new competitors.  Buying into any of the losers as a “value play” meant you lost money.

Not all earnings are equal.  A dollar of earnings in a growth company is worth a multiple.  Earnings in a declining company are, well, often worthless.  Those who see this early get out while they can – before the company collapses.

Parecería ser que hemos alcanzado el punto en que Microsoft siga el camino de otros grandes actores de la industria de la informática: siguen sin observarse signos claros de cambio en su gerenciamiento, y probablemente otros ocuparán su puesto de liderazgo.

El dilema de un ERP

A comienzos de abril, Ajay Gupta escribe para Informit, recomendaciones para aquellas empresas que adquieren un nuevo ERP (Enterprise Resource Planning). Su punto de vista es que el nuevo software (y toda la reingeniería que trae aparejada) no debería ser modificado mas allá de lo que su propia configuración y ajuste a las características del contratante requieran, por lo menos durante los primeros seis meses, o preferiblemente durante un año fiscal completo:

It is my recommendation that organizations delay any and all customization for a minimum of six months, and preferably a full fiscal year

Sus razones son entendibles desde el punto de vista del ERP en sí, pero son difíciles de aceptar desde el punto de vista de quien lo hubiera comprado para mejorar su gestión. Más aún, aunque aceptara renunciar a ajustarlo a sus necesidades, de todas formas es probable que la dinámica de su negocio le obligara a adecuarlo imperativamente.
La argumentación de Gupta abarca tres áreas:

• El valor de la reingeniería de procesos que propone el ERP de que se trate

Enterprise resource planning systems can bring value to an organization in terms of its automation, defined internal workflow capabilities and through increased decision support transparency and operational efficiency. However, to achieve these goals, organizations almost universally must commit to reassess and re-engineer their existing business processes. A pre-implementation stage is the ideal time to document current operations in an effort to find and cut out unnecessary steps, streamline operations and reduce operating costs, as well as track how operations will translate into the new environment. The exercise of examining business practices helps and is often considered critical to a successful migration to the new system. However, this preliminary planning doesn't always happen, at least not as effectively as would be hoped. Another way an organization can ensure business processes are modified is to essentially force itself to operate with the new ERP right “out-of-the-box” and with no customizations, however slight, to the code, work flows, and system operations permitted in the first fiscal cycle. Such a delay or postponement of customization efforts will be seen as a polite way to deny such requests. Honestly, there may be some truth to this as postponing a request can be easier than openly saying no. However, organizations that truly embrace the notion that the ERP implementation is an effort to change business practices that perhaps don't work as well as they did in the past, even though they have been done that way since forever, generally can find greater success in the overall project.

• El costo de la modificación

Given the current fiscal situation throughout our economy, avoiding measures that increase operating costs in both the short and long term is often essential. At the least, such measures should be undertaken only when there is certainty about the fiscal budgets for the duration of the implementation project, and when there is certainty on the cost implications of the customization. The true cost of customizing an ERP is rarely accurately considered and includes at a minimum all of the following:

• Cost of custom code development by ERP vendor or 3rd party This is often the only factor considered. However, what is considered is only the invoice amount presented on a custom code development proposal. Cost overruns, mid-stream changes to scope, or modifications that account for insufficient requirements are not considered, even though many acknowledge such a likelihood. 

• Additional end user training and consulting costs towards adoption of customized code Customizations, whether altering the core source code or creating a new workflow, are often funded through the original implementation budget and often at the expense of training and consulting dollars. Introducing customized and unique code into an ERP system complicates the overall system use and management effort and usually requires additional training and consulting assistance. Its an interesting act of irony that training and consulting funds are often raided to fund the customizations in the first place, when the customization itself usually requires additional training and consulting support beyond what was originally allocated. Further, since the ERP is customized, the ERP vendor's trainers and consulting professionals may themselves need time to learn how it now operates before they can effectively provide the training and consulting services. Depending on the contract language for implementation support and consulting services, firms may have to pay for the time vendor representatives spend to learn the customization.

• Increased cost of post-implementation ERP maintenance Changes made to an ERP often alter the work process when implementing a vendor's regular patch updates. For example, many ERP systems present a social security number on screens that also provide other, less sensitive demographic information. Given the concerns surrounding identity theft, many consider enacting measures to remove the SSN for such screens so the screen itself can still be assigned to users as necessary for the execution of their duties without giving those users access to the SSN. It sounds worthwhile, and perhaps a change that removes one field from one screen will not be so expensive. However, such a change will have to be tested each time a patch to the ERP system is made to ensure the new patches do not overlay, reverse or otherwise alter the coding changes made in the customization. This added staff burden must be taken into consideration when evaluating this approach to making changes. In light of this, the cost of customization should include the cost of custom code development, additional training and consulting expense, and additional manpower required to maintain the system in the long run. Further, customization necessarily involves time, which may push back go-live dates. If doing so involves financial penalties for missing delivery dates, such financial penalties should also be considered.

• El real conocimiento de los nuevos procesos

Prior to actual “real world experience” in using an ERP to accomplish the numerous tasks that must be performed at all stages of the business cycle, staff may simply not be in the position to identify and articulate all of the areas where customization may present value. Until the organization has seen how the ERP supports all of its administrative and business functions and certain functions only come up once or at certain stages in a fiscal year cycle it may not be in position to know where enhancements will be most helpful to the organization. Further, customizations have the potential to alter the ERP system in ways that affect its functionality in other areas. As ERP systems are integrated systems, changes in one area can have unexpected and unintended consequences in other areas. Often, these changes may not become apparent until later in the business cycle. Only after a complete business cycle would the organization know how to articulate the design constraints that will affect the specific changes desired without compromising functionality in other areas. (...) While functional user and technical staff are still trying to fully understand the operation of the ERP, they may not be in a position to fully articulate the design requirements for any customization, nor accurately predict the consequences of customizations they do implement(...) During the migration to the ERP, the first task is really to understand the ERP and its unique intricacies. Customizing it at this early stage has the effect of giving both end users and technical staff a “moving target,” making such projects more challenging from both the operational and system administration perspective.

Esta es una lista de certeras observaciones. Sin embargo, las conclusiones podrían no ser las que su autor propondría...
Es entendible que empresas sin una cultura corporativa sólida puedan encontrar una ventaja importante en apoyarse en un ERP: éste indudablemente incorporaría técnicas y estrategias de  organización, de planificación y gerenciamiento que valorizarían sus actividades, sus procesos, y sus recursos humanos. Pero si la empresa tiene una cultura y su intención es mejorarla, no parece simple que estas recomendaciones sean aceptables. Un ERP se acerca a un commodity...Una empresa que cuida su posición en primera fila ¿puede confiar sus procesos a un estándar, y no defender su diferencial? Si basa su actividad en la mejora contínua, o reingeniería de sus procesos: ¿se conformará con no intentar refinarlos y reescribirlos? Un ERP tiende a ser un complejo estático, o de baja capacidad de evolución: cuando un ERP ataca un proceso, debe contemplar el impacto de un cambio en el conjunto de sus clientes, y más aún si se trata de un ERP internacional, donde deben contemplarse las exigencias legales y culturales de al menos la mayoría de sus clientes. ¿Cuánto tiempo pasará hasta el momento en que las necesidades de evolución de una empresa en movimiento exijan adelantarse a su ERP en abordar un área determinada de actividades? Y si se escribe nuevo software en áreas no abordadas por el ERP, ¿no comienza la rueda del impacto de lo que Gupta recomienda no hacer...?

Otra compra en el mercado de ALM

Un mes antes que MKS, también Aldon cambia de dueños. En un mes, dos viejos competidores pasan a ser parte de la cartera de empresas que participan del mercado de ALM (application lifecycle management), pero con un alcance más general. Ahora es Rocket Software quien absorbe a otro actor de gran alcance en el manejo de administración de cambios en el iSeries. Parecería ser que los márgenes en el mercado del iSeries (y del ALM seguramente) han disminuído convirtiendo en inviables a productos de un sólo perfil...o por lo menos, más fáciles de tentar con un cheque. Un argumento más en favor de considerar a ALM como un commodity.
El anuncio en SystemI Network, y en la propia Rocket.
También a Rita Sanders la noticia pare caerle por sorpresa:

I stumbled onto the news when I went looking for details on Seagull Software, which I hadn't heard any news from in quite some time. The application modernization vendor's website reminded me that it, too, had been purchased by Rocket Software back in 2007, and is operating as Rocket Seagull, another Rocket Software business unit.
I chatted briefly on Friday with a Rocket Software spokesperson, and he said Rocket Software's growth is a question of the company building its product portfolio in four areas: business intelligence and analytics; storage, networks, and compliance; application development, integration, and modernization; and database servers and tools.

Delicias de la nube...(actualización)

Unas horas después del corte de servicio de Amazon, se asientan los comentarios: ProgrammableWeb evalúa la infabilidad de la nube, y Arik Hesseldahl recuenta los daños...

Un día después: En algunos casos sigue en proceso de recuperación. Algunos sitios todavía no en línea. El corte muestra empresas que dan servicio a otras, apoyadas en la nube de Amazon. Doble problema... Tomio Geron, en Forbes.

Delicias de la nube...

Siguiendo a ExtJs, hoy aparece el lado oscuro del cloud computing: por algún tiempo (¿ tres horas?) múltiples sitios soportados por Amazon, salieron de servicio. En The Next Web:

The popularity of Amazon’s cheap, easily scalable hosting is showing its downside right now, with a number of popular websites and services throwing up errors or being down completely.
Foursquare, Quora, Reddit, Moby and Hootsuite are among those affected by technical troubles on Amazon’s servers. The company’s status dashboard currently shows problems with the company’s Elastic Compute Cloud and Relational Database Service operations, based in North Virginia, with connectivity issues confirmed.

We can confirm connectivity errors impacting EC2 instances and increased latencies impacting EBS volumes in multiple availability zones in the US-EAST-1 region. Increased error rates are affecting EBS CreateVolume API calls. We continue to work towards resolution

Quora pulls no punches on its error page, stating: “We’d point fingers, but we wouldn’t be where we are today without EC2.”

PTC compra MKS

Otro cambio de manos en la industria del software: PTC compra MKS, la empresa canadiense dedicada a herramientas de manejo de ciclo de vida del software. MKS es (o fue) un actor importante en el mercado de iSeries (o AS400, o System i, o como se llame), a través de Implementer y otras herramientas asociadas. A su vez, Implementer fue un producto comprado a Silvon (1998), diseñador originario del producto. MKS con esa compra integró una cartera de productos orientados al soporte del  ciclo de vida de desarrollo de software, que fuera el núcleo de su actividad desde su inicio. Su desaparición (o absorción, para ser más exacto) concentra un poco más la industria, como viene sucediendo desde el 2000 aproximadamente.
Aunque de esto hace ya algunos años, he tenido contacto con la empresa, que heredó, con la compra a Silvon de Implementer, el producto de administración de cambios (MKS-CM Connector) para 2E (hoy CA 2E). Su cambio de propietario traerá cambios de estrategias y partidas en el personal (diseñadores, ingenieros, comerciales) que harán su futuro un poco más anónimo y genérico. Es que ALM es un mercado de commodities...
Para los seguidores de Plex y 2E, CM First, base de Webclient, soporta un producto de administración de cambios para el iSeries (Matchpoint) que también deberá reacomodar sus cargas ante el cambio de guardia de uno de sus competidores.

Rafael Chaves sobre MDD

Rafael Chaves reflexiona el 7 de abril sobre una discusión  en The Model Driven Software Network (a propósito de una crítica de Steven Kelly sobre la real performance de UML), generando una interesante continuación. En resumen, su posición es que es UML tiene más alcance y posibilidades que las que se le atribuyen o se usan, recalcando una vez más que UML no es una notación gráfica (principalmente), algo que él particularmente aplica. Otra buena discusión sobre MDD, unos días antes.