Chile mencionado por Dr Dobb's

La publicación Dr Dobb's dedica un artículo a los proyectos y esfuerzos para colocar a Chile como plataforma de outsourcing de corporaciones de todo el mundo. A la conocida presencia de Yahoo en Santiago de Chile, David Gardner agrega la entrada de Tata Consulting:

Chile views itself as a potential IT outsourcing tiger, and while it has been working hard to convince U.S. companies of its outsourcing expertise, it may have found a surprising supporter -- India's outsourcing giant Tata Consulting Services (TCS.)
"TCS likes Chile because we are in the same time zone as the U.S.," said Constanza Donoso, a representative of the Chilean Economic Development Agency, in a brief interview. "Tata provides financial services to U.S. customers from Chile."

Gardner destaca el incremento en fondos para investigación y desarrollo:

The new drive, said Donoso, comes from the country's new President Michelle Bachelet, who has pledged that Chile will increase its research and development spending by 50 percent. The country is setting aside $200 million this year from mining taxes to invest in high technology; the figure is likely to grow to $350 next year, officials said.

Varias compañias, particularmente estadounidenses, establecieron servicios en Chile:

Several U.S.- and Europe-based companies have located service operations in Chile's major cities primarily to serve Latin American customers. These include Delta Air Lines and Air France reservations operations as well as customer service units run by Citigroup, JPMorgan, Unilever and Zurich Financial Services.
Particularly prized are U.S. technology companies, which will carry out sophisticated research and development in Chile. Synopsys, a California-based provider of semiconductor design, has opened its first design center in Latin America in Santiago. It plans to expand the software engineering group to 60 by 2009.
Yahoo has established an Internet Research Lab where the PhDs it has hired develop mathematical algorithms that will facilitate Internet searching. General Electric's International Center of Excellence in Chile has hired many software developers. Software AG, a German company with a large presence in the U.S., develops enterprise software for government and businesses from its XML operation in Chile.
Businesses are increasingly attracted to Chile's high literacy rate (96 percent) and the growing number of Chileans who speak English (7 to 8 percent), Donoso said.

Acoto por mi parte, que, como en otros aspectos, es destacable el esfuerzo conciente y concertado puesto en marcha para lograr este objetivo. Como en otro artículo se apunta, Chile debe mejorar en varios frentes sin embargo para poder concretar un buen resultado de carácter más o menos permanente: la existencia de trabas administrativas a la operación de actividades extranjeras, poca existencia de servicios de respaldo, no mucha difusión de lenguas extranjeras -a pesar de lo indicado en el artículo-. Sin embargo, Chile no ha dejado de obtener buenos resultados, uno tras otro, a fuerza de continuidad y claridad de objetivos.

Un informe sobre fatiga mental en educadores argentinos

Infobae publica hoy un informe de la Escuela de Trabajo Social de Universidad Nacional de Córdoba impulsado por la Unión de Educadores de la Provincia de Córdoba para conocer el estado de salud de los docentes. Si bien puede ser calificado de parcial, aporta números que incluso lateralmente son de interés, y que debieran servir para mejorar la preparación de estadísticas sobre el sector.
El problema:

"uno de cada cinco de los más de 55 mil educadores en actividad", presentan síntomas de burn out o "cabeza quemada".
Se trata de un síndrome de cansancio emocional, despersonalización y falta de realización profesional que afectan la tarea educacional.
La patología, común entre los cirujanos y profesionales expuestos a altos grados de tensión, implica la pérdida de recursos emocionales para enfrentar el trabajo.

Los números:

El 21,7 por ciento de los docentes presentó síntomas de cansancio, fatiga, manifestaciones psíquicas y físicas y sensación de no poder dar más de sí.
El 27,5 por ciento manifestó actitudes negativas, distantes y cínicas hacia sus alumnos.
El 20,8 por ciento presentó bajo rendimiento y autoestima y sensación marcada de frustración.
(...)
Los docentes que presentan síntomas de burn out son mayoritariamente mujeres, de entre 31 y 50 años con más de 161 alumnos a cargo y con una antigüedad de entre 11 y 15 años.

Subrayo el último número: ¿más de ciento sesenta y un alumnos a cargo? ¿qué significa eso?¿que un maestro/profesor atiende mensualmente una clase/dos o tres clases de ese promedio aproximado de alumnos? ¿que recorre cuatro escuelas semanalmente?¿y esa cifra supera al diez por ciento de los educadores?.

Steven Kelly, DSL, y Charles Simonyi

Steven Kelly, participante en OOPSLA como miembro de MetaCase, comenta a Simonyi, quien comenta a las herramientas DSL:
He asked a good question:

"If DSLs are so useful, and so incredibly efficient, and have been around for so long, why isn't everybody already programming this way?" He gave three answers:

* building good languages is hard
* designing parsable languages can be hard
* building editors for the language is expensive"

Responde Kelly:

I'd agree with the first, but graphical DSMs and a meta-tool like MetaEdit+ or GME have solved the latter two problems over ten years ago. One of the questions at the end pointed this out to him. For the first, good tools can help, but the real answer is simply that building a language is a task for an expert developer. It's hard even then, but it's doable and is the best possible use of the expert's knowledge and skills.

Kelly discute también el enfoque de Simonyi para su propio desarrollo:

Intentional have changed the name of their future product to "Domain Workbench", borrowing consciously from Martin Fowler's term "Language Workbench" (and you can look at MetaEdit+ Method Workbench for a possible hint of where the lovable jackal got that particular piece of carrion). The main focus is on providing different views on the same program -- different projections of the same tree-like representation of the program in their repository.
I'm all for different representations (my first work on MetaEdit+ was building the Matrix Editor). But Intentional's idea is to be able to switch between different representations on the fly, and that's not a good idea. The human brain pays a significant cost each time the format shifts in that way -- just like switching between two spoken languages. Additionally, we build up maps in our mind of our code, and automatically laid out code breaks some of those maps -- even more so if you switch between several different representations.

Sobre Metacase: Metaedit+

Booch necesita secretarios

Si usted tiene tiempo, es buen conocedor de OOD y patrones, maneja bien el inglés, y es analítico para trabajar, tiene una magnífica oportunidad de participar en un proyecto valioso: Grady Booch no puede abarcar sólo su proyecto, y ha lanzado una invitación a colaborar con él, en su Handbook.

El futuro del diseño, en veinte años

Volviendo a Lambda, the ultimate, Peter Van Roy escribe dos líneas sobre el futuro del diseño, sugiriendo vías de evolución, y proponiendo un modelo:

What will programming look like in 20 years? Maybe it will be based on a "definitive language" like the speculations of the article Convergence in language design: a case of lightning striking four times in the same place (FLOPS 2006). Such a language will have a layered structure and its handling of concurrency is important. (Whether it is dynamically or statically typed is of absolutely no importance, BTW.)

