El próximo Microsoft

"El alma de un nuevo Microsoft", un artículo de Bussiness Week mira hacia adelante en la estrategia futura de negocios de la empresa, destacando a directivos como J. Allard, impulsor de Zune:

Zune hit store shelves on Nov. 14--a mere eight months after Allard's team got the go-ahead for the seemingly impossible task of toppling Apple's iPod music player. Contrast that with the five years and some 10,000 Microsoft Corp. workers it took to give birth to the latest version of the company's Windows operating system, Vista, which begins selling to corporate customers on Nov. 30 (and to consumers in January). From the start, Vista has seemed like an anachronism--packaged software in a Web 2.0 era where ever more applications are moving off the PC and onto the Internet, some springing forth in a matter of weeks

Business Week estima que la empresa debe cambiar ante el creciente asedio de nuevos participantes y nuevas motivaciones:

the point is that Microsoft needs to find its un-Vista. Several of them, in fact. The software giant is entering perhaps the greatest upheaval in its 30-year history. New business models are emerging--from low-cost "open-source" software to advertising-supported Web services--that threaten Microsoft's core business like never before. For investors to care about the company, it needs to find new growth markets. Its $44.3 billion in annual sales are puttering along at an 11% growth pace. Its shares, which soared 9,560% throughout the 1990s, sunk 63% in 2000 when the Internet bubble burst, and they have yet to fully recover.

Y directivos como Allard permiten saltar adelante:

Allard and those like him are having an impact. They're showing that strategies to move the company beyond Windows can emerge and be accepted by top brass as nonthreatening. A key moment came six years ago, when Allard insisted that the new Xbox video game console be developed without using Windows. In one meeting, Gates berated him for suggesting that the operating system wasn't up to snuff. But Allard argued that it wasn't specialized enough to handle video gaming. Gates eventually relented, in a decision that is widely seen today as a key to the console's success.
(...)
That's exactly what Microsoft needs if it hopes to again set the tech agenda. Windows and Office will deliver more revenues in coming years than the exports of many small nations. But Web spitfires such as Google Inc. and Salesforce.com have the wind at their backs. And while Microsoft continues to recruit top talent, it also continues to see key leaders move on: executives such as Vic Gundotra, a top evangelist in its developer division, who will soon join Google, and Brian Valentine, the longtime leader of the Windows server business, who now works for Amazon.com Inc.

PHP en el AS/400

Por si no lo sabía...Hasta hace muy poco, no era posible usar PHP en un ISeries (o AS/400, o I5). Desde abril de este año, esto ha cambiado: Zend Technologies Ltd ofrece ahora una implementación. El artículo en IBM developer ofrece información introductoria y de implementación.

PHP on System i is a great benefit to small and medium businesses. After understanding the basic background and architecture types of PHP, you can download and install thousands of available applications on System i, either by themselves or with a supported database. There are considerations when porting an application from the MySQL database to DB2, such as database connectivity. However, the cutting edge, low-cost applications that PHP offers combined with the solid System i platform and DB2 database make a strategic choice for any growing business.

Características actuales de la implementación (dada una, probablemente veremos otras):

System i users have several issues to consider when choosing an open source application. The first and probably most direct issue is selecting from the diversity of existing applications. Zend Core is the only PHP engine currently available for i5/OS on the System i platform. Before installing Zend Core, you need to install 13 licensed programs included with the System i software package (see Table 1). The introduction of the Zend Core framework for i5/O has greatly simplified installation of PHP on System i computers. Zend's setup tool provides the System i platform with the PHP engine, Apache HTTP Web server, DB2 native support, and Web GUI administration.
The Zend Core product is a free, licensed product. The installation involves creating a SAVF file on the System i and copying the Zend Core to the file in binary. The Zend Core includes detailed instructions with its download from the company Web site (see Resources).
By installing Zend Core, the associated PHP Apache Web server is configured. You can easily perform additional customization of the framework using the GUI administration page through a Web browser. The Zend PHP engine is currently supported only on i5/OS Version 5 Release 4.

Juan Freire: el uso de la Web en la escuela media española

El excelente blog de Juan Freire se ocupa del uso de tecnología Web 2.0 en la enseñanza media española:

(...) en enseñanzas medias, en algunos casos, son las propias instituciones (los centros y las comunidades autónomas) los que han comprendido la necesidad de introducir Internet en la enseñanza y han apoyado estrategias en este sentido. Siendo minoritarias estas iniciativas (y aún más minoritarias las que desarrollan estrategias eficaces), constituyen un cambio cualitativo al constituirse en ejemplos de buenas prácticas que otras instituciones y profesores pueden seguir. Las estrategias de las universidades son, en el mejor de los casos, aún incipientes, en la mayoría inexistentes y, en algunos otros, totalmente perversas al fomerntar estándares cerrados y reducir la capacidad de colaboración

Léalo, y tómelo como una guía de orientación en los esfuerzos por entender el poder de las nuevas herramientas para la construcción de conocimiento. (Como siempre, enlace en el título de esta nota)

Ley de educación argentina casi completada

La semana pasada se concretó el envío de la nueva ley de educación al congreso nacional, en una ceremonia de consenso:

Asistieron los presidentes de la Unión Industrial Argentina, Héctor Méndez; de la Sociedad Rural Argentina, Luciano Miguens; de la Comisión de Educación del Episcopado, monseñor Guillermo Garlatti; de la Asociación de Bancos Argentinos, Mario Vicens, y del Consejo Superior de Educación Católica (Consudec), hermana Gladis Uliarte, además de gobernadores y legisladores. Estaban, además, Hugo Yasky, titular de la Ctera y de la Confederación de Trabajadores de la Argentina (CTA); Hugo Moyano, de la Confederación General del Trabajo (CGT); Juan Carr, de la Red Solidaria; Margarita Poggi, directora del Instituto Internacional de Planeamiento Educativo de la Unesco; rectores de las universidades, y representantes del ámbito académico y de organizaciones de derechos humanos, entre otros.

Este consenso refleja un trabajo previo de consulta de medio año que es mencionado como un gran esfuerzo de millones de participantes por el ministro de educación:

Filmus celebró la posibilidad de encontrarse "en un clima de pluralidad" 180 días después de lanzar, en mayo último, el debate por la ley de educación. "Permítanme creer que están reflejadas las aspiraciones y los sueños de la mayoría de los argentinos en este proyecto de ley que enviamos al Congreso", expresó. Y se refirió "al esfuerzo que han hecho las más de cuatro millones de personas que participaron del debate"

Este período de consulta sin embargo no parece suficiente para lograr un buen debate, sino más bien para consensuar un proyecto ya definido. Dice un editorial de La Nación:

Esta vez, los educadores y los diferentes actores sociales interesados por la educación se vieron involucrados en el debate. En efecto, pareciera que el Ministerio de Educación supo escuchar y tomar debida nota de los aportes y las críticas que la ciudadanía había ido expresando a través de sus organizaciones. Debe destacarse la prudencia y el esfuerzo realizado por el ministro para incorporar distintas posiciones y acordar consensos fundamentales que quedaran plasmados en el articulado de la futura norma en sus dos fases de redacción.
A lo largo de seis meses, pues, se han realizado numerosos actos de difusión y jornadas de reflexión y debate de propuestas, en los que participaron miles de docentes, padres, más de 700 organizaciones de la sociedad civil, sindicatos de docentes y no docentes, y centenares de académicos, intelectuales, dirigentes gremiales, empresarios y representantes de organizaciones de la sociedad civil. Esta original forma de elaborar una norma le otorgará a la futura ley legitimidad social y, además, señala el camino a través del cual deberá aplicársela.

Algunas de las características de la nueva ley:

