Una nueva versión sobre la (posible) venta de Sun

Gavin Clarke, en The Register, agrega otra faceta a la ronda por el futuro de Sun: la propuesta de compra de IBM habría bloqueado una compra de Sun por parte de Oracle y Hewlett-Packard, desmembrada en dos negocios: la cartera de software para Oracle, y el hardware para HP. El negocio representaba "más de 2000 millones de dólares". La oferta de IBM por más del doble habría congelado la operación:

Oracle and Hewlett-Packard are believed to have made a joint offer for Sun Microsystems in a deal totaling more than $2bn.
Under the deal, database giant Oracle would have taken Sun's software portfolio for $2bn, leaving HP with Sun's vast Solaris, Sparc, and x86 server products, manufacturing and distribution, and user base.
A potential deal between the three is understood to have been blocked by IBM, in the middle of talks to buy the whole of Sun for a reported $6.5bn.
Oracle, HP, and Sun declined to comment on what they called rumors, while IBM was unavailable for comment at the time of going to press.
A source, who didn't want to be identified, told The Reg that Oracle and HP had gone in to meet Sun to discuss the possible deal.
It's already been reported that Sun had been shopping itself around Silicon Valley, with HP named as a potential buyer.
This, though, is the first indication that HP had teamed with Larry Ellison's M&A beast Oracle - which has bought 50 companies in four years - to take only what they wanted from Sun. At $2bn, this would have been one of Oracle's large purchases, slotting behind PeopleSoft and BEA Systems.
Oracle and Sun parted ways on Java and on databases on Sparc a while back, partly thanks to Sun's $1bn purchase of the popular open-source database MySQL.
Of all Sun's software products, Oracle is likely to be most interested in owning this.

Lo que está claro, es lo oscuro del futuro de Sun. En épocas difíciles, las estrategias de negocios están bajo fuego.

La posible adquisición de SUN

James Gossiling opina sobre la eventual compra de Sun por IBM; recogido por Jason Stamper, en Computer Business Review:

Gosling insisted the rumoured acquisition is, “Obviously just speculation at this point.”

But asked about the different cultures within IBM and Sun, and in particular their developer staff, Gosling said: “There would definitely be a culture clash. We’re definitely weirder than they are.”

“We grew up from a bunch of hippies, almost with flowers in our hair,” said Gosling.

Although the firm was founded in 1982, its proposition, which involved the peddling of open systems in general and Unix in particular -- and more recently its transition into a major contributor to the open source software movement – has given it a certain hippy, perhaps even radical culture. Especially when compared to the more proprietary computing platforms that preceded it, IBM included.

But Gosling suggested that it would still be possible for Sun and IBM staff to settle their differences: “We’re a much more grown-up company now [than when Sun was founded] with a very different group of people. We’ve become a full-on enterprise software company,” he told CBR.

Asked whether it would be interesting to try and in some way combine some of Sun’s NetBeans open source development framework technology with IBM’s rival Eclipse project, Gosling said: “It would certainly be possible. We have been partners on the Java journey for quite a few years. In many ways there would not be a huge impact on Java development.”

But in a statement that perhaps has ramifications for IBM’s rumoured acquisition of Sun, Gosling – the inventor of Java – said that the Java community is now, “Such a large community of people that nobody could control it. If anybody tried, it would ruin it all.”

Desde hace tiempo, ambas empresas tienen más puntos en común que diferencias en su orientación a Open Source. Una eventual absorción probablemente favorecería la actividad en Eclipse. Y quizá por el lado de IBM ampliaría su soporte a Java, creciente sobre sus equipos de rango medio (ISeries). Sin embargo, una compra tiende más a ser la absorción y eliminación de un competidor en el mercado. Dana Gardner, en ZD Net, duda de su viabilidad y realidad:

By buying Sun IBM gains little other than some intellectual property and mySQL. IBM could have bought mySQL or open sourced DB2 or a subset of DB2 any time, if it wanted to go that route. IBM has basically already played its open source hand, which it did masterfully at just the right time. Sun, on the other hand, played (or forced) its open source hand poorly, and at the wrong time. What’s the value to Sun for having “gone open source”? Zip. Owning Java is not a business model, or not enough of one to help Sun meaningfully.