How will we program with such a language? Maybe we will program with feedback loops, as explained in Self management and the future of software design (FACS 06). This seems to be one way to handle complexity, the inevitability of software and hardware faults, and managing global behavior of a system. I am coordinating a new project, SELFMAN, that is looking at this.

Extraído del papel de Van Roy mencionado:

We propose to build self-managing software systems as sets of concurrent agents interacting by means of asynchronous events and implemented using a component model with first-class
components and component instances. In this framework, self-managing systems are built as hierarchies of interacting feedback loops. The first design rule is that the whole system (except perhaps a small kernel) should be inside a feedback loop.
Feedback loops interact through two mechanisms, stigmergy (shared environment parameters) or management (one loop controls another). The feedback loop structure is designed to provide a desired global behavior. This behavior should also be predictable from the loop structure. We relate this proposal to two other architectures, namely the Erlang fault-tolerance architecture and the subsumption architecture for implementing intelligent behavior.
These ideas are being realized in SELFMAN, a project in the European 6th Framework Programme that started in June 2006 [27]. We intend to elaborate these ideas into a programming methodology together with an implementation. It should be as easy to program with and reason about a feedback loop as it is for an object or a component. We will design and formalize a component model that is based on the Oz kernel language extended with elements from the Fractal model.
We will use this component model as the basis of a programming model along the lines of Section 5 and implement this model in Mozart [26,9,13,23]. We will build a feedback loop architecture on top of this implementation and use it to implement a self-managing replicated transactional storage service.

Otros puntos de vista en la misma línea pueden verse en Paradigmas.

Eric Kimberling: buen material sobre implementación de ERP´s

Eric, miembro de Panorama Consulting Group LLC, colabora frecuentemente con IT Toolbox, un sitio excelente para conocer, aprender e investigar sobre el desarrollo e implementación de aplicaciones de empresa (lo que abarcan usualmente las siglas ERP, Enterprise Resource Planning, y EAI, Enterprise Application Integration).
En el último tiempo, son destacables sus artículos "The hidden costs of ERP", y "Why Are ERP Projects Always Over Budget?", centrados en el manejo de la implementación de estas aplicaciones verdaderamente complejas.
Sobre costos ocultos:

1) Internal company resources to make decisions on ERP requirements, help with system design, and perform testing. Aside from a full-time core team, most ERP projects require the involvement of 3-5 part-time subject matter experts for each full-time core team member.

2) Internal or external resources to manage data conversion, interface development, and report generation. Getting the system implemented is a huge milestone, but not if you haven't converted data or built the right interfaces and reports.

3) Employees to support communications, training material development, and training deployment activities. Many assume that the implementation consultants will handle this, but company employees also need to provide much of their time in helping develop materials and deploy training.

4) Time that senior management is involved in decision-making and conflict resolution. In a perfect world, employees across all office locations and geographies would be able to make decisions that everyone agrees with and that is best for the business overall. Unfortunately, in reality, senior management is often required to make decisions on behalf of the business, prioritize business needs, and provide strategic direction to ensure the project is aligned with overall business goals. There are costs associated with this time, and it should be quantified accordingly.

5) Design of business processes, particularly if the project involves a large, multi-national company with fragmented operations. ERP presents an opportunity to standardize and globalize operations across multiple locations, so arriving at a common operating model takes time and resources. It should not be assumed that the software itself will provide all the answers; business users need to decide how they are going to best leverage ERP to run their operations in the future.

6) "Backfilling" project team members with contract or other employees to manage day-to-day activities for the project team members who are no longer able to commit to their usual day-to-day jobs. It shouldn't be assumed that the business will continue to run as normal without replacing people that are devoting their time to the project.

7) Travel and expenses for team members, particularly if dealing with a global project. Project budgets should assume at least 15% of total consulting costs for travel, then double this amount to account for internal project team travel.

Sobre el incumplimiento de plazos y presupuesto:

1) Ensure executives outside of IT are involved in the vendor evaluation and planning process. Having more executives involved will help the management team identify all the hidden costs and benefits of implementing ERP.

2) Take your time during the ERP evaluation and project planning phase of the process. Too many companies rush into ERP as if the world is going to end without it, and they don't take the time to clearly lay out their business requirements, thoroughly evaluate the various vendors, and plan for a successful project. Any company that is serious about making their ERP project successful should spend at least 3-6 months on the selection and planning process, and possibly even more for companies that take longer to make decisions or are over $200 million in revenue.

3) Develop an actionable, realistic business case. A business case should be used for more than just convincing top management to approve the project. It should also be used to identify and manage operational business benefits and key performance indicators during and after the implementation.

4) Develop a realistic project plan and implementation timeframe. It may seem obvious that you won't know your true costs until you develop an implementation plan, but too many companies try developing an estimate before a plan has been identified. This is a huge recipe for a significant cost overrun.

5) Be open to the fact that it might not be time for ERP. Many may find this concept blasphemous, but even companies with the most manual processes and outdated technologies may not be suited for ERP. Perhaps a better and more cost-effective solution will help, such as business process improvements, best of breed software, etc.

Pero también son valiosos los comentarios de los lectores:
Sobre los costos ocultos, Yangoh dice:

The hidden costs have a lot to do with something like "putting the cart before the horse" syndrome. The industry norm is to engage ERP systems integrators and implementation consultants to help speed up the goal of "going life" without having any cultural revolution. The work culture may have to be changed drastically in order to adopt the new ERP systems.
It is definitely important to have SCM management education and training priot to ERP implementation, so that the business processes may have to be re-designed, improved and fine-tuned.
Due to the costs of consulting on a per man-day basis, in a lot of cases, it is not uncommon to try to reduce the number of man days to "going life". In many instances the life span of the ERP systems implemented with the compressed and expedited project timeframe can become very short, simply because more often than not the key users may revert to their old ways of doing things if the system does not suit them.
If only enterprises have the proper SCM education and training prior to purchasing a major ERP systems, then the costs of business transformation may be reduced drastically. It can also be true that sometimes it may not be necessary to change the systems at all, if only proper business process systems synchronisation (www.mpicsdb.blogspot.com) has been sorted out.
The other problem is the obsession with brand name ERP rather than going for the best in class or best of breed application solutions. In any case, operations management is still perceived as an art, so many enterprises can try new business practices but with the entrenched deep-rooted time-tested culture and processes.
The people factor is the least priority with some implementers forcing their way through the configuration of the ERP systems without getting the buy-ins and the approval of the key users.
If we use ERP as the enabler, then getting the business processes sorted out and synchronised should be the top priority besides looking at the opportunity for simplification and standardisation.

Sobre el exceso en presupuesto, Doug Hadden