Un análisis profundo del proyecto presentado muestra que intenta corregir las deficiencias del texto legal que lo precedió, la ley federal de educación, para alcanzar soluciones efectivas y realistas. Entre otras, además de restablecer la tradicional división entre escuela primaria y secundaria, están la recuperación de la responsabilidad del Estado nacional, como garante del derecho a la educación y al conocimiento; la asignación de una inversión no inferior al 6 por ciento del producto bruto, destinada exclusivamente al sector educativo; la escuela secundaria obligatoria, que extiende el total de la escolaridad obligatoria a trece años; la jornada extendida o completa para las escuelas primarias, lo cual permitirá la incorporación de nuevas actividades educativas; la reforma curricular e institucional de la escuela media; la enseñanza obligatoria de una segunda lengua y de las nuevas tecnologías de la información, y se explicitan un conjunto de medidas destinadas a mejorar la calidad de la educación.
También en el articulado se resguarda debidamente la libertad de enseñanza y se restablece la importancia de la formación docente inicial y continua en el nivel nacional.
El proyecto define a la educación como "un bien público y un derecho personal y social, garantizados por el Estado". (...) Fija la obligación del Estado de garantizar la oferta de la sala de jardín de infantes de cuatro años y da carácter vinculante para las provincias a las decisiones del Consejo Federal de Educación. [La Nación, 17-11-06]
Establece el mejoramiento de la formación de los docentes como un factor clave de la calidad de la educación, crea el Instituto Nacional de Formación Docente y admite dos modalidades en la carrera docente, al prever ascensos y promociones sin dejar el aula y en la gestión directiva.

Un aspecto negativo en la presentación: aparece una discordancia representada por uno de los pilares que deberá construír la reforma: la posición de los gobernadores provinciales. La explícita oposición del gobernador de Salta expresa uno de los problemas estructurales que Argentina debe afrontar y resolver: su organización federal, y la independencia, autonomía o aislamiento, según sean las posibilidades de la provincia de que se trate. ¿Quién aplicará la reforma?
Dice el gobernador:

"La letra del documento es dañina para los Estados provinciales ya que sobre sus administraciones cayó la obligación de la Educación cuando en 1991- fueron traspasados los establecimientos nacionales".
En ese sentido, explicó que "el anteproyecto de ley dispone acerca del porcentaje presupuestario que se va a destinar a Educación, con lo cual usurpa facultades de las Legislaturas provinciales, a las cuales les corresponde establecer los respectivos presupuestos anuales de gastos"
(...) [Señaló la intención] de sustituir al legislador provincial del tratamiento de leyes de esta naturaleza. Según interpreta, las mismas suponen la consulta a los Estados provinciales, los que "solamente pueden expresar su voluntad a través de instituciones y no mediante un organismo ad-hoc (el Consejo Federal de Educación) generado en el ámbito del Ministerio nacional de Educación".
(...) No se puede hablar de un sistema educativo nacional porque para consensuar un régimen único resultaría necesaria la creación de la figura de una "ley convenio", a la que pudieran adherir las Provincias: "A partir del momento en que los establecimientos educacionales pertenecen a las Provincias y son dirigidos y mantenidos por éstas, las cuales pagan el sueldo a los respectivos docentes, mal puede hablarse de un sistema educativo nacional".

Bijay Jayaswal y Peter Patton sobre métricas de calidad

Developer publica un artículo sobre métricas de software que tiene la virtud de estar soportado por una visión de la calidad que supera el usual enfoque "especialista". Son destacables tres aspectos: la recuperación de la importancia de los teóricos de Calidad Total (TQM) en los orígenes de la disciplina; la atención dedicada a los problemas de arquitectura (a propósito, los autores entregan también una definición de arquitectura); y la discusión de las métricas específicas al paradigma del análisis y la programación orientada a objetos. Sus puntos principales desarrollados:

• 
  

• Historically software quality metrics have measured exactly the opposite of quality—that is, the number of defects or bugs per thousand lines of code.
• Software is a multidimensional concept that can be viewed from many professional and user viewpoints.
• Two leading firms in customer-focused software quality are IBM and Hewlett-Packard.
• IBM has a proprietary measure set, whereas HP uses five Juran quality parameters.
• The Naval Air Systems Command coined the term Total Quality Management (TQM) in 1985 to describe its own quality improvement program. It soon spread worldwide.
• The four essential characteristics of a TQM program in any field are customer focus, process improvement, quality culture, and measurement and analysis.
• TQM made an enormous contribution to the quality of enterprise software in the early 1990s, just in time for the Y2K transition.
• Until recently, most software quality metrics were of an in-process nature; metrics to support DFTS must be applied upstream in the development process.
• Small programs (less than 100 LOC) exhibit 1.5 defects per KLOC. Large programs (more than 1,000 LOC) exhibit 1.5 defects per KLOC. Medium-sized programs often have only 0.5 defects per KLOC.
• Sophisticated software tools for measuring software quality, such as PAMPA, are beginning to appear.
• OOP goals in software reusability tend to enhance software quality as well.

Breve introducción a las arquitecturas

Dejando de lado las referencias más específicas a Websphere, un artículo de Bobby Wolf en el sitio de IBM dedicado a desarrolladores ofrece una introducción al alcance de las arquitecturas de software. Cuatro aspectos de interés:

• La descripción de las organizaciones con una arquitectura no planificada, espontánea o no-arquitectura.
• La breve historia de las arquitecturas en general adoptadas
• La definición de un arquitecto de IT
• ...y la introducción a las arquitecturas orientadas a servicio (SOA)

En principio, una definición:

The architecture of a system is the highest level of shared understanding of that system by the experts who create it. It is the main parts of the system that need to be understood so that the system, the main components, and how they relate and interact can be understood. An architecture is whatever the expert designers find important at the top level; the architecture drills down into important details while less important ones are determined at lower levels of design. (...)
If the entire system is considered the topmost level of interest, that's the enterprise architecture. If you're focusing on the hardware and low-level software the system runs on, you're concerned about the infrastructure architecture. Even that may be high level for someone focused on the network architecture, in which the network is considered the highest level of interest. Others focus exclusively on the storage architecture. Operations architecture involves keeping the production system running smoothly even during challenges like load spikes and outages.

Una arquitectura no planeada, cae en alguna de estas categorías, según Wolf:

There are three general types of these non-architected architectures, each with its own derogatory yet memorable name:

Big ball of mud (a.k.a. Shantytown) -- This kind of system contains large segments that are unused. Yet the unused parts are so enmeshed with everything else that they're impossible to identify, much less remove.

Spaghetti -- This is a system with no logical flow, where any part may be connected to any other part. In such a case, most of the parts share some dependency on many or most of the other parts, even if such dependencies make little difference to the overall functionality of the system.

House of cards -- With this non-architecture, every part depends on many others, so that a change to one part breaks several, and fixing one problem introduces many more.

Many systems with the properties of one type tend to have the properties of the other two types as well. The figure below shows an example architecture that has characteristics of all three types.

Sobre la historia de las arquitecturas:

The following are major milestones in IT architecture, listed in roughly chronological order:

• Mainframes. The first applications ran on one central computer. Users connected through dumb terminals or teletype machines. Architecture was simple: The application did everything beyond the operating system. For persistence, there was no external database like IBM DB2® or Oracle--the application stored its data in files itself. There were no messaging systems, no GUIs, no shared data, and no interaction between applications.
• Workstations. As desktop computers became common, so did applications that ran on them. These are personal productivity applications like VisiCalc, WordPerfect (now published by Corel Corporation), and the Microsoft® Office applications. These were personal applications; each user ran a locally installed copy and quit it after its use. No data was shared; it was stored in files on local disk and only distributed by sneaker-net.
• Networking. Networks connected workstations to each other, to shared server computers, and to mainframe-style central processing computers. This enabled e-mail capability within an enterprise and sharing files on a file server.
• Client/server. Networking enabled client/server computing, where the application no longer ran completely on a central computer or on a workstation, but was split across the two. Original client/server applications ran on the workstation but accessed centralized data from a database server. Later architectures split the application itself into two parts: a shared component for business logic that ran on the server and local clients that implemented the user interface. The need to host this central business logic led to the development of application servers for running and managing the server part of the application.
• N-tier. A client/server architecture is said to be a two-tier architecture. When the database server runs on a different host computer from the application server, that's a three-tier architecture. As network-based applications became more sophisticated, designers divided the application stack--from the GUI to the database--into more processes on both the client and the server. Such a multiple-tier design became generically known as an n-tier architecture.
• Internet. The Internet is networking on steroids, a global network. The Internet is actually older than the networks in most enterprises, but it was impractical to access it in the business world until an enterprise constructed an internal network that could connect to the Internet. The Internet enabled communications and information sharing not just between users in an enterprise, but between users anywhere in the world.
• World Wide Web. The Web made the Internet graphical. It enabled authors to publish words and pictures--using Hypertext Markup Language (HTML)--as a combined document that could be viewed by anyone anywhere in the world. These HTML documents contained hyperlinks to other documents, so any reference to another document became active and provided the reader direct access to the referenced source. This was the beginning of information on demand, to links being as important as nodes.
• Browser GUIs. The Web introduced HTML browsers for viewing static HTML documents. This paradigm was quickly adapted to provide interactive GUIs for accessing remote applications. This was a return to the centralized computing model. It wasn't actually a client/server model, because practically none of the application ran on the client except for HTML rendering and some simple scripting. Even the validation of input values had to be performed on the server.
• Web services. The Internet was created to connect applications, but the Web connected people to static content and to server applications. Web services use the Web to connect applications so that one application can invoke behavior in another application through a Web connection.
• Web 2.0. This is the application of Web services to Web sites. The user of a Web site is no longer a person, it's another application.
• Service-Oriented Architecture (SOA). Applications have tended to be monolithic, running entirely either on a central computer or on a workstation. Client/server and n-tier architectures distributed application layers; browser GUIs moved the application back to the server. Even with n-tier architectures, this architecture was still rather monolithic because the run-time stack is self-contained; applications at best interacted as peers. SOA divides an application into a service coordinator (the top set of consumers in a composite application) that represents user functionality and service providers that implement the functionality. While the coordinator tends to be unique to a particular application, a service can be reused and shared by multiple composite applications.
• Event-driven architecture. With SOA, the service coordinator explicitly specifies and invokes the desired services. With event-driven architecture (EDA), an application detects an event and emits a notification; other applications have handlers that can receive the notifications and react by invoking services. In this way, the detection application doesn't have to know all the services it should invoke in response to an event; it can simply announce the event and let the other applications decide which services to invoke in response.

La definición de IBM sobre quién es un arquitecto (seis disciplinas):

1. Enterprise architecture. An enterprise architect focuses on mapping IT capabilities to business needs. The architect is responsible for an enterprise's full range of software-intensive systems, including the relationship between multiple applications, data shared between applications, integration of the applications, and the infrastructure to run applications.
2. Application architecture. An application architect focuses on the design of applications to automate business processes and provide functionality that helps users perform business tasks. The architect's responsibilities include designing the application to meet user functional and quality of service requirements including performance, availability, scalability, security, and integrity. Responsibilities also include evaluating and selecting the software and hardware necessary to run the application, as well as the tools and methodologies to develop the application.
3. Information architecture. An information architect focuses on the data used by multiple applications, including the structure, integrity, security, and accessibility of that data. The architect's responsibilities include designing, building, testing, installing, operating, and maintaining the systems for managing that data. Design of these systems must account for data requirements such as source, location, integrity, availability, performance, and age.
4. Infrastructure architecture. An infrastructure architect focuses on the design of hardware and server software including server computers, storage, workstations, middleware, non-application software, networks, and the physical facilities that support the applications and business processes required by the enterprise. The architect's responsibilities include evaluation and selection of these components; modeling, simulating, and testing to validate the designs and selected products; and performance, availability and scalability of the resulting infrastructure.
5. Integration architecture. An integration architect focuses on the design of solutions that enable existing applications, packaged software offerings, networks, and systems to work together within an enterprise or among enterprises. These solutions may use different technologies, vendors, platforms, and styles of computing.
6. Operations architecture. An operations architect focuses on the design of solutions to manage the infrastructure and applications used by the enterprise. The architect's responsibilities include defining plans, strategies, and architectures for the installation, operation, migration, and management of complex information systems.

These architects do not work independently because their domains overlap. The infrastructure architect designs the foundation the systems run on. The application architect designs the programs for users, the integration architect makes sure the programs can be integrated, and the information architect makes sure they have data. The operations architect makes sure it all runs properly, and the enterprise architect oversees all of these aspects and ensures that they all come together.

SOA es desarrollada por separado, en un área completa

Dificultades de las "máquinas de pensar"

Danny Hillis, con excepticismo pero también con entusiasmo, habla en la revista del MIT, de las "máquinas de pensar" y otros mecanismos de análisis complejo:

We look to our own minds and watch our patterns of conscious thought, reasoning, planning, and making analogies, and we think, "That's thinking." Actually, it's just the tip of a very deep iceberg. When early AI researchers began, they assumed that hard problems were things like playing chess and passing calculus exams. That stuff turned out to be easy. But the types of thinking that seemed effortless, like recognizing a face or noticing what is important in a story, turned out to be very, very hard.

Por qué falló en su intento de desarrollar una "máquina de pensar":

Well, the glib answer is that we just didn't have enough time. But enough time would have been decades, maybe lifetimes. It is a hard problem, probably many hard problems, and we don't really know how to solve them. We still have no real scientific answer to "What is a mind?"

Sobre la aplicación de computación a la biología:

TR: You were ahead of your time in applying computation to immunology, genetics, and neurobiology. Today, computation is ubiquitous in biology. What will this mean?

Hillis: I am excited that computational biology is coming into its own. It feels like the field of computing did in 1970. Everything seems pos­sible, and the only constraint is our imagination. There are still so many basic, simple questions that are unanswered: "How are memories encoded?" "How does the immune system have a sense of ‘self'?"

I am especially interested in what will come of computational models of evolution, although I have to admit that the field seems a bit stuck right now. Most current models of evolution reduce it to a very weak kind of search algorithm, but I have always felt that there is something more to it than that. It is not that the biologists are wrong about the mechanisms, but rather that the models are much simpler than the biology. It may be that the interaction of evolution and development is the key, or behavior and environment, or something like that.

"la calidad no es mi problema"

Alan Koch escribe en CM Crossroads acerca de los roles en la construcción de software de calidad, apuntando a un problema común: la separación de funciones diluye la responsabilidad en la obtención de un producto de calidad, y en la raíz del problema está el hecho de que ésta no se obtiene a posteriori, sino que se construye con el producto. Por lo tanto, su obtención es responsabilidad del proceso de construcción en sí (y sus actores):

Testers Don’t Assure Quality
(...) one of the premises for the “Quality is not my job” syndrome is the idea that the testers are responsible for assuring the quality of the product we are building. It turns out that this is not the case. Although the testers’ job revolves around quality, it is more about measuring quality that it is about assuring it.
Yes, testers find problems, which get fixed resulting in fewer problems. But do we ever expect the testers to find all of the defects in the product? We shouldn’t, because the complexity of our systems makes that an unreasonable expectation. The main value of testing is to demonstrate the degree to which the product can be trusted to satisfy the customers’ needs.
There is an important truism that says, “You can’t test quality into the product; it must be built in.” [El subrayado es mío] If quality must be built in, then who should be accountable for the quality of the product? Those who build it are the only people we can look to for a high-quality product. The developers are the source of the quality (or lack there of) that the testers measure.