So, does IBM need chip architectures from Sun? Nope, has their own. Access to markets from Sun’s long-underperforming sales force? Nope. Unix? IBM has one. Linux? IBM was there first. Engineering skills? Nope. Storage technology? Nope. Head-start on cloud implementations? Nope. Java license access or synergy? Nope, too late. Sun’s deep and wide professional services presence worldwide? Nope. Ha!

Let’s see … hardware, software, technology, sales, cloud, labor, market reach … none makes sense for IBM to buy Sun — at any price. IBM does just fine by continuing to watch the sun set on Sun. Same for Oracle, SAP, Microsoft, HP.

With due respect to Larry Dignan on ZDNet, none of his reasons add up in dollars and cents. No way. Sun has fallen too far over the years for these rationales to stand up. UPDATE: Tony Baer likes Fujitsu as Sun savior.

Only in playing some offense via data center product consolidation against HP and Dell would buying Sun help IBM. And the math doesn’t add up there. The cost of getting Sun is more than the benefits of taking money from enterprise accounts from others. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

Eric Newcomer pone el acento en la competencia por el liderazgo de la comunidad Java, y sí considera que existe interés de parte de IBM en la compra, particularmente si futuros desarrollos de Sun siguieran un camino distinto del que hoy otras empresas tienen embarcado:

The hot topic of debate today is the breaking news story that IBM is in talks to acquire Sun. Dana Gardner doubts this, and a bunch of myFB and Twitter friends ask the obvious questions in their status updates: Why the heck would IBM want to do this?

I haven’t seen anyone yet bring up the Java question. As co-chair of the OSGi EEG and formerly 9-year employee of a Java vendor, I have seen the battles between Sun and IBM over the control of the Java langauge up close. It has never been a pretty picture.

Recently I was asked about Jonathan Schwartz’s blog entries about Sun’s future direction and corporate strategy. The content of these entries has been subject to the usual praise and criticism, but I haven’t seen anyone talk about what’s so obviously and painfully missing - at least for someone active in the Java community and trying to push the ball forward (e.g. enterprise OSGi). Where is the talk about leading the Java community? Where is the talk about collaboration with IBM, Oracle, Progress, Tibco, and others? Where is the description of how helpful Sun is toward Apache’s Java projects (especially Harmony)?

IBM has ported many products onto the OSGi framework during the past several years, including flagship products such as WebSphere Application Server and Lotus Notes. Never mind the fragmentation in the Java community caused by the disagreement over SCA. What about Sun’s recent announcement that they were going to reinvent Java modularity in the Open JDK project, all on their own, without input, without regard to what happens to OSGi? What kind of potential change cost does that represent to IBM and all the other Java vendors who have ported products onto OSGi?

The potential acquisition of Sun has been debated so far mostly in terms of the business value Sun has - that is, in the context of where it is still making money, as if that were the main or only reason for an acquisition. But I say again, what about the unrealized potential for collaborative leadership in the Java community? Sun obviously isn’t paying attention to this, but IBM might be.

Para más información, la eventual compra, analizada por The Wall Street Journal.

Extendiendo el alcance de los modelos

Jean Bezivin, profesor de la Universidad de Nantes, conduce un proyecto que ahonda la apuesta por el desarrollo guiado por modelos (MDD/MDE): AtlanMod, el equipo que lidera, trabaja en el desarrollo de un framework que permita actuar por encima de distintos metamodelos. Como en investigaciones previas lo ha mencionado, se trata de un meta-meta-modelo:

The AtlanMod team is progressively developing AmmA, a conceptual modeling framework. This modeling toolkit provides a high level view of MDE, implementing a number of domain specific languages like KM3 to construct metamodels, ATL to define model transformations, AMW to specify the abstract correspondences between models, or TCS to express the relations between grammars and metamodels. The AmmA toolkit implements the advanced artifacts and operations characteristics of last generation generative domain modeling facilities.