I wonder whether the ERP industry suffers from the "blame the victim syndrome". Don't get me wrong, this advice is realistic. But, the solution to the ERP implementation problem seems to be generic - how to run large complex projects. Project Management 101. Isn't there something that the ERP vendors themselves can do to reduce the risk of going over budget?
Every time an ERP vendor reacts to a failed or late implementation, they point out that the customer's schedule was unrealistic - there weren't enough trained staff members - business processes presented by the client weren't accurate - there wasn't a long enough testing period (and so on). All of these are absolutely correct - in context to the ERP vendor's business model. When will these vendors smarten up and find ways to reduce the risk? Or, are they making too much money to change and upset the value chain? Possibly they are too focused on features or integrating acquisitions rather than worrying about usability, time to results, sustainability etc. Perhaps making ERP more complex increases switching costs. Don’t you wonder what would happen if ERP companies spent as much on simplification as they do on marketing?
On the other hand, to what extent are the victims responsible for predatory behavior? There’s more than enough evidence that ERP implementations are fraught with danger to know that vendors leverage hyperbole during the sales process. How can any responsible organization enter into an ERP contract without knowing these well-publicized risks?

La educación en Argentina

Las cifras de la educación son bastante aceptables, vistas por sí solas; consultando las estadísticas de la UNESCO sobre Argentina, los números muestran un país bien preparado. En estos días, justamente, un informe destaca sus aspectos positivos en el contexto latinoamericano. Sin embargo, para cualquiera que conozca las cifras más de cerca, esto no puede conformar, ni mucho menos.
Dado que el Ministerio de Educación redacta un proyecto de Ley de Educación, es ahora la época oportuna de puntualizar problemas y ofrecer soluciones. En los próximos meses, se irán acumulando aquí apuntes que puedan servir en algo. Quizá sean sólo impresiones, pero esperando que a alguien le interesen y se sume.
Para comenzar por algún lado, quisiera remitir a los dos artículos escritos antes sobre Chile, en los que se menciona la educación más de una vez. Algunos de los elementos que valoro allí no son mensurables en un párrafo de una ley, o no veo cómo lo serían: por ejemplo, la preocupación nacional por el resultado del exámen de aptitud que habilita para la Universidad, tanto de los estudiantes de escuela media, que sus últimos dos años están masivamente dedicados a su preparación, así como a enterarse de las distintas oportunidades que ofrecen las universidades o escuelas de formación terciaria, como de las escuelas, que desarrollan planes orientados a preparar para el exámen, o los padres, que siguen de cerca esa preparación.
Releyendo lo que escribo, creo que sí se pueden decantar elementos para una ley:

• El exámen nacional es obligatorio (en algún momento trataré el español). No es viable entrar a una universidad estatal sin pasar por ese exámen, que establece prioridades en base al puntaje y las vacantes disponibles. Se establecen listas de espera de los matriculados que se resolverán por el orden de precedencia de los resultados.
• Los últimos dos años tienen un aspecto de preparatorio para la admisión: así, una serie de actividades están programadas para capacitar, por un lado, y para hacer conocer la oferta de estudios. Existen dos o tres ensayos del exámen durante este período.
• Las escuelas son valoradas en base a los resultados de sus alumnos. Existe un ranking de calidad de las escuelas que es leído por todos.
• El rendimiento de las escuelas no sólo se sigue por este medio, sino por examinaciones periódicas de establecimientos y educadores.
• Las universidades ofrecen sus servicios en las escuelas; no esperan pasivamente la inscripción, sino que salen a dar a conocer sus especialidades.

Aquí no estoy hablando de la calidad del contenido de esa enseñanza, que no conforma ni a los propios chilenos, sino de la vía en la que se construye. Considero que sobre una base racional, el contenido es mejorable. Pero una base caotica desperdicia el trabajo.
Soy conciente que un exámen es limitativo, y que es muy cuestionado en Argentina. Pero sin un exámen de admisión se produce un período muy estéril inicial, que es bien conocido por el caso de la Universidad de Buenos Aires, obligada a mantener una estructura especial (el CBC-Ciclo Básico Común) para atender a miles de postulantes en una primera etapa que se supone que es orientativa: el trabajo que debiera cubrirse en el período anterior. Pensar en un curso de un año que sea nivelador, es ocultar el problema de la insuficiencia del período previo. De todas formas, puede tomarse al CBC como un exámen de ingreso, algo que pudiera servir para proponer un plan que mejorara el período de transición hacia estudios superiores o especializados.

Los números de las estadísticas marcan rasgos gruesos del nivel de instrucción, pero no conforman cuando se conoce la sociedad: no hablan en detalle de la calidad, ni de la profundidad de los conocimientos adquiridos. De esto hay que seguir hablando, y proponiendo...

Conferencia anual de JAOO

Para tener en cuenta: reunión 2006 de la European Conference on Java and Object Orientation. Suele reunir personas y materiales de verdadero interés. Especialmente, vale esto para el blog de la Conferencia

Parque tecnológico de la Universidad Austral y Taurus

El 19 de octubre se presentó en Pilar, provincia de Buenos Aires, un nuevo parque tecnológico, promovido en este caso por la Universidad Austral y la empresa alemana Taurus. El anuncio del proyecto cuenta a su favor con la consistencia de otros proyectos anteriores, incluída la Universidad misma, que es una de las más recientes establecidas en Argentina. El proyecto en las noticias:
En CanalAr:

La inversión inicial demandará unos 14 millones de dólares, pero las autoridades de la universidad dijeron que ascenderá a unos 150 millones de dólares hacia el final del proyecto, que contó con la ayuda de Taurus, un reconocido operador inmobiliario a nivel mundial. La idea es que haya una excelente correlación entre la universidad, la empresa, la inversión privada y los programas públicos de desarrollo.
Débora Georgi, ministra de la Producción de la provincia de Buenos Aires, estuvo en la presentación y aseguró que esto representa una sinergia entre el crecimiento industrial y el avance tecnológico en el país. Al respecto, subrayó que en las cercanías de Silicon Valley, en Estados Unidos, se encuentra la Universidad de Stanford. De éste modo destacó la articulación de un proceso compatible con la necesidad del pequeño y mediano empresario orientado al sector de la investigación.
Con igual sentido, el rector de la Universidad Austral, José Alejandro Consigli, explicó: “Es un emprendimiento que acorta la distancia entre la universidad y la empresa porque permite una interacción con la demanda de investigación que tienen actualmente las empresas. Por esa razón, la institución facilita parte de su terreno para que los inversores construyan edificios que luego se alquilarán a las firmas que se instalen”.
El académico agregó: “El interés de una empresa que quiera participar en el proyecto es que va a tener profesores e investigadores. Contará también con algunos laboratorios de la universidad y con alumnos para realizar pasantías. Indudablemente, son carreras afines a las necesidades de una firma, pero no necesariamente. Habrá algunas que se instalen por los beneficios impositivos que otorga la Municipalidad de Pilar o la Provincia. Con el tiempo terminará constituyéndose en un polo tecnológico”.
Finalmente, Peter Merrigan, CEO de Taurus, afirmó: el Parque es una plataforma única que concentrará inversiones para toda la región y pone a la Argentina al nivel de las naciones más avanzadas. Al igual que otros ejemplos exitosos en el mundo, es la unión de esfuerzos que reunirán un capital intelectual muy valioso en la región, en un ámbito de seguridad, con la estructura edilicia y servicios de última generación”.