¿Cómo se debe manejar la calidad? Como una visión global, una cultura de calidad:

A Culture of Quality
While it is advisable to integrate product quality into our developers’ accountabilities, this will work best within the context of a culture of quality. We need an organization that values the quality of what is done just as surely as it values productivity and speed.

In a quality-oriented organization, every individual is conscious of the quality of the end product and their own contributions to it.

• The developers strive for high-quality designs and code, not just for the sake of technical elegance, but mainly so it will satisfy the customer. Rather than slinging code, they carefully engineer a system.
• The Business Analyst strives not just to document the requirements, but mainly to provide the foundation the developers will need to build the right thing. Rather than merely writing a specification, the BA is the liaison between the customer and the developer, assuring that they understand each other.
• The project Manager strives not just to build a good plan and manage activities, but mainly to establish the environment in which the team can build the product the customer needs and deliver it when the customer needs it. Rather than giving orders and demanding results, the pM is enabling each team member to do his or her job well.
• The tester strives not just to find defects and point fingers, but mainly to determine the degree to which the product as it was built will actually meet the customer’s needs. Rather than telling the developers how bad their code is, the tester is helping the developers to do a better job on this project than they did on prior ones.

In an organization like this, no one will say, “Quality is not my job.” Rather, everyone is conscious of the ways in which quality is a part of their jobs.

Las afirmaciones de Koch remontan a los conceptos de Calidad Total, y han recorrido un ya largo camino en la industria. A pesar de las opiniones de muchos desarrolladores, contrarios a las ideas de emplear sistemas "fabriles", encontrarían muchas ideas estimulantes en el estudio de la evolución de los métodos de fabricación de los últimos treinta o cuarenta años (Lean Manufacturing, Just in Time)

Estados Unidos: Alza tecnológica sin burbuja

Cristina Triana publica en El economista de España una nota sobre el alza actual de la cotización accionaria de las empresas tecnológicas en Estados Unidos. Algo que se advierte desde hace algún tiempo, como lo ha demostrado Google, rompiendo la tendencia a la retirada del mercado de acciones. Las cifras comparativas de Triana muestran una situación en general saludable de las empresas, con valores que aún están por debajo de los valores alcanzados durante la burbuja:

(...) Los inversores se encuentran mucho menos dispuestos en 2006 -excepto en el caso de algunas compañías concretas- que hace seis años a pagar cualquier precio por tener en sus manos títulos de una tecnológica, a pesar de que las que resistieron la lluvia de números rojos post 2000 eran las mejores, según los expertos. "El estallido de la burbuja tecnológica propició la desaparición de las compañías que habían surgido y que únicamente se sustentaban en el momento y no en su negocio"

La estrategia de Microsoft en modelado vs MDA

Un importante punto de inicio para discutir otros argumentos. Se trata de un documento de Microsoft de octubre de 2005, que aunque no sea muy reciente, es más constructivo que otros documentos posteriores.

Imagínese Software Factories como MDA incorporado y ampliado, donde MDA se define con un sentido más amplio que la definición oficial basada en PIM y PSM. Software Factories van más allá de la independencia genérica de la plataforma y los modelos específicos. (...)
MDA, según lo define OMG, sólo trata una pequeña parte de lo que creemos que son problemas reales que deben solucionarse para permitir un desarrollo eficaz controlado por modelos.

Incluso resulta de mucho interés la descripción de algunos objetivos deseables en el marco de una mayor rigurosidad en la construcción de software:

¿Qué se debería modelar para un tipo de sistema determinado? Puesto que distintos sistemas pueden tener arquitecturas diferentes, ni un sólo conjunto de modelos puede describir todos los sistemas posibles de forma efectiva. La respuesta a esta pregunta variará entonces según los diferentes tipos de sistemas. En nuestra opinión, un único PIM y un solo PSM por plataforma de destino, desarrollados todos con un lenguaje de modelado de finalidad general, como prescribía MDA, no son suficientes para admitir los niveles considerablemente superiores de automatización que promete el desarrollo controlado por modelos. La automatización enriquecida del ciclo de vida del software requiere numerosos tipos de modelos adicionales como, por ejemplo, modelos que:
• Capturan, analizan y administran los requisitos; identifican las relaciones de seguimiento entre los requisitos, diseño arquitectónico y construcciones de implementación, permiten la validación de que se implementan los requisitos y permiten el análisis del impacto cuando cambian los requisitos.
• Definen la arquitectura del software de modo que admita la seguridad, el análisis del rendimiento y la confiabilidad, así como otras formas de evaluación, de manera que permita un ensamblado de sistemas predecible a partir de componentes y transformaciones paso a paso eficientes y reversibles de requisitos e implementación.
• Definen cómo se empaquetan los componentes ejecutables del sistema, identificando los tipos de recursos del entorno de desarrollo que necesita cada componente y enlazando los componentes a instancias específicas de dichos tipos de recursos.
• Definen casos de pruebas, realizan pruebas en los conjuntos de datos, en el sistema de seguridad y en otros artefactos, de forma que facilitan el proceso de evaluación de la calidad del software desarrollado mediante modelos y la administración y visualización de los resultados de las pruebas.
• Identifican las relaciones de seguimiento entre los modelos y los demás artefactos, de modo que facilitan el análisis del impacto empresarial cuando los sistemas dejan de funcionar, configuran los sistemas para satisfacer los requisitos y aplican limitaciones durante la configuración del sistema.
• Define configuraciones de artefactos de origen utilizados para crear ejecutables, facilitar la creación de versiones de dichas configuraciones y asociar informes de defectos y solicitudes de cambios de características asociados con versiones específicas.

Invariablemente, estos requisitos son vistos como elementos que invalidan el esquema sugerido por OMG, y remiten a la solución de Software Factories como camino acertado, afirmación que a más de un año de este documento sigue siendo una promesa, y una visualización de futuro.
Por eso mismo, insisto en que estas puntualizaciones deben ser tomadas como parte de una lista de tareas para discutir, en un camino convergente de soluciones, donde las realidades de múltiples herramientas practicando sobre las lineas sugeridas por el estándar de Desarrollo Orientado por Modelos de OMG, compitan con las virtualidades de Software Factory, y aún otras propuestas existentes.
Contrariamente a las afirmaciones actuales de los sostenedores de SF, en 2005 el enfoque era más abierto:

Algunas organizaciones que buscan un desarrollo controlado por modelos aceptan una interpretación más amplia del término MDA que la que prescribe OMG; de hecho, como hemos descrito, deben hacerlo para poder lograr el éxito. El uso de cualquiera de las especificaciones de OMG en el desarrollo controlado por modelos se marca normalmente como MDA, incluya o no PIM y PSM. Algunas organizaciones, por ejemplo, consideran la especificación MOF de OMG clave para MDA. Esta consideración se basa en los nuevos lenguajes de modelado definidos con MOF, no los predefinidos en UML, y son similares en efectividad a nuestro enfoque. (...)
Imagínese Software Factories como MDA incorporado y ampliado, donde MDA se define con un sentido más amplio que la definición oficial basada en PIM y PSM. Software Factories van más allá de la independencia genérica de la plataforma y los modelos específicos para tratar los problemas descritos en la sección anterior.

En cuanto a uno de los pilares de MDA, como ya es sabido, la posición era y es la misma:

En resumen, recomendamos el uso de UML y las herramientas basadas en UML para:
• Realizar bocetos.
• Escribir en pizarras blancas.
• Documentación.
• Dibujos conceptuales que no están directamente relacionados con el código.

Recomendamos DSL y herramientas basadas en DSL definidas de forma precisa para:
• Abstracciones precisas con las que generar código
• Abstracciones precisas que asignan puntos de variación en los marcos y componentes.
• Asignaciones precisas entre lenguajes DSL.
• Dibujos conceptuales que tengan asignaciones que se puedan especificar de forma precisa en otros lenguajes DSL o en artefactos de código.

No recomendamos nada de lo anterior en el caso de programación visual de lógica detallada de programas (o por lo menos no hasta dentro de varios años).

Este también es uno de los puntos donde disiento particularmente: No es más ni menos riguroso el mapeo que se ejecute entre un diagrama UML y el código, que el que pueda hacerse entre una herramienta DSL y el código. Esto sin hablar del hecho de que reemplazar el ahora odioso diagrama "genérico" UML por un lenguaje específico de dominio no será una tarea trivial, capaz de poner en manos de un desarrollador medio. Estamos hablando aquí de: o comprar n herramientas "de dominio" para cubrir la articulación de la arquitectura elegida (y resolver su integración), o dedicar un(os) equipo(s) de desarrollo a la forja de los DSL requeridos para el problema específico.
Que el UML como lenguaje no sea suficiente para generar lógica detallada, y que tampoco lo sea un DSL ("No recomendamos nada de lo anterior en el caso de programación visual de lógica detallada de programas -o por lo menos no hasta dentro de varios años-"), es algo que pone la escritura de código "a mano" como parte principal del desarrollo, con lo que no difiere mucho una SF de un marco para la administración de configuración. Sinceramente, los intentos tipo MDA se proponen mayores logros.

El tratamiento post-mortem de un proyecto

Mike Gunderloy dedica un artículo en Developer.com al cierre post-mortem de un proyecto, considerándolo con razón una herramienta de importancia en su manejo en el tiempo, denominándo la técnica "memoria institucional".

Though the name is well-established by now, "postmortem" has somewhat unfortunate connotations. The purpose of a good software postmortem isn't to carve up the corpse of a collapsed software project so as to assign blame for failure (though in dysfunctional organizations postmortems get used this way anyhow). Rather, the goal is to build up an institutional memory and develop a set of best practices that work for your own organization by meticulously recording what went right and wrong over the course of a project.
(...)
The difference between an organization with a culture of postmortems and one without can be dramatic. This is probably in part because of the good effects of postmortems, and in part because companies that lack the discipline to perform postmortems tend to be at a rather chaotic level of practice. When postmortems are institutionalized, you'll find people saying things like "we organize our source code tree this way, because we've found in the past that it works well" or "we stopped using that particular risk assessment practice because it just wasn't giving us any useful information." Without postmortems, developers are more likely to invent techniques as they go along, without much regard for what may or may not have worked in the past - and more likely to be surprised when something fails for the second (or third, or tenth) time.
(...)
Software postmortems, performed consistently, are a key part of bringing a development organization from chaos to smooth, repeatable functioning. In fact, if your development efforts are completely disorganized, postmortems can be a great way to start turning things around, because they will help you identify and keep the good parts while finding and throwing out the bad parts. If you're not already using this essential tool, it's never too late to start.

Gunderloy da nueve sugerencias para su elaboración:
Planear las actividades:

People need to have time to think without being thrown immediately into the next project. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report

No dejar pasar mucho tiempo:

Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the postmortem, rather than waiting for a convenient break in the action (which never comes, anyhow) a month or two later

Registrar los detalles:

Part of the postmortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on. This is not padding, but a way to help people looking for applicable experience in the future. If you build up a library of dozens of postmortems, a team about to embark on a 5-person, 6-month effort can use the project details to look for similar projects that the organization has tackled in the past

Involucrar a todos los participantes:

You need to collect them all to really understand what worked and didn't.

Registrar tanto los aspectos exitosos como los fallos:

It's easy for a postmortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features. But people need to hear positive messages as well as negative ones, and they need to hear what things are worth repeating as well as which things are worth avoiding in the future.

No debe ser un argumento de penalizaciones:

If you want honest postmortems, management has to develop a reputation for listening openly to input and not punishing people for being honest. And the way to get that reputation is by not punishing people.

Establezca un plan de acción:

The written postmortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them

Hágalo disponible:

If you're the one responsible for producing one, you should consider sending out an e-mail at the end of the process saying something like, "The XYZ project postmortem is finished and available at \servershare. We recommend that future teams do a, b, and c and avoid d, e, and f. For more details, feel free to read our whole postmortem."

Software Factory según Chillicoder

Martín Trejo, autor de Chillicoder , dedicó en julio de este año un artículo a Factorías de Software, que tiene la virtud de describir las condiciones que impulsan hacia formas más "industriales" de construír software. Y también una introducción a los recursos desplegados por Microsoft en este terreno, particularmente Guidance automation Toolkit. Continuará...

En Bloginnova:I+D en Finlandia, analizada en Bruselas

El próximo 10 de noviembre se celebra en Bruselas un seminario sobre los recientes instrumentos finlandeses y de la UE orientados a generar un entorno próspero de investigación y desarrollo (I+D) e innovación.
El seminario fue inaugurado por Anita Lehikoinen, Directora del Departamento de Educación y Política Científica en el Ministerio finlandés de Educación, quien habló sobre la estrategia de enseñanza superior de Finlandia como un requisito previo para el rendimiento del país en I+D e innovación, y sobre la necesidad de internacionalizar la estructura de investigación de Finlandia.
El Presidente de la Academia de Finlandia, el Profesor Raimo Vayrynen, también se hizo eco del reto de la «internacionalización», y señaló los recientes esfuerzos de la Academia y Tekes, la Agencia finlandesa de financiación de la Tecnología e Innovación, para situar el sistema finlandés de investigación en la arena mundial.

Java marcha a GPL

Stefan Tilkov, como varios otros, adelanta el anuncio del paso de Java a GNU General Public License v2 (GPLv2). Una gran noticia, de primera importancia para los próximos tiempos.
Algunas repercusiones en Tim Bray, InfoQ, Barrapunto, y especialmente, en Sun.

OOPSLA sobre Domain-Specific Modeling

Juha Pekka Tolvanen anuncia en mda-discussion, que están disponibles los procedimientos y presentaciones del Workshop de OOPSLA sobre Domain-Specific Modeling.

Surgimiento y declinación de CORBA (Michi Henning)

Este artículo tiene varios meses de publicado, pero su análisis sigue siendo válido, no sólo porque es retrospectivo, sino también porque se pueden deducir conclusiones vistas a futuro, especialmente en cuanto a la posibilidad de construír estándares apoyados en consorcios de la industria.
Resumiéndolo a cuatro palabras:
CORBA 2.0 se inició con éxito y popularidad al resolver el problema de desarrollo en sistemas heterogéneos:

It provided a standardized protocol and a C++ language mapping, with a Java language mapping following in 1998. This gave developers a tool that allowed them to build heterogeneous distributed applications with relative ease. CORBA rapidly gained popularity and quite a number of mission-critical applications were built with the technology.

La aparición de Java, por un lado, y el crecimiento acelerado de la Web, presentaron un desafío a la consolidación del estándar:

CORBA provided a Java language mapping, but it did nothing to cooperate with the rapidly exploding Web. Instead of waiting for CORBA to deliver a solution, companies turned to other technologies and started building their e-commerce infrastructures based on Web browsers, HTTP, Java, and EJB (Enterprise JavaBeans).

El estándar resultó complicado de utilizar frente al nuevo escenario:

Many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler (if less flexible), so calls for a CORBA component model became louder and louder.

CORBA resultó además caro y de lento aprendizaje:

Commercial CORBA implementations typically cost several thousand dollars per development seat, plus, in many cases, runtime royalties for each deployed copy of an application. This limited broader acceptance of the platform—for many potential customers, CORBA was simply too expensive.
The platform had a steep learning curve and was complex and hard to use correctly, leading to long development times and high defect rates. Early implementations also were often riddled with bugs and suffered from a lack of quality documentation. Companies found it difficult to find the expert CORBA programmers they needed.

Por otra parte, Microsoft no apoyó CORBA, y desarrolló su propio estándar, con pérdidas por ambos bandos:

Microsoft never embraced CORBA and instead chose to push its own DCOM (Distributed Component Object Model). This kept much of the market either sitting on the fence or using DCOM instead, but DCOM could not win the middleware battle either, because it worked only on Windows.

La aparición de XML transformó el escenario:

Another important factor in CORBA's decline was XML. During the late '90s, XML had become the new silver bullet of the computing industry: Almost by definition, if it was XML, it was good. After giving up on DCOM, Microsoft wasn't going to leave the worldwide e-commerce market to its competitors and, rather than fight a battle it could not win, it used XML to create an entirely new battlefield. In late 1999, the industry saw the publication of SOAP. Originally developed by Microsoft and DevelopMentor, and then passed to W3C for standardization, SOAP used XML as the on-the-wire encoding for remote procedure calls.
SOAP had serious technical shortcomings, but, as a market strategy, it was a masterstroke. It caused further fragmentation as numerous vendors clambered for a share of the pie and moved their efforts away from CORBA and toward the burgeoning Web services market. For customers, this added more uncertainty about CORBA's viability and, in many cases, prompted them to put investment in the technology on hold.

El colapso de la burbuja de Internet, produjo un efecto mortal en CORBA:

The industry's financial collapse drove many software companies out of the market and forced the survivors to refocus their efforts. The result was significant attrition in the number of commercial CORBA products. Before the collapse, several vendors had already dropped or deemphasized their CORBA products and, after the collapse, more followed.

Y lo más importante, las reflexiones de Henning sobre el estándar:

Technical excellence is not a sufficient prerequisite for success but, in the long term, it is a necessary prerequisite. No matter how much industry hype might be pushing it, if a technology has serious technical shortcomings, it will eventually be abandoned. This is where we can find the main reasons for CORBA's failure.

Henning puntualiza los problemas de CORBA:
Complejidad (en el desarrollo de las APIs, en el uso del lenguaje C++, complejidad de tipos usados, especificaciones innecesarias)
Falta de servicios disponibles, Seguridad, Versionamiento, los puntos especialmente señalados:

CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.
(...)
Deployed commercial software requires middleware that allows for gradual upgrades of the software in a backward-compatible way. CORBA does not provide any such versioning mechanism (other than versioning by derivation, which is utterly inadequate). Instead, versioning a CORBA application generally breaks the on-the-wire contract between client and server. This forces all parts of a deployed application to be replaced at once, which is typically infeasible. (This shortcoming of CORBA was another major factor in the rise of SOAP. The supposedly loosely coupled nature of XML was seen as addressing the problem, despite this idea being just as naïve as funneling all communications through port 80.)

La lista de defectos técnicos es más minuciosa, pero no quisiera terminar repitiendo el contenido del artículo, aunque sigo pensando que es mejor esto que perderlos, ya que los textos en Internet suelen ser movidos de ubicación.

Pero Henning destaca otro aspecto del declinamiento de CORBA, que es repetido a través de la corta historia de la construcción de software: la idoneidad o capacidad de la institución promotora del estándar. ¿Evolución a través de la investigación académica? ¿de un consorcio de la industria? ¿de una combinación de empresas, instituciones de educación e investigación? ¿la introducción de nueva tecnología por parte de una empresa?
CORBA contó con el soporte de OMG. Qué critica Henning:

The OMG is an organization that publishes technology based on consensus. In essence, members vote to issue an RFP [Request for proposal]for a specification, member companies submit draft specifications in response, and the members vote on which draft to accept as a standard. In theory, this democratic process is fair and equitable but, in practice, it does not work:

There are no entry qualifications to participate in the standardization process. Some contributors are experts in the field, but, to be blunt, a large number of members barely understand the technology they are voting on. This repeatedly has led to the adoption of specifications with serious technical flaws.

RFPs often call for a technology that is unproven. The OMG membership can be divided into roughly two groups: users of the technology and vendors of the technology. Typically, it is the users who would like to expand CORBA to add a capability that solves a particular problem. These users, in the hope that vendors will respond with a solution to their problem, drive issuance of an RFP. Users, however, usually know little about the internals of a CORBA implementation. At best, this leads to RFPs containing requirements that are difficult to implement or have negative performance impact. At worst, it leads to RFPs that are little more than requests for vendors to perform magic. Instead of standardizing best existing practice, such RFPs attempt to innovate without prior practical experience.

Vendors respond to RFPs even when they have known technical flaws. This may seem surprising. After all, why would a vendor propose a standard for something that is known to suffer technical problems? The reason is that vendors compete with each other for customers and are continuously jostling for position. The promise to respond to an RFP, even when it is clear that it contains serious problems, is sometimes used to gain favor (and, hopefully, contracts) with users.

Vendors have a conflict of interest when it comes to standardization. For vendors, standardization is a two-edged sword. On the one hand, standardization is attractive because it makes it easier to sell the technology. On the other hand, too much standardization is seen as detrimental because vendors want to keep control over the features that distinguish their product from the competition.

Vendors sometimes attempt to block standardization of anything that would require a change to their existing products. This causes features that should be standardized to remain proprietary or to be too vaguely specified to be useful. Some vendors also neglect to distinguish standard features from proprietary ones, so customers stray into implementation-specific territory without warning. As a result, porting a CORBA application to a different vendor's implementation can be surprisingly costly; customers often find themselves locked into a particular product despite all the standardization.

RFPs are often answered by several draft specifications. Instead of choosing one of the competing specifications, a common response of OMG members is to ask the submitters to merge their features into a single specification. This practice is a major cause of CORBA's complexity. By combining features, specifications end up as the kitchen sink of every feature thought of by anyone ever. This not only makes the specifications larger and more complex than necessary, but also tends to introduce inconsistencies: Different features that, in isolation, are perfectly reasonable can subtly interact with each other and cause semantic conflicts.

Major vendors occasionally stall proceedings unless their pet features make it into the merged standard. This causes the technology process to degenerate into political infighting, forces foul compromises, and creates delays. For example, the first attempt at a component model was a victim of such infighting, as was the first attempt at a C++ mapping. Both efforts got bogged down to the point where they had to be abandoned and restarted later.

Estas características pudieran adscribirse a múltiples consorcios. Henning especifica éste para OMG:

The OMG does not require a reference implementation for a specification to be adopted. This practice opens the door to castle-in-the-air specifications. On several occasions the OMG has published standards that turned out to be partly or wholly unimplementable because of serious technical flaws. In other cases, specifications that could be implemented were pragmatically unusable because they imposed unacceptable runtime overhead. Naturally, repeated incidents of this sort are embarassing and do little to boost customer confidence. A requirement for a reference implementation would have forced submitters to implement their proposals and would have avoided many such incidents.

En fin, el análisis de Henning puede verse lateralmente como una historia de CORBA, pero centralmente como una reflexión sobre las intrincadas vías de evolución de la tecnología. Henning dice: "Open source innovation usually is subject to a Darwinian selection process". Sin duda, debemos extender la afirmación al conjunto de procesos de innovación.