(...) The MDE community has been using the concepts of terminal model, metamodel, and metametamodel for quite some time. A terminal model is a representation of a system. It captures some characteristics of the system and provides knowledge about it. In MDE we are interested in terminal models expressed in precise languages. The abstract syntax of a modeling language, when expressed as a model, is called a metamodel. A language definition is given by an abstract syntax (a metamodel), one or more concrete syntaxes, a definition of its semantics, etc. The relation between a model expressed in a language and the metamodel of this language is called conformsTo. This should not be confused with the representation relation (repOf) holding between a terminal model ant the system it represents. Metamodels are in turn expressed in a modeling language called metamodeling language. Its conceptual foundation is captured in a model called metametamodel. Terminal models, metamodels, and metametamodel form a three-level architecture with levels respectively named M1, M2, and M3. MDE promotes unification by models like object technology proposed in the eighties unification by objects [1]. The principles of MDE may be implemented in several standards.[En la presentación del equipo]

El conjunto de herramientas combina en este momento experimentación, investigación, y trabajo en producción real:

Completely specializing on advanced model engineering, the AtlanMod research team is well known for its toolbox (AmmA for AtlanMod Model Management Architecture), including in particular the widely used ATL transformation language (AtlanMod Transformation Language). Since these tools have been made available on the Eclipse.org platform, there are an important number of organizations, academic or industrial, that are currently using these tools. AtlanMod has been a key international actor in the development of the model transformation area, publishing the first papers and creating the reference conference on the subject (ICMT for International Conference on Model Transformation). AtlanMod participates in the major international, European, and national projects on MDE like Carroll, ModelWare, ModelPlex, TopCased, OpenEmbeDD, OpenDevFactory, Lambda, FLFS, IDM++, Happy/Gaja, etc. In addition to these, ATL has been used in a number of other projects, including international projects and activities supported by several French clusters. AtlanMod has demonstrated that, with a small team, it was possible to achieve high impact by keeping a precise focus and of course by getting a lot of collaboration through open source projects (Eclipse).

Este trabajo en progreso es de un alcance mayor a MDA, estableciendo puentes con otros estilos de desarrollo basado en modelos. La diversidad de puntos de vista es un motivo que promueve un nivel por encima de los distintos estilos, y la posibilidad de extender las potencialidades de la automatización de análisis y generación es otra razón para este punto de vista. Uno de los papeles que explican su punto de vista, "Applying Megamodelling to Model Driven Performance Engineering", desarrolla un caso real aplicado al análisis y ajuste de la performance de un modelo. Una revisión de este trabajo puede dar una idea de las posibilidades que AmmA ofrece.

Swift, un experimento sobre seguridad en Web

Lambda The Ultimate comenta un ensayo en curso que parece muy interesante: Swift, un sistema que basa la construcción de aplicaciones web en la utilización de una extensión de Java que aplica políticas de seguridad, y en tiempo de compilación divide el código entre JavaScript en el cliente, y Java en el servidor. Para seguir, tenga éxito o no. Presentación en Lambda...:

Swift: making web applications secure by construction

Swift is a language-based approach to building web applications that are secure by construction. Swift applications are written in the Jif language, a Java-based language that incorporates "security-typing" to manage the flow of information within an application. The Swift compiler automatically partitions the application code into a client-side JavaScript application and a server-side Java application, with code placement constrained by declarative information flow policies that strongly enforce the confidentiality and integrity of server-side information.

Swift was recently featured in the "Research Highlights" section of the Communications of the ACM, as a condensed version of an earlier conference paper. The original conference paper is Stephen Chong, Jed Liu, Andrew C. Myers, Xin Qi, K. Vikram, Lantian Zheng, and Xin Zheng, Secure web applications via automatic partitioning, Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP'07), pages 31–44, October 2007.

Jif has been mentioned previously on LtU here and here.

La presentación en el sitio de Swift:

Swift is a new, principled approach to building web applications that are secure by construction. Web applications are hard to build because code and data need to be partitioned to make them responsive. They are also hard to build because code and data need to be partitioned for security. Currently there are no good methods for deciding when it is secure to move code and data to the client side.

Because of the connection (and tension) between the problems of security and interactive performance, Swift addresses both at once, automatically partitioning application code while providing assurance that the resulting placement is secure and efficient.

In the Swift approach, application code is written in the Jif language, a Java-based language that includes information security policies. The source code is automatically partitioned into JavaScript code running in the browser, and Java code running on the server. For interactive performance, code and data are placed on the client side where possible. Security-critical code is placed on the server and user interface code is placed on the client. Code placement is constrained by high-level, declarative information flow policies that strongly enforce the confidentiality and integrity of server-side information. The Swift compiler may also choose to replicate code and data across the client and server, with benefits for both security and performance.