En Infobae:

El parque tecnológico, científico y empresarial que se construirá en 27 hectáreas del campus de la Universidad Austral en Pilar requirió una inversión inicial de 14 millones de dólares de parte de la empresa Taurus, que levantó 120 emprendimientos similares en Estados Unidos y Europa.
El proyecto fue presentado ante unos 300 empresarios de diferentes actividades, con la participación de la ministra de Producción de la provincia, Debora Giorgi y el rector de la Universidad Austral, José Alejandro Consigli.
Consigli destacó que el proyecto comenzó a gestarse en 2000, pero desde hace dos años el interés de Taurus, le dio un nuevo impulso, beneficiado además por el entorno de recuperación y crecimiento económico en el país.
El académico fundamentó la importancia de levantar un centro en el que "se desplieguen las sinergias entre la universidad y el sector empresarial" y enfatizó el apoyo que encontraron en el Estado, tanto a nivel municipal como provincial y nacional.
El presidente Néstor Kirchner envió una carta a las autoridades de la Universidad a quienes felicitó por la iniciativa y sostuvo que las acciones de investigación y desarrollo incrementan la competitividad de las empresas y apuntalan el crecimiento del país y de la región.
El proyecto ideado por Taurus prevé que en el segundo semestre de este año las primeras empresas ya podrán instalarse en el predio donde por ahora trabajan en el suelo y el despliegue de la infraestructura de servicios.
Si bien hoy se concretó la presentación formal, el presidente del Parque Austral, Fernando Ambroa, señaló que ya recibieron el interés de veinte empresas entre las que se cuentan multinacionales y nacionales dedicadas al desarrollo de software, telecomunicaciones satelitales, laboratorios medicinales y de la industria automotriz.
La intención es albergar hasta 100 empresas, con una inversión final del proyecto por 150 millones de dólares y prevén que se generarán al menos 8.000 empleos calificados.

En Clarín:

Ese predio podrá albergar a empresas de biotecnología, agroalimentos, automotrices o de software, entre otras especialidades, según comentó Fernando Ambroa, presidente del Parque. El directivo señaló que ya hay una veintena de empresas interesadas en sumarse al proyecto.
La inversión inicial de la obra —de unos 14 millones de dólares— va a provenir de la operadora inmobiliaria alemana Taurus, asociada a este emprendimiento. Esta firma debuta, así, en el mercado local aunque maneja negocios similares en Estados Unidos, Canadá y Europa. Es, por ejemplo, socia mayoritaria del Parque Tecnológico de Orlando, en EE.UU..
"En este caso, en el polo de Pilar, no hay venta", explicó Ramiro Julia, presidente de Taurus Argentina. "Las empresas alquilan el edificio, a un costo que es sustancialmente menor al de cualquier oficina en la Capital Federal y similar a los alquileres de la zona: unos 14 dólares el metro cuadrado", dijo.

En La Nación:

Al acto asistieron representantes de más de 300 empresas, entre ellos de Molinos, la farmacéutica Boehringer Ingelheim y Hewlett Packard. También estuvieron presentes autoridades municipales y provinciales que anunciaron ventajas impositivas para las empresas que se radiquen en el parque.
La ministra de Producción bonaerense, Débora Giorgi, anunció durante el acto la firma de un decreto por parte del gobernador, Felipe Solá, que declara de interés provincial la iniciativa.
También sostuvo que será acogido por la ley de promoción industrial de Buenos Aires, que aguarda ser sancionada en la Legislatura provincial y que acarrearía exenciones en el pago de sellos, ingresos brutos y rentas. Por último, destacó la necesidad de brindarles la posibilidad a las pymes para que se integren a estos emprendimientos. De esa forma, dijo, podrían acceder a tecnología y servicios que no pueden financiar por sí mismas. "Queremos que las pequeñas y medianas empresas se transformen en grandes y las grandes, en multinacionales", dijo.
A su turno, el intendente de Pilar, Humberto Zuccaro, anunció que las empresas que se instalen en el predio quedarán exentas del pago de la tasa municipal.
Mediante una carta, el presidente de la Nación, Néstor Kirchner, de gira por Bolivia, destacó el proyecto y señaló que el parque "se transformará en un espacio de investigación y desarrollo, mejorando así su competitividad y contribuyendo al desarrollo económico de nuestro país y de toda la región".
Juliá celebró la misiva del Presidente y tibiamente dejó entrever qué esperan de la Nación: "El apoyo del gobierno nacional a esta iniciativa es muy importante, porque los países ven estos proyectos como infraestructura estratégica y brindan créditos blandos o subsidios directos, como pasa en Uruguay o Brasil".

El parque se une así a otras iniciativas anteriores, en general emprendidas en colaboración entre Universidades estatales y sectores privados de la tecnología, como los de Tandil, Córdoba y Rosario. La Universidad Austral posee otras instituciones de punta, como la Escuela de Negocios, que, por ejemplo, permitió difundir APICS en Argentina.

Un blog finlandés activo en MDA y SF

Aali Likoski, desarrollador .NET en finlandia, mantiene en MSDN un activo blog, en la línea de Microsoft sobre Software Factories, pero con un punto de vista más abierto sobre MDA. Al menos, es lo que se puede concluír sobre sus entradas en inglés... (mi finés está en la lista de espera).

Al negocio del software en Argentina le faltan ingenieros...

En La Nación, el 12 de octubre:

Representantes de la industria informática y del Ministerio de Educación lanzaron ayer la segunda versión de la campaña para incentivar la inscripción de alumnos en las carreras universitarias de sistemas. Pese a que la industria tuvo un fenomenal desarrollo en los últimos años, el número de egresados e inscriptos en las carreras informáticas y afines no es suficiente para cubrir los puestos que las empresas requieren.
Actualmente, sólo un 5% de los estudiantes universitarios cursa carreras vinculadas con la tecnología.
(...)
Según las estadísticas del sector, la industria de desarrollo de software viene creciendo a un ritmo del 20% anual, en promedio, en los últimos tres años. En 2006 proyecta facturar $ 4800 millones, un 20% más que en 2005 y exportará por 300 millones. Actualmente, la industria de software emplea cerca de 50.000 profesionales. Además, ya hay trabajando 14.000 profesionales directamente para exportación de software.

Acciones que tensan las paradojas argentinas...En vísperas de una nueva ley de educación, sería fundamental planear las bases de políticas duraderas, de décadas de alcance, antes que golpes de timón en la tempestad.

Cómo MDA incrementa la productividad