José Canosa: la ciencia y la universidad deben cambiar

Lo que sigue es una nota de José Canosa, publicado en Ideas, suplemento de Libertad Digital. Creo que merece que se publique completo, no limitándolo a una referencia, que quizá no sea visitada.
El contenido de la nota debiera ser leído no sólo por españoles, sino también por muchos otros.
Sigue el artículo, completo:

La revolución pendiente de la universidad y la ciencia españolas
Por José Canosa

Estudios recientes muestran la ineficacia de los esfuerzos españoles por lograr un nivel universitario y de desarrollo científico y tecnológico equiparable al de los países desarrollados de nuestro entorno.

Muchos de ellos se centran en cuestiones cuantitativas: presupuestos dedicados a las universidades públicas, porcentaje del PIB empleado en I+D, número de investigadores, estadísticas de graduados y doctores egresados de las universidades, etcétera. Pero las causas fundamentales del atraso secular español son otras: el control político de la universidad y la empresa científica, el régimen funcionarial de los profesores universitarios y de los investigadores de los organismos públicos de investigación (OPI) y el concepto medieval y burocrático de los estudios y títulos universitarios oficiales.

Los sistemas universitarios y científicos de nivel internacional se rigen por valores universales que transcienden todas las culturas. Los más importantes son la independencia plena del poder político y los sistemas estables de autogobierno universitario.

Hay que llevar a cabo una reforma radical y realista que permita implantar gradualmente en España un sistema universitario y científico de nivel internacional. El sistema nuevo debe basarse en sólidos precedentes y en experiencias históricas de éxito, tanto en España como en otros países. Los esfuerzos actuales para reformar un sistema burocrático, disfuncional, politizado y medieval recuerdan a los de Gorbachov por hacer más competitivo y abierto el sistema comunista.

Los datos siguientes ponen de manifiesto la importancia de la calidad de las universidades. Entre públicas y privadas, en España hay más de 70. En Suiza hay 10, todas públicas, de las que sólo cinco son investigadoras. España tiene 143.881 publicaciones en el Science Citation Index del Institute for Scientific Information (ISI), para el sexenio 1994-1999; Suiza tiene 89.176 en el mismo período. Sin embargo, el número de científicos suizos que figuran entre los autores más citados en las revistas científicas y técnicas internacionales se eleva a 74; España cuenta con 11 (datos del ISI). Por otra parte, el promedio de patentes suizas registradas por año en Estados Unidos en el quinquenio 1997-2001 fue de 1.519; el promedio español fue de 154 (United States Patent and Trademark Office, USPTO).

Estos datos demuestran la ceguera de los esfuerzos españoles a la hora de mejorar la calidad del gran número de universidades del país.

El objetivo español debe ser conseguir un número reducido de universidades investigadoras de nivel internacional, y este proceso debe comenzar con una universidad privada sin fines de lucro y con una universidad pública. Éstas serán como faros que iluminarán el camino a otras universidades.

A principios de los 50 se fabricaron los primeros coches en la fábrica SEAT de Barcelona; mientras, Corea estaba inmersa en una guerra que dejaría el país en ruinas. Hoy, Corea exporta coches con marcas y tecnología propias a todo el mundo, mientras que España ensambla los coches de las multinacionales extranjeras. Corea es, asimismo, una potencia mundial en electrónica.

Vista nocturna de la capital de Corea del Sur, Seúl.¿Qué es lo que explica estas diferencias? La visión y la voluntad de los dirigentes del Gobierno y la industria coreanos. Conscientes de las deficiencias de su sistema educativo, en el que las universidades estaban sujetas a rigideces tradicionales y al control de la burocracia estatal, a finales de los 60 el Gobierno decidió crear un nuevo instituto de postgrado especializado en ciencias aplicadas y tecnología, el Korea Advanced Institute of Science (KAIS).

El Gobierno de Corea pidió ayuda al americano; éste mandó a Fred Terman a evaluar el proyecto del KAIS y asesorar al Ejecutivo de Seúl. Terman (1900-1982) es universalmente reconocido como el padre de Silicon Valley y el principal impulsor de la excelencia mundial de la Universidad de Stanford.

En 1971 Terman presentó el informe final de su equipo a los gobiernos coreano y americano. Fue recibido muy favorablemente por Seúl, que puso en práctica sus recomendaciones con rapidez y entusiasmo. Nada se interpuso en el camino: ni tradiciones coreanas ancestrales e intocables, ni "títulos oficiales", ni que el Jefe del Estado firmara los nombramientos de catedráticos, ni otras lindezas medievales análogas. Una de las primeras y más fuertes recomendaciones de Terman fue que el KAIS se liberase del control del Ministerio de Educación.

Los graduados del actual Korea Advanced Institute of Science and Technology se emplean en todos los sectores de la economía nacional, pero sobre todo en la industria. Desde 1981 han fundado más de 360 compañías de alta tecnología.

En aproximadamente la misma época (a finales de los 60) comenzó el despegue de Irlanda, un país conocido durante siglos por su emigración, sus poetas trágicos, sus hambrunas y sus guerras civiles. En menos de una generación Irlanda ha logrado un PIB per cápita superior al de Alemania, Francia y el Reino Unido. Este milagro se basó, entre otras cosas, en la universalización de una educación universitaria gratuita de calidad. Y Gobierno, sindicatos y empresas acordaron un programa de austeridad fiscal, con impuestos corporativos bajos, y otras medidas para la atracción de inversión extranjera.

Los resultados fueron extraordinarios: hoy operan en Irlanda 9 de las 10 multinacionales farmacéuticas más importantes, 16 de las 20 mayores compañías de instrumentos médicos y 7 de las 10 primeras firmas de software.

Esto contrasta con lo que sucede en España, que cuenta con unos 23.000 becarios de investigación (estudiantes de doctorado e investigadores postdoctorales). Todos los estamentos implicados, el Gobierno, las universidades y los becarios, aceptan que la inmensa mayoría de estos futuros doctores están condenados al paro, a menos que el Gobierno les dé empleos públicos. Esto sólo puede hacerse estableciendo veinte universidades más o cuadriplicando el número de investigadores en el Consejo Superior de Investigaciones Científicas, o con una combinación de ambas medidas. De ahí las continuas manifestaciones reivindicativas de estos becarios, que reclaman, desde el comienzo de sus estudios de doctorado, contratos con el Ministerio de Educación con derecho a paro.

La ministra de Educación, Mercedes Cabrera.¿Es posible que España salga de este agujero? Por supuesto, si hay la visión y la voluntad política y empresarial de hacerlo. En primer lugar, hay que eliminar las leyes orgánicas sobre universidades, de una imbecilidad manifiesta, que recogen conceptos inútiles y medievales como el de título "oficial".

La primera universidad científica de Europa, Cambridge, ha nombrado a Emilio Artacho, un físico con el doctorado por la Universidad Autónoma de Madrid (UAM), senior lecturer y fellow de Clare Hall, uno de sus institutos de estudios avanzados. Cambridge no requirió que los gnomos de un ministerio "convalidasen" los títulos del Dr. Artacho para evaluarlo profesionalmente. Por el contrario, si la UAM quisiera ofrecer una cátedra a un doctor de Cambridge, el proceso no podría ni comenzar antes de que los gnomos del Ministerio de Educación español "convalidasen" el título de Cambridge, un proceso arcano que puede durar más de dos años.

Hace un año el Ministerio de Educación tenía en trámite la convalidación de más de 30.000 títulos universitarios. No es broma. Este ministerio controla, con normas del BOE, el progreso de un estudiante en sus estudios de doctorado para decidir si se le renueva la beca. Es verdad. No se les ocurre transferir a la universidad los fondos para que los profesores asuman su responsabilidad natural.