En la base del sistema está Jif, que es descripto así en su sitio:

Jif is a security-typed programming language that extends Java with support for information flow control and access control, enforced at both compile time and run time. The source code for the Jif compiler and run-time system is now available for download. Jif is written in Java and is built using the Polyglot extensible Java compiler framework.
Static information flow control can protect the confidentiality and integrity of information manipulated by computing systems. The compiler tracks the correspondence between information the policies that restrict its use, enforcing security properties end-to-end within the system. After checking information flow within Jif programs, the Jif compiler translates them to Java programs and uses an ordinary Java compiler to produce secure executable programs.

Jif extends Java by adding labels that express restrictions on how information may be used. For example, the following variable declaration declares not only that the variable x is an int, but also that the information in x is governed by a security policy:

    int {Alice→Bob} x;

In this case, the security policy says that the information in x is controlled by the principal Alice, and that Alice permits this information to be seen by the principal Bob. The policy {Alice←Bob} means that information is owned by Alice, and that Alice permits it to be affected by Bob. Based on label annotations like these, the Jif compiler analyzes information flows within programs, to determines whether they enforce the confidentiality and integrity of information.

¿Podría agregarse una capa más, para crear el código que luego se compilará?. Para investigar, en la hora 25 del día...

Una historia del modelado conceptual

Para quienes hubieran sido muy jóvenes en los 70 y 80, una breve referencia a la evolución del modelado desde sus orígenes, con apuntes a algunos hechos relevantes: The history of conceptual modeling, en páginas de la Universidad Klagenfurt. Lo interesante del sitio es que está abierto a nuevos aportes (enviar por correo electrónico, ver a continuación). Resumen de su prefacio:

This is just an approach to give a short and incomplete overview about conceptual modeling in the last 30 years. Everyone who has ideas, important events or innovative papers about the history of conceptual modeling is welcome to add them by e-mail. The current approach is just a starting point and it should grow to a very extensive overview.
The conceptual modeling is divided into three decades: the 1970ies, the 1980ies and the 1990ies.

The 1970ies
In the 1970ies database design is very important. Especially Peter Chen’s paper “The Entity-Relationship Model: Toward a Unified View of Data” is a milestone in the area of data modeling and database design.
Abstraction and Generalization in database design are introduced by Smith and Smith.
There are also attempts to develop high level data definition languages for defining conceptual schemas to describe conceptual schemas. Such a language is the Conceptual Schema Language (CSL).
Information Systems and semantics of information systems become also very interesting.

The 1980ies
In the 1980ies there are several approaches to extend Chen’s Entity Relationship Model. We also focus on the Pingree Park Workshop in 1980. Also important in this decade is REMORA by Roland Colette. Actually information systems and the design of IS are interesting topics.

The 1990ies
At the beginning of the 1990ies there are several questions such as schema integration, schema transformation and quality measures for conceptual schemas in the area of database design. But this time is also influenced by object-oriented modeling methods and languages in software engineering. In the 1980ies object-oriented programming languages become more and more important. As a result of this evolution object-oriented programming leads to object-oriented modeling. Data Modeling in software engineering becomes more and more important.
At the beginning of the 1990ies more than fifty different modeling languages existed at the same time. Booch, Jacobson and Rumbaugh decided to work together and so they developed the Unified Modeling Language (UML) that became in 1997 a standard in the object-oriented modeling.

Una visión histórica debería ser muy útil para ubicarse en el mapa del modelado tal como hoy se lo ve.

Gerenciamiento y apertura (Cómo apoyarse en la Web 2.0)

Pocos días atrás Forbes publicó un artículo que relaciona redes sociales informales y empresas, abogando por la utilización de éstas para mejorar las comunicaciones dentro de la empresa, y entre ella y sus clientes. Una lectura atenta puede extraer lecciones para nuestros mercados, pensando en España y Chile especialmente, donde es frecuente un estilo vertical de manejo de las relaciones internas y externas.
Matthew Fraser y Soumitra Dutta, autores del artículo, destacan las ventajas de comunicación y retroalimentación que implica una red abierta en tiempo real, y resaltan la resistencia al cambio y el criterio verticalista usual en las dirigencias. Qué dicen:

Many corporate executives either dismiss social networking as a time-wasting distraction or regard it as a risk management problem. Much of their fear has focused on potential risks like security breaches and data privacy.

Web 2.0 evangelists, on the other hand, argue that social software can be used to boost productivity. They say it can facilitate an open-ended corporate culture that values transparency, collaboration and innovation. Most important, it can be an effective way to build a customer-centric organization that not only communicates authentically but also listens to customers and learns from that interaction.

In the current stormy economy, as companies look for new ways to market their products and engage their customers, chief executive officers are finally looking more and more at how social networking tools can extend their brands, create corporate cultures based on listening and learning, and establish their own leadership profiles.

Nonetheless, big brands, generally speaking, haven't successfully tapped the potential of social media; they tend to regard Web 2.0 platforms as just another way to push out short-term marketing campaigns. They fail to grasp that the new media require new ways of doing business. Old ways need to be tossed out.

(...) Most CEOs, let's face it, are cut off from their most important constituencies, including employees and customers. Their press conferences are carefully stage managed, their annual meetings over-rehearsed, and in both cases the goal is usually to reveal as little as possible. Web tools like blogs can help corporate leaders enhance their credibility by communicating directly and having authentic conversations with key stakeholders.

(...) Corporate leaders can use Web 2.0 tools not only to communicate but also to learn from employees, suppliers, customers and the public. Many corporations spend large sums trying to find out what people think of them. Plugging into the blogosphere or listening to feedback on Twitter offers a more effective and cost-efficient way of learning how to approach customer relations.

(...)A CEO can use Web 2.0 tools not only to communicate and learn, but also to instigate action and become a more effective leader. Tools like blogs and podcasts put a top executive in more direct contact with employees, cutting through multiple layers of middle managers, who can be motivated by their own agendas to frustrate direct communication. A persuasive CEO can use Web 2.0 tools to boost morale, foster creativity and enhance the values of open collaboration.

CEOs can use Web 2.0 tools to make themselves known as intellectual leaders not only among their employees and customers but also with the media and the public. Public relations people often get nervous when CEOs wants to connect directly, but a CEO who blogs intelligently can enhance his personal brand as an intangible corporate asset.

(...) Is there any peril in Web 2.0 for CEOs? Yes, there are dangers that corporate leaders must work to avoid, such as confidentiality breaches if financial matters are disclosed, harm to a company's reputation caused by blogging employees and negative blowback from the blogosphere.

(...) The key message for corporate leaders seeking to harness the benefits of Web 2.0 is that simply deploying the software is not enough. The challenge is to ensure that the company's corporate culture is infused with values of openness and transparency. Of course, at many corporations that's easier said than done.

As the management guru Gary Hamel observes, "While the Web was founded on the principle of openness, the most honored virtue among senior executives seems to be control. Most companies have elaborate programs for top-down communication, including newsletters, CEO blogs, Webcasts and broadcast e-mails. Yet few, if any, companies have opened the floodgates to grassroots opinion on critical issues."

These are tough challenges. But Web 2.0 is finally gaining momentum in corporations, with an urgency increased by the current economic climate. It's now reasonable to predict that following the Web 2.0 revolutions in personal interactions and politics, a corporate Web 2.0 tipping point is on the horizon.

Un modelo basado en la confianza en la gente, en el trabajo colaborativo, en la delegación de responsabilidades, encontraría valiosas herramientas en la Web 2.0 (por llamar de alguna manera al conjunto de recursos disponibles). Un modelo basado en las decisiciones tomadas en la soledad, o en la consulta con confidentes y cofrades, y en el liderazgo comercial por monopolio, despreciará la oportunidad. ¿Quién tendrá mejor resultado?.

La importancia de la gente en el sistema de Toyota