Este comentario es una actualización de otro hecho en los inicios de este blog, sobre un análisis de productividad de Middleware Research, comparando un desarrollo utilizando una herramienta MDA contra otro equipo utilizando herramientas "estándar". Al volver sobre el tema a propósito de otra discusión, encontré que el enlace era inhallable. Concluyo que, a pesar de que fuera redundante, es preferible citar textualmente y desarrollar el comentario, en lugar de remitir al original. Es que Internet es demasiado fugaz, y las referencias y citas basadas en enlaces no son muy confiables. Trataré de tomar esta observación en el futuro. Y ahora, reponer el artículo...
The Middleware Research era una compañia dedicada, entre otras cosas, a la investigación y evaluación de software. Para el 2004, todavía aparecía como parte de The Server Side, pero hoy, siguiendo el enlace de su artículo, lo que se encuentra es esto:

As of November, 2004, The Middleware Company and its Middleware Research business unit have been discontinued. TheServerSide.com, TheServerSide.NET and related conferences are continuing operation as part of the TechTarget network. The Torpedo O/R benchmark has been moved to: http://www.torpedo-group.org, and the SOA Blueprints initiative now lives at: http://www.soacenter.com

Para quien le interese, todavía puede encontrar materiales disponibles en sus nuevos alojamientos. En el caso del informe de productividad de MDA, luego de varios intentos, lo localicé en el sitio de Compuware. Compuware, que también sufrió cambios desde 2004, no lo menciona como un papel destacado, quizá porque no cuadre enteramente con su producto -OptimaJ- al día de hoy.
Cuá era el propósito del estudio:

In the spring of 2003 The Middleware Company performed and published a study testing whether development tools taking a Model-Driven Architecture (MDA) approach increased the productivity of developers building a new J2EE application. That study found that MDA increased productivity 35% over a traditional, code-centric approach.
This study extends the examination to the realm of application maintenance. Two teams performed a set of typical and diverse enhancements to an existing application. One used an MDA -based tool, while the other team used a code-centric approach with a traditional enterprise-caliber integrated development environment (IDE).
The team taking the MDA approach completed the five enhancements 37% faster than the traditional team, in 165 hours versus 260. These results are well in line with those of the first study. As a result of this case study, The Middleware Company reinforces its recommendation that development shops interested in increasing their productivity evaluate MDA -based development tools for use in their projects.
(...)
This whitepaper compares the productivity of two development teams maintaining and upgrading an identical J2EE application. One team used a Model-Driven Architecture (MDA) approach to J2EE development. The other team used a traditional, code-centric development approach. The original application was a version of the familiar J2EE PetStore application, defined by a rigorous functional specification. The upgrades, which represented a range of typical enhancements, were defined by another rigorous specification. Both specs were reviewed by industry experts.

La herramienta medida fue OptimalJ, pero puedo asegurar que el esquema es válido con la mayor parte de los productos de su tipo, y allí reside el interés del estudio. El punto clave del estudio es su extensión al período de mantenimiento. Es aquí donde las ventajas de utilizar un esquema de desarrollo basado en modelado abstracto con generación automática de los resultados, se torna crecientemente productivo, tanto más cuanto más se expande el desarrollo en tamaño y tiempo. La condición es que la descripción del problema esté hecha en el nivel abstracto, y que existan herramientas que traduzcan en cada momento el modelo a código ejecutable.
Qué se comparaba:

(...) the basis for the specification used in this study is the well known PetStore
application4, a simple web-based J2EE e-commerce application. The baseline PetStore has the following functionality:
o User management and security. Users can sign into the system and manage their account.
o A Product catalog. Users can browse a catalog of pets on the web site (such as birds, fish or reptiles).
o Shopping cart functionality. Users can add pets to their shopping cart and manage their shopping cart in the usual ways.
o Order functionality. Users can place an order for the contents of their shopping carts.
o Web services. Users can query orders via a web service. We extended the PetStore to include this, since web services are an emerging area of interest.
From a technology perspective, the PetStore includes the following:
o A thin client HTML UI layer
o JSPs to generate HTML on the server
o JDBC SQL-based data access
o EJB middle tier components
o Ad-hoc database searching
o Database transactions
o Data caching
o User/Web session management
o Web Services
o Forms -based authentication

Our Maintainability Specification describes requirements for five major enhancements to the baseline application. Each focuses on a different combination of additions or changes, from new user features to business logic changes to integration with other applications.
The teams in this study implemented all of these enhancements :
1. Tracking pet maturation
2. Calculating shipping costs
3. Soliciting supplier bids for new inventory
4. Integrating with Amazon.com via its web service
5. Integrating with a mainframe application to track shipments

La comparación desde el punto de vista de la arquitectura:

Since the development work performed in this study built on that of the original one, many of the critical design choices were already in place. As the previous study describes in detail, both teams used J2EE design patterns extensively in their original work. On the MDA side, these patterns resulted from the implementation templates that translate the Platform-Specific Model (PSM) into code. The MDA tool automatically generated high-quality pattern code from the model. On the traditional side, the patterns stemmed from deliberate design choices and (for the most part) explicit coding. In fact, the previous study found that the traditional team actually used several more patterns than the MDA team.
Some of the design patterns used by both sides in the original application include:
o Session Façade
o Business Delegate
o Data Transfer Object (DTO)
o Model-View-Controller (MVC)
Additionally, the traditional team used these patterns in its original coding:
o Service Locator
o Data Access Objects (DAO)
o JDBC for Reading
In the current round, both teams expanded their use of patterns. On the MDA side, the newer version of OptimalJ incorporated patterns that the previous study’s version did not, particularly Service Locator and DAO. Since these additions resulted from changes to the implementation patterns, they stem from the MDA approach rather than this particular MDA tool. In fact the MDA team in the previous round could have added those patterns had they edited the templates themselves. On the other side, the traditional team used the EJB Command pattern in the legacy integration enhancement. All in all, in this round both teams used approximately the same set of design patterns.
In terms of overall design quality, the code produced this time compared favorably with that of the previous round. For new work that extended previous functionality, the two teams adhered to the same basic designs. The MDA models generated new code that was architecturally equivalent to the existing code.
And the traditional team continued their deliberate use of appropriate design patterns.
In terms of work that was substantially new – such as JMS, web service or legacy integration – the MDA approach continued to help keep architectural quality high. Two examples:
o When a web service or JCA integration was added to the model, the model generated not only the basic client stub classes, but also a stateless session bean and business façade wrapper to the stub.
o For writing a JMS producer, the MDA approach made it very easy to define a message data structure and tie it to the message-producing component, thus minimizing the amount of custom business logic actually required.
On the traditional side, the team had to consciously design and build the wrapper code for the various integration components . They did so with a level of quality comparable to that of the original application.

La integración de código heredado:
El equipo tradicional:

Receiving the stub classes for talking to the CICS application simplified the team’s task enormously. Without them, the team would have had to write that code by hand; lacking experience in COBOL programming or CICS connectivity, they undoubtedly would have found this experience arduous, time consuming and frustrating.
One problem hindering productivity had to do with the distribution of classes for deployment. Using a JCA adapter and accompanying RAR file encouraged the use of an EAR file for deployment. This caused several slowdowns as the team discovered that all non-EJB classes needed to be placed in a separate JAR
file from the EJB JAR and the WAR file so that they could be safely shared and correctly loaded by the class loader. This took considerable time to detect as crucial and then configure, however once accomplished, the deployment of changes was much swifter