En segundo lugar, hay que abolir el estatus de funcionario para los profesores e investigadores de futura contratación. En una reunión reciente de la Fundación CYD, presidida por Ana Patricia Botín, cuyos objetivos son promover la mejora de la universidad en España, Lluís Ferrer, rector de la Autónoma de Barcelona, manifestó: "Es una vergüenza que todavía haya títulos universitarios oficiales". Luego, sobre el problema del funcionariado, dijo: "Tenemos un economista joven en la universidad que está considerado entre los tres mejores del mundo. Ha recibido tres ofertas de universidades americanas y, claro, no queremos perderlo. Con el sistema actual, su sueldo está fijado por su categoría en el escalafón, y no puede cambiarse".

El rector recurrió a empresarios catalanes, que pusieron sobre la mesa el dinero suficiente para garantizar la permanencia del joven economista. "Esto lo pude hacer una vez, pero claro, no podré resolver nuevos casos de esta manera", adviritó.

Otro ejemplo de los efectos perversos del funcionariado. Juan Ignacio Cirac (flamante premio Príncipe de Asturias de Investigación) es un físico español que hasta hace poco era profesor de la Universidad de Innsbruck. Considerado uno de los mejores teóricos de óptica cuántica, varias universidades públicas españolas trataron de contratarlo, pero no aceptó por la imposibilidad de negociar sobre su salario y otras condiciones. Cirac es ahora director del Instituto Max Planck de Óptica Cuántica, en Múnich.

O sea que, por un lado, no hay medios jurídicos ni económicos para contratar a las promesas jóvenes españolas y, por otro, se ponen 450 millones de euros para el Centro Nacional de Investigaciones Cardiovasculares (CNIC), bajo el mando de una figura de 63 años residente en Nueva York que no tiene ninguna posibilidad de crear una institución de excelencia, tarea que lleva décadas. Piensa volver a España dentro de dos o tres años para ponerse al frente de la institución. Entre tanto, el CNIC ha acordado transferir 5 millones de euros para financiar los Valentín Fuster Laboratories del hospital Monte Sinaí de Nueva York: el plan Marshall al revés.

Dado el marco legislativo actual, en que el Estado se reserva la facultad de otorgar los títulos universitarios oficiales, la única manera de despegar es creando una universidad privada investigadora de nivel internacional que otorgue exclusivamente títulos propios, siguiendo el precedente de escuelas de negocios como IESE, Icade y Esade, las cuales han alcanzado una reputación internacional. Esto les permite atraer estudiantes extranjeros, hasta el punto de que más del 60% de los graduados del IESE no son españoles.

Debido a sus altos costes, un país sólo puede mantener un número muy reducido de universidades investigadoras de nivel internacional. Para establecer una base científica sólida que sirva al despegue tecnológico de un país, dos o tres universidades son suficientes, como muestran los casos de Suiza, Irlanda y Corea.


JOSÉ CANOSA, doctor en Física Aplicada por la Universidad de Harvard, fue investigador en el Centro Científico de IBM en Palo Alto.
Copyright Libertad Digital SA. Juan Esplandiu 11-13, 28007 Madrid.

El ranking de Universidades de Jiao Tong

La Universidad Jiao Tong, de Shanghai, elabora desde hace unos años, una evaluación de las mejores universidades del mundo, desde la mejor hasta el puesto quinientos. No es el único ranking existente, pero es suficientemente valioso, considerando que los principales indicadores están basados en la calidad académica de sus educadores, y los logros de sus alumnos:

We rank universities by several indicators of academic or research performance, including alumni and staff winning Nobel Prizes and Fields Medals, highly cited researchers, articles published in Nature and Science, articles indexed in major citation indices, and the per capita academic performance of an institution.
For each indicator, the highest scoring institution is assigned a score of 100, and other institutions are calculated as a percentage of the top score. The distribution of data for each indicator is examined for any significant distorting effect; standard statistical techniques are used to adjust the indicator if necessary.
Scores for each indicator are weighted as shown below to arrive at a final overall score for an institution. The highest scoring institution is assigned a score of 100, and other institutions are calculated as a percentage of the top score. An institution's rank reflects the number of institutions that sit above it.
Esta es la tabla de criterios:

Criteria	Indicator	Code	Weight
Quality of Education	Alumni of an institution winning Nobel Prizes and Fields Medals	Alumni	10%
Quality of Faculty	Staff of an institution winning Nobel Prizes and Fields Medals	Award	20%
	Highly cited researchers in 21 broad subject categories	HiCi	20%
Research Output	Articles published in Nature and Science*	N&S	20%
	Articles in Science Citation Index-expanded, Social Science Citation Index	SCI	20%
Size of Institution	Academic performance with respect to the size of an institution	Size	10%
Total			100%

Si bien es conveniente leer todas las listas (las quinientas mejores, las cien mejores por continente), el cuadro que resume la participación de países, asociada con su población y su producto bruto nacional, permite tener una visión global de la distancia que separa al mundo desarrollado del resto de la comunidad internacional. No obstante, en el conjunto aparecen países cuya posición implica sin duda un esfuerzo notable por elevar la calidad de la educación y preparación de sus habitantes, así como la ausencia notable de otros:
Este es el cuadro comparativo:

	Top 100	Top 500	Population*	GDP*
USA	53.5%	33.4%	4.6%	28.4%
UK	10.9%	8.6%	0.9%	5.1%
Japan	5.9%	6.4%	2.0%	11.2%
Germany	5.0%	8.0%	1.3%	6.6%
Canada	4.0%	4.4%	0.5%	2.4%
France	4.0%	4.2%	0.9%	5.0%
Sweden	4.0%	2.2%	0.1%	0.8%
Switzerland	3.0%	1.6%	0.1%	0.9%
Netherlands	2.0%	2.4%	0.3%	1.4%
Australia	2.0%	3.2%	0.3%	1.5%
Italy	1.0%	4.6%	0.9%	4.1%
Israel	1.0%	1.4%	0.1%	0.3%
Denmark	1.0%	1.0%	0.1%	0.6%
Norway	1.0%	0.8%	0.1%	0.6%
Finland	1.0%	1.0%	0.1%	0.5%
Russia	1.0%	0.4%	2.3%	1.4%
Belgium	0.0%	1.4%	0.2%	0.9%
China	0.0%	1.8%	20.4%	4.7%
South Korea	0.0%	1.8%	0.8%	1.6%
Spain	0.0%	1.8%	0.7%	2.5%
Austria	0.0%	1.4%	0.1%	0.7%
China-Hong Kong	0.0%	1.0%	0.1%	0.4%
China-Taiwan	0.0%	1.0%	0.4%	0.7%
Brazil	0.0%	0.8%	2.9%	1.5%
Singapore	0.0%	0.4%	0.1%	0.3%
Argentina	0.0%	0.2%	0.6%	0.4%
Mexico	0.0%	0.2%	1.6%	1.6%
New Zealand	0.0%	1.0%	0.1%	0.2%
South Africa	0.0%	0.8%	0.7%	0.5%
Ireland	0.0%	0.6%	0.1%	0.4%
Czech	0.0%	0.2%	0.2%	0.3%
Greece	0.0%	0.4%	0.2%	0.5%
Hungary	0.0%	0.4%	0.2%	0.2%
Poland	0.0%	0.4%	0.6%	0.6%
India	0.0%	0.4%	17.0%	1.7%
Chile	0.0%	0.2%	0.3%	0.2%
Egypt	0.0%	0.2%	1.1%	0.2%

Universia apunta varios de los informes de evaluación existentes a nivel internacional, con mención especial de algunas existentes en el mundo iberoamericano. Puede consultarlos en su sitio.