En varias oportunidades se ha hablado aquí de Lean Manufacturing, desde dos puntos de vista: cómo Lean Manufacturing, Calidad Total (Total Quality Management, TQM) ,o TPS (Toyota Production System) pueden y deben ayudar a mejorar el proceso de construcción de software, y cómo estos sistemas comparan contra nuestra experiencia iberoamericana de gerenciamiento de la empresa.
Este último aspecto progresivamente es el que más me interesa, siendo observador frecuente de "sistemas" de gestión, por llamarlos de alguna manera, que difieren mucho de buenas prácticas productivas. Observaciones logradas en años de cambios de mano de empresas argentinas, de sus propietarios familiares originarios a consorcios que las convirtieran en commodities, con administradores recién llegados que sólo piensan en bajar costo o maquillarlas para una reventa rápida. Empresas familiares que, por otra parte, sucumbieron con facilidad ante el primer cambio de generación, o ante la competencia directa de una empresa multinacional. También puntualizaciones anotadas sobre la empresa chilena, en general familiar, jerárquica, basada en estructuras de confianza, con poca voz de las personas que la integran fuera de esa organización informal. Y en estos últimos años, un volúmen de información sobre la empresa española que no acabo de procesar, pero que en múltiples ocasiones se aparece ineficiente, inconducente. No por casualidad es un lugar común la afirmación de la baja productividad en España. Muchas veces, hablando con otros colegas, he dicho que debiera abrir un cuaderno para anotar malas prácticas. Quizá lo sean estas notas.
A propósito de un reportaje a Steven Spear, del Harvard Business School, quisiera recordar una perogrullada: la gente es importante en una organización (de lo que hemos hablado antes).
En el título de esta nota se habla de Toyota y la gente con la que produce. Cuando se habla de su caso, se entiende que se habla de la empresa, sus proveedores, y sus agentes comerciales y de servicio, porque su sistema los integra, ya que parten del criterio que para aplicar su justo-a-tiempo (Just in Time, JIT), es necesario que todo el proceso de producción, comercialización y seguimiento esté integrado y colabore para que dé resultado. En todo este proceso, la participación de cada integrante de la cadena es fundamental. Cada uno es responsable por su parte del trabajo, asegurando que el producto pase sin defectos. Cada persona debe tener múltiples aptitudes, porque contrariamente a las prácticas tradicionales, no existen especialistas, sino personas capaces de hacer distintas actividades. Y además, cada persona tiene la capacidad de detener la producción si lo considera necesario debido a un fallo o defecto.
El sistema de Toyota fue estudiado y copiado desde hace tiempo, pero, al menos en el caso de sus competidoras americanas, el objetivo de mejora no es logrado, con poca asimilación de sus participantes. Asimismo, en distintas lecturas de papeles sobre TPS, parecería que se escapa el rol que la gente cumple en el sistema.
Spear puntualiza este aspecto durante el reportaje de Sarah Jane Johnston (How Toyota Turns Workers Into Problem Solvers):

(...) despite Toyota's openness and the genuinely honest efforts by other companies over many years to emulate Toyota, no one had yet matched Toyota in terms of having simultaneously high-quality, low-cost, short lead-time, flexible production over time and broadly based across the system.

[qué se ha escapado: ] In essence (...), the people who work in an organization that produces something are simultaneously engaged in collaborative production and delivery and are also engaged in a collaborative process of self-reflective design, "prototype testing," and improvement of their own work systems amidst changes in market needs, products, technical processes, and so forth.

It is our conclusion that Toyota has developed a set of principles, Rules-in-Use we've called them, that allow organizations to engage in this (self-reflective) design, testing, and improvement so that (nearly) everyone can contribute at or near his or her potential, and when the parts come together the whole is much, much greater than the sum of the parts.

(...) We've seen that consistently—across functional roles, products, processes (assembly, equipment maintenance and repair, materials logistics, training, system redesign, administration, etc.), and hierarchical levels (from shop floor to plant manager and above) that in TPS managed organizations the design of nearly all work activities, connections among people, and pathways of connected activities over which products, services, and information take form are specified-in-their-design, tested-with-their-every-use, and improved close in time, place, and person to the occurrence of every problem.

Spear explica sobre la delegación de responsabilidad:

We've observed that Toyota, its best suppliers, and other companies that have learned well from Toyota can confidently distribute a tremendous amount of responsibility to the people who actually do the work, from the most senior, expeirenced member of the organization to the most junior. This is accomplished because of the tremendous emphasis on teaching everyone how to be a skillful problem solver.

(...) We've observed that Toyota, its best suppliers, and other companies that have learned well from Toyota can confidently distribute a tremendous amount of responsibility to the people who actually do the work, from the most senior, expeirenced member of the organization to the most junior. This is accomplished because of the tremendous emphasis on teaching everyone how to be a skillful problem solver.