El equipo MDA:

Connecting to a mainframe application through a JCA adapter proved remarkably easy. The teams were given an adapter for CICS applications and a piece of COBOL code containing the required record structure, as well as basic information about the target application and some rudimentary documentation.
After the JCA adapter was installed (a simple process), setting up the JCA client was much like defining a web service client:
o OptimalJ parsed the COBOL file much like a WSDL document to create the correct data structure (a custom DTO). This process also created the appropriated elements in the integration tier of the application model.
o The team had the product create corresponding data structures in the domain and application models.
o Generating the code model (EJB and web code) from the application model was straightforward.
o The default application again proved handy for testing.
Overall, the process was extremely quick and did not require any knowledge of COBOL.

En suma:

The challenge in this enhancement was much like the previous one: very little change to the data structures, some UI work, some business logic, but mostly integration. And the result was a comparably large difference between the two teams. Here the challenge centered almost exclusively on using JCA to send a query to a CICS application and get a result. The MDA team was able to add the JCA integration to their MDA model in almost exactly the same way as for a web service. This meant they could auto-generate the stub code without having to know anything about COBOL. And, as with the web services, they also auto-generated wrapper components. The entire effort was remarkably easy.
The traditional team, by contrast, did not have the benefit of a wizard to generate their stub code, so to keep the study’s focus on the differing approaches the team was given those classes . The remainder of their work centered on installing the JCA adapter and integrating the provided code into the application.

La comparación desde el punto de vista cuantitativo:

To complete all five PetStore enhancements took the MDA team 164.8 hours of development time, compared with 260.5 hours for the traditional team. This comes to a 37% improvement in productivity for the team using MDA.
This result is well in line with those of the previous study, which found a 35% productivity improvement for the MDA approach in building the PetStore application to the original baseline specification. The new result indicates that the MDA approach can offer similar productivity gains with respect to maintaining /
enhancing an existing application.

La comparación es particularmente interesante al bajar al trabajo diario de los dos equipos, enfocando las tareas y tomando decisiones. Quizá en su análisis detallado se encuentre el material de mayor interés, y la motivación para estudiarlo. Invito a hacerlo.

Irlanda, "Milagro Celta" comparado

Con una larga historia de emigración y pobreza, Irlanda evolucionó hasta convertirse en uno de los países de mayor interés en el mundo. Michel Moe dedica un breve artículo a enumerar y comparar las cifras de su crecimiento, relacionándolas con las de otros países emergentes, particularmente China e India. Sus cifras comparadas por producto bruto y uso y consumo de servicios dan una visión realista (por oposición) del grado de desarrollo de las dos economías gigantes.
(Sobre los límites de usar el producto bruto como medida, Wikipedia)

Historia viva del software

Scott Rosenberg inicia la publicación de materiales dedicados a la discusión de materiales importantes en la historia del desarrollo del software, con la particularidad de mantener una discusión abierta sobre cada ensayo o tema abordado:

This is the inaugural edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. This week we're talking about Frederick Brooks's The Mythical Man-Month

(...)

During the years I spent researching Dreaming in Code, I accumulated a veritable mountain of reading material on the topic of software development, the history of programming, project management and so on. (I even read much, though certainly not all, of it!) There is, plainly, a core set of books, documents and texts that trace the evolution of this subject; I also gathered some unusual obscurities and overlooked offshoots.

Only a small fraction of this material made its way into Dreaming in Code itself, which is a narrative tale of the ups and downs of one project, set in the context of the longer history of the field. I've been trying to figure out a good way to share my discoveries, spark some interesting discussion and contribute a lasting resource to the Web based on the work I've already done and the reading I continue to do.

Here's my plan: Every week I'm going to announce a topic — usually, a text or document, in many cases easily accessible online; a week later, I'll post some thoughts, notes and ideas about the topic, and open the floor in comments for you to throw your two cents in. If all goes well, together we'll build a handy annotated reading list for curious developers and interested outsiders — and maybe have some fun along the way.

Una nueva ley de educación en Argentina

En La Nación:

Una de las máximas responsabilidades que deberá asumir en poco tiempo más el Congreso de la Nación será la de analizar, debatir y sancionar la futura ley nacional de educación. La Argentina necesita dejar atrás la frustrante experiencia que se vivió con la llamada ley federal de educación, que fue aprobada por abrumadora mayoría en 1993, pero terminó por acarrearle a la comunidad educativa -y a la sociedad en su conjunto- más problemas que soluciones, en parte por desaciertos del propio texto normativo y en parte por equivocaciones en su aplicación.

El texto del Ministerio de Educación, según La Nación:

• restablecimiento del ciclo secundario como un ciclo único
• obligatoriedad de cumplir el ciclo secundario completo
• "procura superar las dificultades creadas por el excesivo fraccionamiento a que ha sido llevado el sistema educativo nacional, debido a las notorias disparidades que presentan las diferentes jurisdicciones"
• incorporación de tutores y coordinadores de cursos, cuya misión será acompañar a los jóvenes y orientarlos en su trayectoria escolar
• estructuración de procesos adecuados de orientación vocacional
• "el anteproyecto dispone que cada jurisdicción provincial o territorial deberá optar por una de las dos modalidades estructurales siguientes: o se adopta una duración de seis años para el nivel de educación primario y seis para el nivel secundario o se elige una duración de siete años para la primaria y cinco para la secundaria. Algunos observadores calificados de la problemática educativa opinan que el anteproyecto no debería autorizar esa opción. A juicio de esos especialistas, la ley debería optar lisa y llanamente por uno u otro régimen"
• se crea el Instituto Nacional de Formación Docente, que buscará garantizar una formación continua común en todo el país.

Debe tenerse en cuenta que para disminuír la deserción no alcanza con hacer obligatoria la enseñanza...Habrá que ver qué otros elementos se diseñan para hacer que la obligatoriedad no sea letra muerta. Es importante la institución de las tutorías, y el énfasis en la capacitación docente. Nuevamente, otros elementos deben acompañar al establecimiento de una institución.
Cada diez o quince años pasamos por una nueva ley de educación, con el mayor resultado visible de más confusión en el ejercicio de la enseñanza, nuevas dificultades en la terminación de estudios (quienes quedan en la frontera entre los dos sistemas encuentran dificultades para asimilar el cambio), y algo más de degradación en los resultados. Pero también, cada intento es una nueva oportunidad de planear un mejor sistema, que pueda torcer el rumbo hacia un resultado exitoso.

Ingeniería de Software como materia de estudio

El profesor Thomas Hillburn ofrece una lista de materiales orientados a formalizar una currícula para el estudio de Ingeniería de Software. Soporta en su sitio algunos materiales del SEI (Guidelines for Software Engineering Education, Specification for an introductory Software Engineering Curriculum). Particularmente, están disponibles muchos de los papeles de trabajo de la conferencia "Fronteras en Educación".