Spear destaca también las distintas características requeridas para gerencias y jefaturas:

[Pregunta Johnston]Q: What is the role of the manager in this process?

[Responde Spear]A: Your question about the role of the manager gets right to the heart of the difficulty of managing this way. For many people, it requires a profound shift in mind-set in terms of how the manager envisions his or her role. For the team at Aisin to become so skilled as problem solvers, they had to be led through their training by a capable team leader and group leader. The team leader and group leader were capable of teaching these skills in a directed, learn-by-doing fashion, because they too were consistently trained in a similar fashion by their immediate senior. We found that in the best TPS-managed plants, there was a pathway of learning and teaching that cascaded from the most senior levels to the most junior. In effect, the needs of people directly touching the work determined the assistance, problem solving, and training activities of those more senior. This is a sharp contrast, in fact a near inversion, in terms of who works for whom when compared with the more traditional, centralized command and control system characterized by a downward diffusion of work orders and an upward reporting of work status.

Como en otras oportunidades se ha comentado, esta confianza en la gente, esa disposición a delegar, y, en el caso de Toyota al menos, el estímulo a proponer, representan una gran diferencia con el estilo que solemos presenciar. El trabajo en equipo, la consulta, el estímulo a la puntualización de defectos, están muy lejos de las prácticas de trabajo con alta rotación (contratación por cortos períodos, reducido equipo propio), la baja importancia dada a la capacitación, la inexistencia de estímulo a la participación, son algunos vicios reiterados en nuestras tierras, con impacto en la productividad.
Muchas certificaciones de procesos de software, o más simplemente, el diseño de esquemas de manejo del proceso, fallan simplemente por erróneos criterios de gerenciamiento: no es posible que un sector funcione bien, si está encajado en un universo de malas prácticas.

Calidad y modelo de negocios

El 4 de marzo, James Bach escribe que "La calidad está muerta" en la creación de software. Pero el desarrollo de su nota apunta más bien a un modelo de negocios, antes que a una posición general sobre el desarrollo de software siguiendo patrones de calidad.
Ciertamente apunta a un problema su indicación de que la cesión del desarrollo y actividade de control a terceros a través del outsourcing disminuye la calidadad del producto. Al menos, es frecuente la crítica de desconexión entre solicitante y encargado de los trabajos, así como la desconfianza en la real capacidad de empresas (abundantes referencias a India), y la devaluación de algunas certificaciones de calidad.
También es cierto que la media probablemente maneja criterios mucho más laxos que los recomendables tanto en la construción como en el control, y no alcanzarían varias páginas para dar ejemplos.
Lo importante de su observación es que, si las empresas que desarrollan software, y aquí habla de aquellas cuyo negocio es esto mismo, si estas empresas son empujadas por el mantenimiento de un retorno elevado de utilidades, entran en un ciclo de renovación de productos que termina degradando la calidad de aquello que entregan. Bach habla reiteradamente de quien probablemente sea el mayor impulsor de este modelo, Microsoft, señalando en las sucesivas entregas de versiones de Windows un grado de inmadurez que ha terminado minando la confianza en sus productos.
Estamos ante una crisis que parece que marcha a ser mayor que la de 1930. ¿Se generalizarán las malas prácticas en pro del abaratamiento del producto final, o se mantendrá un modelo más conservador? Estas son épocas de crudo darwinismo. Quizá el más fuerte no sea el mejor.

Lenguajes de computador: Preferencias en la lectura

El 25 de febrero, Mike Hendrickson analiza en O´Reilly las cifras de la editorial acerca de la venta de materiales dedicados a lenguajes de computación. ¿Cuánto tienen que ver estos números con su uso real? En cierto modo marcan tendencias, pero sólo si se lo observa en un período mediano de plazo, para diferenciar tendencias duraderas respecto de las "olas". Un caso claro es el del COBOL, con menos de mil libros vendidos. ¿Podríamos concluír que su uso es menor que el de c#, java o c++, con cifras variando entre los 170.000 y 270.000 libros?. En realidad, se trata del interés prestado a uno y otro. Lo que les interesa a quienes agregan conocimiento e investigan. Pero el uso real es una combinación de pragmatismo, conservadorismo e innovación, y la persistencia del COBOL da fuerza a los dos primeros elementos.