Dos palabras más sobre SAP, Oracle, y SOA

Henning Kagermann, en la nota de Wharton mencionada antes, habla de su Enterprise Services Architecture, como su elección para el uso de servicios web. Tony Baer, de onStrategies, menciona, reforzando las palabras de Kagelmann, las soluciones de SAP y Oracle, y cómo las soluciones middleware , como BEA, se aproximan a la misma visión, para soportar aplicaciones "compuestas":

With the emergence of SOAs, it’s become thinkable to tie bits and pieces from the same system, or disparate systems, together into so-called composite applications. You can use third party tools, like business process management systems to tie things together, or you can buy prepackaged composite apps, like SAP’s xApps.

And if you take SOA seriously, you start thinking about breaking down those packaged software monoliths into federated services that could loosely couple with whatever else is out there. In other words, SOA gives best of breed a new lease on life.

Oracle’s Fusion architecture is being designed to decouple enterprise apps into services. SAP’s Enterprise Services Architecture (ESA) forms the blueprint on how its apps will be exposed. However, exposing apps as services that can readily integrate with third party offerings does not mean that SAP, Oracle, et al are ready to cede account control. Just the opposite – they intend to play the hub in larger playing field.

SAP: cómo va un elefante a la guerra

Knowledge Wharton publica el cuatro de octubre un valioso reportaje a Henning Kagermann, CEO de SAP. La conversación es un excelente resúmen del estado de situación de la competencia entre los grandes actores de las aplicaciones ERP, y de la posición de su empresa en ésta. Las complejas aplicaciones construídas por SAP, Oracle, ahora Microsoft, y otras empresas menores, son una cantera para aprender ingeniería...No es muy probable encontrar otras más abarcativas, extensas, y requeridas de resolver entre persistencia y variabilidad.
Algunos puntos destacables:
Dice introductoriamente Wharton sobre las posibilidades de cambio del producto:

When Henning Kagermann became the sole CEO of SAP in 2003, a role he had previously shared with company co-founder Hasso Plattner, he faced a number of challenges, including an economic slowdown that hurt SAP's growth. Kagermann moved quickly to put in place a program to reshape the company's product offerings and adjust its market focus to position it for the next generation of software. But because major corporations use SAP's software to run nearly every aspect of their business, change at SAP requires a delicate balance between progress and stability.[Resaltado mío]

Sobre el estado de la competencia:

Based in Walldorf, Germany, SAP is the worldwide market leader in enterprise software applications with annual revenues of $10.08 billion at the end of 2005. Microsoft and Oracle compete with SAP and are among the fiercest rivals in the industry. Oracle's recent acquisition spree -- scooping up PeopleSoft, Siebel Systems and more than a dozen smaller companies -- has increased its customer base and consolidated much of the market. Microsoft poses an additional challenge: While serving as a vital partner for SAP to link its ubiquitous Office products to SAP's enterprise backend, Microsoft is also SAP's main competitor in the mid-range market, a key segment for SAP's future growth. Managing such complex relationships is one of Kagermann's major challenges.

Sobre el cambio tecnológico planeado:

In addition, he [Kagermann] must navigate SAP through industry changes that are rewriting the rules of software deployment. With a long history of developing tightly integrated client/server systems -- which use traditional desktop "client" software tightly coupled with back-end server applications -- SAP has to compete in a rapidly-evolving world of Internet-based software applications. Some competitors, such as SalesForce.com's brash CEO Marc Benioff, have even declared the death of traditional, locally installed software. Determining whether these are growing trends or passing fads are key decisions for Kagermann.

(...) we want to reach out to more users within the company and beyond. To put it differently -- we have the philosophy that in the future people will work differently. They won't just sit down and have a transaction with a computer. It will be more of a "push" principle, managed by exceptions -- so that the application is pushing exceptions to your desk. For example, in the morning you would have not only email, but also an inbox of all the urgent business issues you should know about -- information which is critical for you to make decisions. This empowers people and brings decision making down to a decentralized level. People can act very quickly, but still -- I come back to this -- within the company's rules. And if you do those things you can reach more users.

(...)

In Duet, some of the Microsoft screens have an SAP panel on the right-hand side, where the user sees the productivity environment and can then go for deeper information. But there will also be users who are not using Outlook. If you go to manufacturing plants, for example, it's more about the integration between manufacturing execution systems and ours. It's more about the information coming from the NC [numerically controlled] machines, etc.

It's about collecting all of this information so that the guy who is managing the manufacturing flow is getting all the information on one screen. He can make smart decisions [based on information] coming from different systems. So, if I say "push," it doesn't mean that the user has to have an SAP user interface. If he wants a different user interface, we could push the alerts into it. And we also have to do it for mobile [hand-held devices].

Sobre la utilización de servicios Web:

[Habla Kagermann]Another piece that has impacted SAP is the concept of Web Services, which was also developed to provide more interoperability between the applications of different departments and companies. We have extended this concept to an enterprise level. We felt it was still too technical, it was still not in business language, and it didn't have the scalability and the robustness that business needs.

And we have used the standards of Web Services, or the Web Services stack, to build what we call Enterprise Services, which helps companies to communicate. So, yes, it has impacted SAP, but we went beyond this because companies expect us to solve their business problems and not just to deliver the technology.

(...)You cannot convert everything into a service. It always depends on whether something is strategic for a company. Why are companies buying assets and not leasing them all the time? The same thing happens with software. There will be areas where companies still believe they have to own the software and have it on site because only then are they entirely independent. But there are areas where it's not that important and they say, "Why should I own this? I can have it as a service, and I can switch it off. [Referido aquí en dos sentidos:Servicio Web, y externalización de la aplicación]"

Sobre el estado actual, y las derivaciones en el tiempo medio futuro, de la competencia entre las compañías que desarrollan ERPs:

Knowledge@Wharton: Speaking of your competitors, how do you differentiate SAP's strategy from that of your key competitors, like Oracle and Microsoft?

Kagermann: In enterprise applications we are the market leader -- and that means that we have to lead the market. And if you want to do that, you should believe in your own capabilities, and therefore we have adopted organic growth strategies. We have developed most of our products ourselves. We acquire [other companies] only if we are not fast enough to market and in areas where we have no capabilities. That's our difference from Oracle and Microsoft.

Microsoft entered the market with two acquisitions and is building competency from there. That's fine, but we don't have to do this. And Oracle has consolidated the market to buy market share and customers.

We are the market leader. If we bought customers [through acquisition] we would have to maintain the acquired products in parallel for a long time, which would split our R&D capabilities and defocus us from what is really important. We could not push clients to migrate quickly to our products, because we have a good relationship with our clients. We didn't want to be in the position where we have to maintain, develop and migrate three or four different products designed by different people. We have done a pretty good job with the organic growth strategy. We have gained a lot of market share.

(...) Knowledge@Wharton: You mentioned Microsoft briefly. You compete with them on mid-range business software, but they are also a key partner of yours. You've launched "Duet," which integrates their front-end client tools with your back-end enterprise software. How do you manage that kind of relationship?

Kagermann: That's a good question. First of all, we are driven by customer demand. If you are a strategic partner to your customer, you have to follow the demand. And the demand is for interoperability between the key vendors.

Even if you compete in some areas, you have to be professional enough to be a good partner. We are continuing to support Oracle's database with our applications, because our clients want this. The point of view that drives us is: If it's a client demand and it's important for the client's success, we have to do it.

Now, internally you are right, it takes strong leadership to make the organization aware that the customer's success is more important than the little fights you might have internally. And as long as you deal fairly with your partner and the partner is fair with you -- it works. It only starts not working if one of the partners doesn't believe in win/win and fairness in business. But so far we have had fair partners.

Sobre la complejidad de manejo de SAP:

Knowledge@Wharton: Historically your software has had the reputation of being a bit complex, difficult to install and, perhaps, rather inflexible...

Kagermann: Yes. Yes.

Knowledge@Wharton: Is there some justification for this?

Kagermann: You have to be fair here. On the other side you hear "highly integrated," "big productivity improvements," "entirely reliable," "highest quality." With the existing architecture, these are more or less [exclusionary]. If you have lots of functionality, you are not simple any longer. If you have lots of choices, it takes time to find the right thing. If you have a high degree of integration, you are not the most flexible. So, these benefits we brought to the market are always a trade-off.

We have seen other products which were more flexible and [yet they] died, because all of a sudden, the books were not in sync. Those types of things happen when it is too flexible.

But I'm with you; the future is getting both. And that's what we are trying to do with a new architecture. We don't want to give up on what we achieved in the past -- 100% compliance, etc., but we want to add much more flexibility. And I think we can do so.

I feel that [what we have done] was the right sequence. You should not come with highly flexible but noncompliant and unproductive software. You should first come with highly integrated, highly productive software and then make it flexible. I think this is the better sequence.

Agregando a esto, la apertura a terceros proveedores:

This concept of enterprise service and process components is so important. We would not bring flexibility and modularity to a level where it's not compliant. This is a big point. We will not open up the platform. Our flexibility starts on top of the platform. What is inside the platform we will not open up because that's where we can guarantee that the pieces are compliant.

Here you have a platform which should also guarantee compliance. You can innovate; you can put pieces together but only pieces that still guarantee the compliance. The components have built-in integration so that you cannot, [for example,] decouple logistics from finance.

It's more like exchanging documents. If you do it by a message flow, by a document, it's decoupled enough, but we would write this document and show it. If somebody then plugs in a different finance system, which has bugs in it, we are at least compliant so that we can say, "Our file documents the entirety of what's happening on a client level so that you can have clear books." So, this type of compliance we will keep. We would not allow people to say, "We don't need this any longer," and switch it off.

En fin, hay mas... Para leer desde distintos puntos de vista, y extraer líneas de trabajo...

Google Reader

Desde hace algún tiempo, cambié el seguimiento de todos los blogs que me interesan, pasándolos del mecanismo de registro y seguimiento de Firefox, al Reader, el beta de Google. En principio lo hice porque estoy comenzando a usar el escritorio Google como inicio de mi browser, acomodando en una sola página correo, notas, bookmarks, noticias...y consulta de blogs. Resulta especialmente práctico el hecho de simplificar las conexiones, evitando la marea de puertos abiertos al consultar los blogs registrados en Firefox, pero ahora (dos días atrás en mi caso) Reader tomó un valor mayor, presentando de manera clara todo el material: es posible ver lo nuevo, de forma resumida o analítica, y agrupado por etiquetas. Rápido para leer, las nuevas entradas aparecen como una fila con una breve introducción al contenido, de una lista que permite ver toda la historia de cada blog. Las etiquetas apuntando a un blog pueden ser múltiples, como en Gmail, de tal forma que los contenidos pueden agruparse y clasificarse. Una manera ágil de seguir las novedades, y conservar lo que sea de interés.

...y hablado de historia, eXtreme Programming

XP, reciente, pero merecedora de una recopilación histórica. Mencionada por Steve Yegge en su artículo sobre Agile (Bad Agile, Good Agile), que conocí por el blog de Juan Palacio
(Bad Agile, Good Agile, y otros fundamentalismos).

Extreme Programming was created by Kent Beck, Ward Cunningham, and Ron Jeffries during their work on the Chrysler Comprehensive Compensation System (C3) payroll project. Kent Beck became the C3 project leader in March 1996 and began to refine the development methodology used on the project. Kent Beck wrote a book on the methodology, and in October 1999, Extreme Programming Explained was published. Chrysler cancelled the C3 project in February 2000, but the methodology had caught on in the software engineering field. As of 2006, a number of software-development projects continue to use Extreme Programming as their methodology.

¿Cómo tomar el comienzo fallido en Chrysler? Quizá más bien como un aspecto más de los fallos en la competitividad de la industria automotriz americana frente a la japonesa (¿y cuáles son las prácticas en estas empresas?)

Historia de los servidores de IBM

"New to IBM systems", en la sección de Servidores de IBM Developer, muestra una breve línea de vida de sus servidores de datos, con una descripción elemental del alcance actual de cada uno de los tipos de servidores. Quizá la línea más movida, y probablemente la generadora de más innovación, haya sido la iniciada por el System/3, que ha llevado al I5 (antes, AS/400):

IBM System i models also follow a rich history, beginning with the powerful and innovative IBM AS/400® products. System i is a scalable minicomputer based on a virtual machine (VM) design. Applications compile to a virtual instruction set (called TIMI) rather than the system’s native instruction set. Through this behavior, an application that was compiled for an original AS/400 system (using the IBM PowerPC® AS A50 processor) can run on a new eServer iSeries™ system (running an IBM POWER5™ processor) without having to be recompiled.

Wikipedia es otro punto de entrada para conocer el ISeries:

[en 1995] IBM re-christened the one-stop shop programming style "OPM" (for Original Programming Model) and introduced a new language paradigm called "ILE" (for Integrated Language Environment). ILE had significant enhancements over OPM, including the ability to create modules (similar to .obj or .lib files), and then bind (link) the modules together into a single executable. The executable could be created as a program or a service program (service programs are similar to .lib or .dll files).
The real power of the ILE environment is in the "integrated" aspect, however. Modules in ILE-compliant languages (RPG, COBOL, C, C++, and CL) could be created and bound together. For the first time, AS/400 programmers could exploit the strengths of multiple ILE-compliant languages in a single program. Also, with the introduction of service programs, standard routines could be externalized more easily, and modularity increased. To ensure proper migration to the ILE environment, OPM RPG and COBOL programs could be migrated to ILE easily

Nota: Este artículo, por largo tiempo, perdió el enlace a las páginas asociadas de IBM. El artículo original se puede localizar a través de The Internet Machine, en su versión del 5 de enero de 2007. La referencia siguiente al Sistem i5 también ha cambiado su ubicación.