Crece la industria del software en Argentina

Cecilia Novoa publica a comienzos de noviembre en IProfesional una nota sobre el crecimiento de la actividad de IT en Argentina, que comienza a representar cifras de real peso: el número de personas ocupadas es similar al que emplea la industria automotriz. Sin embargo, como en otros mercados, sigue siendo inferior a las necesidades la promoción de nuevos profesionales desde las Universidades.

El fuerte crecimiento que el sector informático experimentó en los últimos años lo posicionó "cabeza a cabeza" con la industria automotriz en cuanto a la creación de empleos registrados.
El impulso de tan significativa expansión vino de la mano del lugar que encontró la Argentina en los mercados mundiales como plataforma exportadora de servicios.
Así, mientras la industria automotriz (entre terminales y autopartistas) cuenta con 77.362 empleos registrados, las actividades de Informática (desarrollo e implementación de software, consultoría, suministros de programas, servicios relacionados con bases de datos, procesamiento de datos y servicios de soporte, mantenimiento y reparación) le dan trabajo a unas 76.501 personas, señalan los datos del Ministerio de Trabajo al primer trimestre.
En lo que va del 2010, la incorporación de perfiles "tecnológicos" no para de crecer. La búsqueda de profesionales en el área de IT se incrementó entre un 40 y 50% entre enero y octubre de este año en comparación al mismo período de 2009, según estimaciones de la consultora Michael Page International Argentina.
Al respecto, Daniel Iriarte, Head-Office de la compañía en Buenos Aires, comentó que el dato viene a confirmar que el área de Tecnología de la Información (IT, en inglés) hoy se está constituyendo como uno de los sectores más activos y dinámicos de la industria regional.
De acuerdo al ejecutivo, entre los detonantes del alza incipiente en el rubro se encuentra, en primer lugar, la inversión tecnológica realizada en el país en el transcurso de los últimos períodos.
Asimismo, son relevantes las ventajas con que cuentan los especialistas IT locales, y que se expresan no sólo a través de su costo competitivo (dado el tipo de cambio) o sus similitudes culturales con polos demandantes en la industria, sino también en términos de su formación profesional y académica.
En tanto, Lucia Zunino, Project Leader y selectora especializada en el área de IT de la consultora, aseguró que "el sector informático fue el que más ha crecido en lo que va del 2010".
En base a las experiencias de sus empresas clientes, Zunino apuntó que la creciente actividad e intensidad en la contratación es una consecuencia de la importante cantidad de proyectos que venían postergados o "freezados" y que este año se retomaron.

La contracara del fénomeno
Sin embargo, la contracara de este cambio es la falta de recursos calificados para cubrir las diferentes posiciones que requieren las empresas, ya sean multinacionales o Pyme.
Según los expertos, la famosa "escasez de talentos" en el mercado de las Tecnologías de la Información se siente cada vez más.
Es que, por ejemplo, la cantidad de egresados de las carreras vinculadas a Informática no crece al ritmo que lo hace la industria. De hecho, desde la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI) alertan que de 3.275 (2009) los graduados bajarán a 2.783 para el 2011.
En la actualidad, detalla el siguiente gráfico, el grueso de los empleados de esta industria cuenta con un nivel universitario completo (38%) o incompleto (31 por ciento).

En este sentido, el gerente de la división de Finanzas & IT de Michael Page, Miguel Carugati, advirtió que "hoy resulta esencial que se trabaje en función del aumento del porcentaje de profesionales formados técnicamente y preparados para enfrentar las exigencias del mercado actual".
Los más buscados
En la actualidad, las empresas buscan profesionales no sólo orientados a lo técnico y operativo, sino que también estén enfocado al negocio, con la habilidad de vincular conocimientos especializados con aspectos referentes al presupuesto y la perspectiva de crecimiento económico de una compañía.
Según Michael Page, los perfiles más solicitados en este momento son:

1. Especialistas que ocupen cargos gerenciales en el área de IT
2. Profesionales del sector de ERP (SAP en especial)
3. Personal para las áreas de Project Management y Analistas Funcionales.

De acuerdo a Zunino, la demanda proviene de empresas de línea que necesitan reforzar sus áreas de Sistemas, pero sobre todo de consultoras de desarrollo que venden sus servicios tanto al mercado interno como externo.
En este último grupo de compañías, el caso de Globant, compañía dedicada a la creación de productos de software, es más que ilustrativo.
En lo que va del año, la firma lleva reclutados unos 1.000 nuevos perfiles y espera finalizar el 2010 con un total 2.300 empleados. De cara al 2011, la apuesta es aún más fuerte: sus directivos estiman sumar al equipo entre 1.500 y 2.000 personas.
En diálogo con iProfesional.com, el líder de las prácticas de desarrollo de productos de software (CTO) y del área de Human Capital de Globant, Guibert Englebienne, contó que "estamos buscando profesionales con cierto seniority, pero también perfiles muy específicos como, por ejemplo, con mucho conocimiento en matemática o física para trabajar en el desarrollo de las herramientas de animación para películas.
"Nos cuenta encontrar este tipo de joven profesional. Estamos apuntando a PHP, gente de doctorados o muy buenos programadores", admitió Englebienne.
Como parte de su expansión, Globant optó este año por "federalizarse" y regionalizarse: abrió oficinas en Tandil, La Plata, Córdoba, Rosario, Chaco, Montevideo y recientemente en Bogotá, al tiempo que también duplicó su espacio en Buenos Aires. Y, en el corto plazo, la meta será desembarcar en Estados Unidos, creando centros de delivery de servicios en Sillicon Valley.
Los salarios
De acuerdo a datos de la CESSI, en promedio las remuneraciones de la industria del software son un 35% superior a la de otros sectores productivos registrados.

"Este sobresueldo que venimos pagando crece año a año", resaltó en diálogo con iProfesional.com el presidente de la cámara, Fernando Racca.
Y como si esta diferencia no fuera de por sí significativa, los niveles salariales son aún superiores en las empresas tecnológicas y en aquellas cuyo negocio principal es el desarrollo de software, en comparación con las áreas de Sistemas de las compañías de línea.
E incluso, en algunos casos puntuales, la escasez provoca una marcada arbitrariedad a la hora de acordar los salarios.


Tal como muestra el gráfico a continuación y teniendo en cuenta el 18% promedio de ajuste que -según un relevamiento de la consultora Mercer- se otorgará en el sector High Tech, a diciembre de 2010 las remuneraciones del serán:

Desde Michael Page, Zunino no dudó en señalar que "los salarios del sector IT están por encima de la media del mercado" y que "en las empresas propiamente de Sistemas son más altos aún".
"A las compañías se les dificulta mucho la incorporación de un nuevo profesional, en un mismo rango de seniority, como puede ser analista senior, con el área de Finanzas o Supply Chain y les impacta mucho en la estructura de remuneraciones, ya que tienen que pagarle más porque son posiciones difíciles de conseguir en el mercado", advirtió la consultora.
En línea con los datos provistos por la firma de análisis de mercado Prince & Cooke, Zunino apuntó que "la remuneración varía de acuerdo a tecnología, pero el salario de un analista senior puede llegar fácilmente a los $8.000 brutos, un sueldo que en otras áreas corresponde a los niveles de jefatura".
Y añadió: "En este mercado, los profesionales van a las entrevistas sabiendo que tienen las de ganar y que pueden llegar a conseguir el salario que tienen en mente. Sin embargo, esto crea hipotecas que en un futuro pueden terminar pagándose."
En esta línea, Juan Martín Giachino Chavez, director de RH Humans Group, una firma especializada en selección de perfiles de IT, manifestó que "como las empresas que trabajan las últimas aplicaciones de IT tienen que asegurarse los recursos para trabajar y cumplir con determinados plazos y proyectos, no especulan con los sueldos, sino que ofertan lo máximo posible para tener los recursos."
Al igual que Zunino, el consultor aseguró que "al haber poca demanda de especialistas en nuevas tecnologías como .NET y Flex, entre otras, en muchas ocasiones son los mismos candidatos quienes determinan la remuneración para trabajar".

En tanto, Verónica Contin, selectora de Recursos Humanos también experta en perfiles IT, sostuvo que "entre estos perfiles muchas veces entra en juego la especulación".

Y añadió: "Para aceptar un puesto, los candidatos suelen establecer requisitos como cuatro semanas de vacaciones, trabajo part time por el mismo salario que full time, bonus anual, perspectivas de crecimiento a corto plazo y hasta la condición de que la distancia del trabajo a la casa no supere las diez cuadras o sea dentro del mismo barrio donde reside".

Nota a los "Apuntes sobre Factorías de Software..."

Observo que en la recopilación bibliográfica faltan referencias a Jack Greenfield, Keith Short y sus trabajos sobre factorías de software (Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, y otros documentos).  Una omisión involuntaria, básicamente porque sobre este tema se ha escrito mucho aquí mismo (1, 2). Solucionaremos su ausencia.

Apuntes sobre Factorías de Software,III

Quisiera cerrar un comentario de hace un año sobre factorías de software. El tema surgió, como se dice en la primera nota, de un incidente ya superado con la definición del concepto en Wikipedia. Aquel incidente inicial me motivó a conversar con algunos colegas en el interés de aportar una definición más adecuada que la que en un momento tuvo. De esas conversaciones surgió un borrador que nunca llegó a integrarse a Wikipedia, dado que el problema que lo motivara dejó de existir. Sin embargo, el borrador quedó, y estas sucesivas notas publican lo que todavía pudiera ser de interés.
Entonces, para cerrar ese documento, se despliegan ahora los dos o tres puntos de algún interés y de los que aún no se haya hablado...
Cusumano sobre la industria japonesa
Dice Cusumano sobre la industria japonesa del software, para el período 1970/90, reconociendo diferencias entre procesos a los que se puede aplicar un estilo de factoría de software, y aquellos donde no es adaptable:

As for the future of Japanese-style factories as a way of organizing software development (and perhaps other types of design and engineering work), it remained possible that large centralized factory organizations represented a transitional stage in the evolution of Japan's approach to managing software development technology.
Between the late 1960s and the early 1990s, the factory initiatives provided a useful mechanism to centralize, study, and manage a series of projects more efficiently than treating each effort as separate, with scale economies restricted to individual jobs and no scope economies systematically exploited. With improvements in electronic communications technology, it was no longer essential to concentrate large numbers of people in single locations, as seen in the NEC and Fujitsu cases, although Hitachi and Toshiba managers clearly preferred to bring people together, and it seemed more likely that factory-like organizations would continue to co-exist with job shops, depending on the kind of software being built as well as company objectives.
In general, factory strategies appeared best suited for software systems that could rely on reusable designs and components as well as common development tools and techniques. For totally new or innovative design efforts, Japanese software producers tended to utilize less structured organizational forms, such as special projects, laboratories, or subsidiaries and subcontractors, that gave individual engineers more freedom to invent and innovate. To the extent that Japanese firms wished to place more emphasis on individual creativity, they were likely to build more software in non-factory environments as well as emphasizethe design and engineering roles of personnel in internal projects, especially since new engineering recruits in Japan seemed to prefer labels other than "factory" to describe their places of work.
(Cusumano, Shifting Economies: From Craft Production to Flexible Systems and Software Factories, pag 46)

Reflexiones de Aaen,  Bøtcher y Mathiassen sobre flexibilidad
Del trabajo de Ivan Aaen, Peter Bøtcher y Lars Mathiassen (Software Factories), mencionado al inicio de esta serie, quisiera destacar el enfoque abierto de su investigación:

The term factory signals a commitment to long-term, integrated efforts—above the level of individual projects—to enhance software operations. This is not only a powerful, but also a necessary idea taking the challenges involved in professionalizing software operations into account. But for many the term factory has at the same time the controversial connotation that software development and maintenance is comparable to mass-production of industrial products, and arguably this is not the case. This can easily lead to illusions with respect to the kinds of interventions that can, in fact, improve software operations. It is not surprising, therefore, that some software professionals like the concept while others do not.
The term factory can be used to denote either one or more buildings with facilities for manufacturing or the seat of some kind of production. To many people the concept of a factory also implies a particular way of organizing work with considerable job specialization,formalization of behavior and standardization of work processes.
In this paper we will not adopt this historically based connotation. Rather we use the term without assumptions regarding particular ways to standardize, formalize, specialize, or achieve functional
grouping. The factory is an organization inhabited by people engaged in a common effort, work is organized one way or the other, standardization is used for coordination and formalization, and systematization is important, but there will be several options for the design of a particular software factory. This paper investigates how existing approaches to the software factory has chosen among such options by fitting each approach into one of Henry Mintzberg’s five basic organizational structures (Mintzberg, Structures in Fives: Designing Effective Organizations, Prentice-Hall 1983): the simple structure (organic, centralized, direct supervision); the ad-hocracy (organic, decentralized, mutual adjustment); the machine bureaucracy (bureaucratic, centralized, standardized processes); the professional bureaucracy (bureaucratic, decentralized, standardized skills); and the divisionalized form (decomposed based on standardized output).
(...)The goal is to clarify useful contributions and possible illusions related to the idea of a software factory.
(... ) We agree with Cusumano that the challenge for software management is to find ways to “improve organizational skills—not just in one project but across a stream of projects. To accomplish this, however, and still meet the demands of customers, competitors, and the technology itself, requires firms to balance two seemingly contradictory ends: efficiency and flexibility” (Cusumano 1991, p. 5).
The inherent complexities involved in developing and maintaining software suggest that the appropriate organizational form for a software operation is the professional bureaucracy in which professional competence is viewed as more important than standardized procedures and advanced technologies. Software managers are therefore advised to view the professional bureaucracy as the ideal and dominant form while elements of the machine bureaucracy and other organizational forms (Mintzberg 1983) should be treated as supplements to cope with variations, to increase efficiency whenever industrialized procedures are feasible, and to allow for greater flexibility in unique situations where existing procedures and experiences are insufficient. For this reason any long-term management commitment to improve software operations should fundamentally be based on approaches focusing on software processes, (...) and view approaches focusing on infrastructure as supplementary strategies that can help develop environments in which processes and professionals are better supported.

Algunas líneas sobre fuentes reconocidas
Dos fuentes generalmente reconocidas sobre el tema, y con toda razón, son Michael Cusumano y Yoshihiro Matsumoto, citados y analizados por prácticamente todos los autores leídos. Luego, Michael Evans y Herbert Weber, todos ellos a fines de los ochenta o comienzos de los 90. Probablemente influídos por los estudios de estos autores, Hitachi, Toshiba, Fujitsu, el proyecto Eureka y el proyecto Thales son algunos de los más mencionados y analizados. Desde finales de los noventa, es CMM el conjunto de recomendaciones más analizado. En los últimos años se advierte una evolución de estos trabajos a investigaciones orientadas a desarrollo basado en modelos y a los conceptos de Lineas de Producto Software (SPL), que en general no se han comentado en estos apuntes, aunque sí en infinidad de otros.

En cuanto a obras básicas sobre Factorías, estas son algunas de ellas:

Cusumano, M. A. (1989): The Software Factory: A Historical Interpretation. IEEE Software, Marzo.
Cusumano, M. A. (1991): Japan’s Software Factories. Oxford University Press.
Matsumoto, Y. (1981): SWB System: A Software Factory. En H. Hunke (Ed.): Software-Engineering Environments. Amsterdam: North-Holland.
Matsumoto, Y. (1987): A Software Factory: An Overall Approach to Software Production, En P. Freeman (Ed.): Software Reusability, IEEE.
Matsumoto, Yoshihiro y Ohno, Yutaka, “Japanese Perspectives in Software Engineering”, Addison-
Wesley Publishing Company, 1989.
M. Paulk, B. Curtis, M. Chrissis and C. Weber, Capability Maturity Model for Software (Version 1.1),
Technical Report, CMU/SEI-93-TR-024, Pittsburgh, Software Engineering Institute, Carnegie Mellon
University, Febrero, 1993.
Weber, Herbert, (editor), “The Software Factory Challenge - Results of the Eureka Software Factory
Project”, IOS Press, 1997.
Michael W. Evans, The software factory: a fourth generation software engineering environment,John Wiley & Sons.
Un antecedente que en su momento apuntó Pedro Molina correctamente, es Parnas:
D. Parnas: On the Design and Development of Program Families. IEEE Transactions on Software Engineering, March 1976, antecedente también de SPL.

Algunos papeles leídos en el curso de esta recopilación, han sido:
Concepto y Evolución de las Fabricas Software, Javier Garzás, Mario Piattini
Software Factories, de Ivan Aaen, Peter Bøtcher y Lars Mathiassen.
Improving MDD Productivity with Software Factories, de Benoît Langlois, Jean Barata, y Daniel Exertier
Making the Software Factory Work: Lessons from a Decade of Experience, de Harvey P. Siy, James D. Herbsleb, Audris Mockus, Mayuram Krishnan y George T. Tucker
Diffusing Software-based Technologies with a Software Factory Approach for Software Development, A Theoretical Framework, de Lim, Ngang-Kwang, Ang, S. K. James, y Pavri, F.N.
Otros de Cusumano y Matsumoto han sido mencionados antes.

Provincia de Córdoba, promesa de liderazgo tecnológico

Patricio Eleisegui, en IProfesional, comenta las afirmaciones y proyectos expuestos por dirigentes de las empresas y cámaras de la industria del software cordobesa. En crecimiento desde hace ya varios años, estimulada por la ley de promoción del software, la alianza de empresas nacionales e internacionales junto al estado y la Universidad, están sentando las bases para un desarrollo robusto y estable de sus negocios. Tan robusto como las frágiles condiciones que Argentina permita. El artículo:
Con el futuro como mayor apuesta, Córdoba sigue avanzando para consolidar el funcionamiento del entramado de empresas que hoy diseñan y fabrican desde software hasta equipamiento de telecomunicaciones en suelo mediterráneo.

De la mano de gigantes como HP, Intel, y Motorola, la provincia aspirar a facturar unos $4.000 millones por año en una década, y mantener empleadas a más de 35.000 personas. Avanza la construcción de un parque que aglutinará al grueso de las empresas.  En esa dirección, la alianza que conforman los sectores público y privado dio a conocer las bases de lo que representa el máximo desafío para los próximos años: transformar a Córdoba en la quinta productora mundial de tecnología.

Incentivar la formación de recursos humanos especializados en las diez universidades y centros de estudio que operan en ese territorio, acentuar la integración de las distintas compañías del segmento en espacios específicos, como el ya en desarrollo Parque Empresarial Aeropuerto (PAE), y elevar el perfil exportador de la industria cordobesa son algunos de los objetivos trazados y enunciados por las principales voces de esa provincia.

Pero más allá de estos preceptos, desde núcleos empresariales como el Cluster Córdoba Technology no dudan en adelantar los números que apunta a cosechar el sector IT mediterráneo.

“Para 2020 queremos facturar $4.000 millones anuales, de los cuales el 40% vendrán de las exportaciones. Y emplear en la provincia a 35.000 personas”, precisó Mario Barra, titular del Cluster.

La apuesta, en virtud del escenario actual, resulta sumamente ambiciosa. El mercado de las tecnologías de la información cordobés hoy brinda empleo a casi 8.000 profesionales y factura más de $800 millones por año. Los antecedentes, aseguraron a iProfesional.com fuentes de la Secretaría de Industria de Córdoba, permiten anticipar que la meta puede ser alcanzada antes de la década prefijada.

Sucede que desde 2001 a la fecha, la facturación de las desarrolladoras de tecnología con asiento en suelo cordobés se multiplicó por diez, y el nivel de contrataciones de personal pasó de los 650 técnicos a los 8.000 actuales. Asimismo, la producción local partió de los $10 millones en exportaciones, hace casi una década, hasta alcanzar los actuales $300 millones.

“En Córdoba se viene dando un fenómeno muy particular de agrupación de empresas tecnológicas. Es un caso de asociatividad que incluye al Estado y las universidades de la que no había experiencia en la Argentina”, comentó a iProfesional.com Erardo Rozzano, presidente de la Cámara de Industrias Informáticas, Electrónicas, y de Comunicaciones del Centro de Argentina (CIIECCA).

“Hace unos años el Banco Interamericano de Desarrollo financió un proyecto llamado Cadena Productiva. Córdoba fue hasta el momento la única experiencia que funcionó. Ya sumamos 80 empresas, en su mayoría cordobesas, que facturan 160 millones por año. Y con estimaciones de que en este período aumentaremos la comercialización un 15 o 18 por ciento”, agregó.

En un tono similar, Fernando Racca, presidente de la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI), destacó las particularidades de la experiencia cordobesa.

“Es un ejemplo muy significativo de asociación de empresas locales. Después se dieron otras etapas, marcadas por el ingreso de grandes como Motorola o Intel. Todas con el respaldo de promociones, y ciertas facilidades en lo que hace a disponibilidad de mano de obra calificada”, resaltó Racca a iProfesional.com.

Para luego añadir: “Todo eso derivó en una situación de prácticamente pleno empleo en el sector. También se dio en un momento en el que faltan los recursos. De ahí que muchas empresas que antes operaban en la provincia de Buenos Aires terminaron por mudarse al interior para encontrar recursos formados”.

Nombres e ideas de peso
La presencia en la capital provincial de nombres de peso como Intel, Motorola, Hewlett-Packard (HP), y la española Indra, es otro de los argumentos que enarbolan tanto funcionarios como empresarios al momento de dar por sentado que se alcanzarán los objetivos pautados.

“A eso hay que sumarle el desarrollo del Parque Empresarial Aeropuerto (PAE) en cercanías de, precisamente, el aeropuerto cordobés. Se trata de una iniciativa que motorizan privados como Electroingeniería, Astori, el estudio de arquitectura GGMPU, y la sociedad de bolsa Dracma”, precisó a iProfesional.com una fuente de la Secretaría de Industria cordobesa.

El PAE consiste en un proyecto inmobiliario que ocupará 46 hectáreas frente al aeropuerto Taravella. La propuesta contempla inversiones por u$s45 millones en sus dos primeras etapas, y prevé la construcción de más de cuatro edificios con oficinas, locales, comerciales y espacios gastronómicos.

Dentro de PAE, además de las firmas que lo impulsan, operarán más de 50 compañías pertenecientes tanto al Cluster Córdoba Technology como a la CIIECCA.

Actualmente en construcción, el parque ha sido uno de los requerimientos más solicitados por gigantes como Motorola o Intel, que visualizan al desarrollo como una herramienta que garantizará un mayor caudal de producción en esa provincia.

De acuerdo a fuentes locales, el gobierno cordobés se habría comprometido a invertir $30 millones por cada edificio destinado a estas compañías, aunque cada obra implica un desembolso superior y están en negociaciones con las empresas para establecer el aporte final.

“El diseño del edificio ya había sido pactado, y tenemos un proyecto aprobado que cumple con todos los requisitos legales y las regulaciones internas de Motorola”, indicó Álvaro Ruiz de Mendarozqueta, gerente del Centro de Software Córdoba de Motorola.

La firma estadounidense llegó a esa provincia en 2001 después de la promesa del entonces gobernador José Manuel de la Sota de “mejorar cualquier oferta” para lograr radicaciones industriales y tecnológicas en ese territorio.

Entre otros aspectos, el gobierno cordobés de ese momento se comprometió a edificarle una sede, lo que hasta ahora no se hizo completamente efectivo.

Motorola planea ocupar en PAE un terreno de 11.500 metros cuadrados, donde pretende desarrollar un edificio en dos etapas, la primera de las cuales permitirá albergar a más gente de la que actualmente trabaja en la firma (alrededor de 250 puestos).

Por su parte, Intel llegó a Córdoba en 2006 y ahora tiene en la mira un lote de 13.500 metros cuadrados ubicado al fondo del parque.

De acuerdo a La Voz del Interior, a principios de este año empezaron las obras de los primeros dos módulos del edificio del Cluster.

Tanto esta asociación como CIIECCA tienen destinados un terreno de 11.000 metros cuadrados, y ambas aglomeraciones serán asistidas financieramente por el Banco de Córdoba. Las obras estarían listas entre fines de este año y principios de 2011, según el cálculo de los responsables del proyecto.

Mario Barra, titular del Cluster Córdoba Technology, sostuvo que “PEA es una iniciativa que se articula perfectamente con las actividades descriptas en el plan estratégico del sector”.

“Generará mayor sinergia entre las empresas que se instalen en el parque, posibilitando la realización de proyectos conjuntos, dándole una mayor visibilidad y proyección internacional a las mismas”, dijo a iProfesional.com.


El trabajo con las universidades
Una arista fundamental del plan de crecimiento cordobés es la apuesta por la permanente formación de recursos calificados. Los centros de altos estudios que operan en ese territorio poseen una marcada tendencia hacia las ciencias duras, con planes que integran ingenierías y materias relacionadas con el cálculo matemático.

“En la provincia de Córdoba hay 10 universidades con 200.000 estudiantes. Es la ciudad de mayor porcentaje en la relación estudiante-población estable de América latina”, aseguró Roberto Avalle, ministro de Industria de Córdoba.

“Con la llegada de Motorola entendimos que era necesario coordinar mejor el trabajo con empresas y universidades”, agregó.

Rozzano, de CIIECCA, indicó que la mesa sectorial que integran privados y el Estado cordobés incluye, también, un plan de capacitaciones pautado para diez años de trabajo. “Necesitamos que sí o sí las universidades y las facultades de ingeniería sean parte del proceso”, dijo.

“Incentivamos el contacto permanente entre empresas y docentes. Y damos apoyo para que en muchas universidades incluso se incuben nuevos emprendedores. La formación de los docentes, por ejemplo, nos parece un elemento clave para el trabajo a futuro con los alumnos”, aseveró.

Apuntalado por estas medidas, el segmento tecnológico de Córdoba espera crear cerca de 30.000 nuevos empleos con el correr de los años. “Con ese número, se podrá incrementar el perfil exportador de lo que se hace en la provincia. Ya durante 2011 esperamos poner en marcha iniciativas para conformar, precisamente, nuevos grupos de empresas que vendan al exterior”, anticipó.

Al momento de dar cuenta de cuáles son las medidas que resta instrumentar para potenciar la actividad IT en esa parte de la Argentina, todas las fuentes consultadas apuntan a una misma dirección: lograr que el Estado se transforme en el principal receptor de los productos tecnológicos que desarrollan las compañías locales.

“Los gobiernos no le compran a las Pyme. Como el poder de adquisición del Estado no está concentrado ahí, entonces se pierde el principal motor de desarrollo que podría potenciar al sector. Hospitales, redes de generación eléctrica: todo puede ser abastecido por las empresas cordobesas. Pero lo concreto es que la participación del desarrollo local es mínima, y es algo que necesariamente hay que cambiar cuanto antes”, concluyó Rozzano.

Muchas expectativas, con un fundamento cierto. Pero también hay algunas preguntas: los números que el artículo muestra, reflejan que el grupo de empresas multinacionales exportan casi el total de su facturación, pero las nacionales, entre el 15 y 20%. La facturación de multinacionales (Intel, Motorola), representa la mitad de la que el Cluster tecnológico genera, pero su facturación de exportaciones es dos tercios del total de todas las empresas analizadas. La insistencia en el mercado interno, aún cuando se apoye en las compras del estado, no es suficiente, no solo por la inestabilidad económica crónica, sino por la escasa continuidad de las políticas de estado. No queda claro cuál es la apuesta por la innovación y el desarrollo de nuevos productos. No es lo mismo un modelo apoyado en el offshoring, que otro que apunte a conquistar nichos de mercado. La industria del software sin duda es una de las más susceptibles de globalizarse, y es riesgoso no apuntar a mercados y productos que trasciendan el mercado local.

Teletrabajo en Argentina

En los últimos años, el teletrabajo se extiende con fuerza en Argentina, al menos en algunas áreas de actividad. Aunque las cifras del Ministerio de Trabajo parecen algo exageradas, el fenómeno es más que interesante: de un universo de alrededor de doce a catorce millones de personas trabajando, 1.600.000 usarían alguna forma de teletrabajo. Escribe Cecilia Novoa, en Iprofesional, respecto a sus ventajas y desafíos:

Impulsadas por la necesidad de bajar costos o con el fin de otorgar a sus empleados una política de flexibilidad, cada vez más empresas están recurriendo a las oficinas online. De hecho, según datos del Ministerio de Trabajo, en la Argentina hoy existen casi 1.600.000 teletrabajadores.

Concientes del crecimiento acelerado de la cantidad de personas que se desempeñan bajo este sistema de empleo a distancia, es que la cartera comandada por Carlos Tomada ultima los detalles para establecer condiciones "de mínima" que marquen reglas claras, tanto para los dependientes como para las compañias y prevé elevar en breve un proyecto de ley tendiente a regular la práctica.

Hasta que se promulgue esta ley, desde el Ministerio hicieron hincapié en varias iniciativas que ya están en funcionamiento. Una de ellos es el Programa Piloto de Seguimiento y Promoción del Teletrabajo en Empresas Privadas (PROPET) y al cual las organizaciones se pueden adherir obteniendo beneficios de distinto tipo. Hasta el momento, las tres pioneras fueron Telecom, YPF y Cisco.

En Estados Unidos y países de Europa, una de cada tres compañías implementa el empleo remoto, logrando así aumentar la productividad, disminuyendo el estrés y el ausentismo y motivando a los colaboradores.

En diálogo con iProfesional.com, Fabio Boggino, fundador de Jobing, la primera consultora especializada en la implementación de teletrabajo, asegura que esta práctica es una “necesidad” y que “es importante que los empresarios se den cuenta que así van a poder no sólo retener a sus talentos sino también atraer a la nueva Generación Y, jóvenes a los que, si no le dan este tipo de flexibilidad laboral, no los van a elegir para trabajar.”

Con más de 15 años de experiencia en el área de Recursos Humanos del Grupo Telecom, donde estuvo a cargo de la implementación del programa, Boggino destaca que el empleo a distancia es una herramienta efectiva, barata y rápida que sirve para mejorar el clima de trabajo y la satisfacción laboral, como así también disminuir los costos y optimizar los espacios.

No obstante, el especialista en RRHH advierte que “las compañías no deben caer en la improvisación ni en la informalidad. Tampoco deben apuntar sólo al ahorro de costos, sin pensar en la gente, ya que si la puesta en práctica se hace mal, el teletrabajo como política tiene todas las contras.”

“La empresa que implementa esta modalidad comienza el camino hacia la organización 2.0, dejando atrás la creencia y la costumbre de control horario para pasar a un control de resultados cumplidos. Cuando se trabaja por objetivos los empleados tienen que alcanzarlos, estén o no estén dentro de una oficina; esta es la mejor definición de teletrabajo”, apunta el consultor.

Y añade: “Con el avance de la tecnología ahora la información está donde uno quiere y esto abre un debate en las organizaciones en cuanto a la necesidad no sólo de seguir manteniendo altos costos en edificios corporativos sino también de exigir a los empleados que se trasladen diariamente de sus casas a las oficinas.”

En la actualidad, Jobing se encuentra desarrollando sistemas de teletrabajo en grandes compañías bancarias, de telecomunicaciones y entretenimiento, entre otras. Según un sondeo realizado por la consultora entre 100 empleados remotos activos, con la implementación del empleo a distancia, se logra:

• Aumentar la productividad un 58%
• Mejorar la moral un 79%
• Disminuir el estrés un 63%
• Bajar el ausentismo un 64%

El relevamiento también arroja como conclusiones que 7 de cada 10 empleados considera que su trabajo en relación de dependencia puede hacerse por teletrabajo entre dos a cinco días por semana y que el 20 % de la rotación involuntaria de las empresas se produce por la falta de flexibilización horaria de los colaboradores.

A su vez, a cada colaborador el salario real le rinde hasta un 20% más, porque al trabajar de manera remota logra importantes ahorros en su traslado, en vestimenta y en almuerzos. Y, además, existen empresas que le abonan a su personal remoto un plus mensual a fin de que puedan cubrir determinados gastos -como la electricidad- que podrían generarse.

Sin embargo, de acuerdo a Boggino, el teletrabajo es el último paso. Así, para que una persona cumpla con sus funciones a la distancia y la experiencia sea exitosa, primero deben cumplirse cinco factores clave:

1. Los legales. Hay nuevos derechos y obligaciones de las partes y, por lo tanto, esto tiene que quedar plasmado en algún documento. No se renuncia a ningún derecho adquirido, todo lo contrario, se confirman, ya que lo único que cambia es el lugar donde se realiza el trabajo.
   
   
2. El foco en los perfiles y en las habilidades y competencias de la gente. Y no sólo del empleado que cumple su función fuera del domicilio legal del empleador, sino también del jefe que lo tiene que supervisar. De nada sirve que un teleempleado tenga todas las habilidades, compromiso autonomía, disciplina, organización, si su jefe, no sólo no está comprometido, sino que tampoco no puede liderar equipos virtuales. En definitiva, antes de iniciar un proceso de implementación de teletrabajo en una compañía, es fundamental instaurar el concepto de “teleempresario.”
   
   
3. El tipo de liderazgo que se requiere para teletrabajar. Es el de control de objetivos, no se necesitan líderes que controlen horarios sino que con esta nueva forma de organización, al colaborador se le pide que cumpla una tarea en un determinado tiempo, y donde la realice es un tema secundario.
   
   
4. La capacitación de los colaboradores involucrados en la experiencia. Se deben crear, por ejemplo, nuevas reglas de convivencia con su familia. Y prepararlos para trabajar en equipos a la distancia y con herramientas virtuales, como así también formarlos en seguridad laboral, entre otros aspectos.
   
   
5. La forma parcial. El trato humano y personal, es irremplazable. Por este motivo, lo ideal es que el trabajo a distancia no sea todos los días sino que se realice, por ejemplo, dos veces por semana, sobre todo para quienes tienen mucho tiempo de traslado o hijos pequeños.
   

Según Boggino, en el proceso deben involucrarse cinco actores clave: el CEO de la compañía (quien tiene que ser el principal sponsor y socio del cambio cultural) y las áreas de Recursos Humanos, Legales, Real Estate e Informática.

Evidentemente, no todo es posible de procesarse en forma remota; pero sin duda representa una innovación que bien aplicada puede ser especialmente productiva.
Un aspecto que el artículo no menciona, es el peso que en estas cifras representan las actividades vinculadas al offshoring, que han crecido particularmente: factorías de software, servicios de consultoría, centros de atención al cliente, factorías de diseño, actividades de publicidad.

Apuntes sobre Factorías de Software, II

De lo comentado antes, queda la impresión de que durante la época temprana del desarrollo del software, múltiples líneas de acción tendieron a darle sustento sistemático a su concepción y construcción, y en este contexto, la idea de aplicar el concepto de factoría fue una vía consistente de trabajo; primero iniciada en Estados Unidos, luego tomada con fuerza por Japón, y finalmente continuada en Europa. Tanto M. Cusumano como Y. Matsumoto señalan la conferencia de la NATO sobre Ingeniería de Software en 1968, como el punto de partida de los intentos de construír el software a modo de una factoría desde la Ingeniería de Software.
Ya se habló de Bob Bemer y M.D. Mcllroy, cuyos antecedentes se remontan a fines de los 60, y cuyas afirmaciones van en el sentido de mejorar procesos y procedimientos, medir, estandarizar herramientas de productividad, y establecer técnicas de reutilización del código.
Cusumano recoje a Mcllroy sobre reutilización de código, tan temprano como 1968:

The most important characteristic of a software components industry is that it will offer families of routines for any given job. No user of a particular member of a family should pay a penality, in unwanted generality, for the fact that he is employing a standard model routine. In other words, the purchaser of a component from a family will choose one tailored to his exact needs. He will consult a catalogue offering routines in varying degrees of precision, robustness, time-space performance, and generality. He will be
confident that each routine in the family is of high quality--reliable and efficient. He will expect the routine to be intelligible, doubtless expressed in a higher level language appropriate to the purpose of the component, though not necessarily instantly compilable in any processor he has for his machine. He will expect families of routines to be constructed on rational principles so that families fit together as building blocks. In sort, he should be able safely to regard components as black boxes.

[Citado por Cusumano en The Software Factory: Origins and popularity in Japan: M.D. Mcllroy, "Mass Produced Software Components," in Peter Naur and Brian Randell, eds., Software Engineering: Report on a Conference Sonsored by the NATO Science Committee, Brussels, Scientific Affairs Division, NATO, January 1969]

En este y otros papeles, Cusumano recoje a Bemer sobre métricas y factorías:

[A] software factory should be a programming environment residing upon and controlled by a computer. Program construction, checkout and usage should be done entirely within this environment, and by using the tools contained in the environment... A factory... has measures and controls for productivity and quality. Financial records are kept for costing and scheduling. Thus management is able to estimate from previous data... Among the tools to be available in the environment should be: compilers for machine-independent languages; simulators, instrumentation devices, and test cases as accumulated; documentation tools -- automatic flow-charters, text editors, indexers; accounting function devices; linkage and interface verifiers; code filters (and many others).

[Cusumano, en The Software Factory: Origins and popularity in Japan: R.W. Bemer, "Position Papers for Panel Discussion -- The Economics of Program Production," Information Processing 68, Amersterdam, North-Holland, 1969, pp. 1626-1627]

Objetivos semejantes impulsaron el desarrollo de las fábricas de software de Hitachi, Toshiba, NEC, Fujitsu, a partir de la década de 1970, y las de SDC de Rand Corporation en Estados Unidos. Estas acciones fueron analizadas detalladamente por Michael Cusumano, que entrega también una buena bibliografía sobre los esfuerzos dedicados desde los 60 hasta los 90. Particularmente destaca el trabajo de Matsumoto en Toshiba:

An RD group responsible for industrial systems software in Toshiba, led by Dr. Yoshihiro Matsumoto, introduced an organization and process in 1977 integrating tools, methods, management and personnel systems with a physical layout for work stations (...). The strategy for utilizing this infrastructure centered around four policies: (1) standardize the development process, to reduce variations among individuals and individual projects; (2) reuse existing designs and code when building new systems, to reduce redundant work and maximize productivity; (3) introduce standardized and integrated tools, to raise the performance levels of the average programmer; and (4) provide extensive training and career-development tracks for programmers, to relieve the shortage of skilled engineers.

Perhaps the most delicate feature of Toshiba's Factory was its organizational structure, a matrix imposed over product departments from several operating groups and divisions, all located on one site, Toshiba's Fuchu Works. Established in 1940 and set on 198 acres in the western outskirts of Tokyo, the Fucnu Works in 1991 had at least 8000 employees working primarily in four areas: Information Processing and Control Systems, Energy Systems, Industrial Equipment, and Semiconductors (Printed Circuit Board Division). Operating departments within the divisions corresponded roughly to 19 product lines, including systems for information and control in public utilities, factories, power-generation plants, and various industrial and transportation equipment. Each department contained sections for hardware and software design as well as for manufacturing, testing, quality assurance, and product control.

Similarities in the type of software the Fuchu Works built from project to project allowed Toshiba to deliver "semi-customized" programs that combined reusable designs and code with newly written modules, rather than writing all software from scratch. Toshiba also relied heavily on a standardized tool and methodology set, the Software Engineering Workbench (SWB), developed gradually after 1976and modelled after AT&T's UNIX Programmers Workbench. Toshiba utilized its customized version of the UNIX operating system as well as a full complement of tools for design-support, reusable module identification, code generation, documentation and maintenance, testing, and project-management. Important features of the Toshiba methodology were the design of new program modules (ideally limited to 50 lines) for reusability, the requirement that programmers deposit a certain number of reusable modules in a library each month, and the factoring in of reuse objectives into project schedules and budgets (Matsumura et al., 1987).

Software productivity at the Toshiba Software Factory rose from 1390 delivered equivalent-assembler source lines or EASL per person per month in 1976 to over 3100 in 1985, while reuse levels (lines of delivered code taken from existing software) increased from 13% in 1979 to 48% in 1985. The 3130 lines of EASL source code per month per employee translate into approximately 1000 lines of Fortran, the most common language Toshiba used in 1985 -- considerably more than the 300 lines or so of new code per month commonly cited for U. S. programmers making similar real-time applications. Quality levels (defined as the number of major faults detected after final testing) also improved dramatically after the opening of the factory, ranging from 7 to 20 per 1000 lines of delivered code converted to EASL to .2 to .05 in 1985 (the range depended on quality-control practices as well as the reliability requirements and the amount of testing customers contracted for) (Cusumano, 1991: 240).

Toshiba data indicated that reusability was the major reason for productivity and quality improvements. The organization Toshiba created to promote reuse and overcome short-term concerns of project managers and development personnel (such as the longer time required to write and document reusable software) relied on Software Reusing Parts Steering Committees and a Software Reusing Parts Manufacturing Department and Software Reusing Parts Center. The factory formed a steering committee for different areas (with different members, depending on the application) to determine if customers had a common set of needs suitable for a package, and then allocated funds from the Fuchu Works' budget for these special projects. Some packages were usable in different departments, although most served specific applications. The Reusing Parts Manufacturing Department and Parts Center evaluated new software (and documentation) to make certain it met factory standards; after certification, engineers registered the software in department or factory reuse
databases (libraries). Registered items required a key-word phrase to representthe functionality of the part or correspond to a specific object, as well as reuse documentation that explained the part's basic characteristics.
[Cusumano, The Software Factory: An Entry for the Encyclopedia of Software Engineering]

Al documento mencionado en la nota anterior, se agregan otros tres consultados del mismo autor, todos en el mismo sentido:

The Software Factory: Origins and popularity in Japan, Cusumano, Massachusetts Institute of Technology (MIT), Sloan School of Management, Working Papers (WP2036-88)

A quantitative analysis of U.S. and japanese Software-Engineering practice and performance, Cusumano y Chris F. Kemerer, en Management Science, Volumen 36 , número 11, 1990

The Software Factory: An Entry for the Encyclopedia of Software Engineering, Cusumano, Massachusetts Institute of Technology (MIT), Sloan School of Management, Working papers, (WP3268-91)

En resumen, las décadas de los 80 y 90, en estos y otros papeles, se revelan como un laboratorio precursor tratando de elevar la productividad especialmente en la industria japonesa: un aspecto fundamental es el papel motor de sus empresas, y la colaboración con instituciones de investigación universitaria. De paso, merecen un comentario aparte (será otro día) las observaciones de Cusumano sobre las diferencias de enfoque entre Japón y Estados Unidos.
Visto en perspectiva, este esfuerzo por plasmar factorías de software colaboró, junto a otras líneas de acción, a prefigurar áreas de investigación que ya nos son mucho más familiares: el impulso del análisis y diseño orientado a objetos, y el desarrollo de componentes. Digamos que desde el punto de vista histórico, las factorías están lejos de representar un retroceso en la forma de encarar la construcción de software. Matsumoto por ejemplo, muestra en la continuidad de su propia actividad cómo este pensamiento siempre estuvo en primera línea de la investigación acerca de mejores vías para la construcción de software.

Papeles sueltos sobre factorías de software

A partir de un incidente con la definición en Wikipedia para Software Factories (en ese momento, la única versión publicada de factorías de software) durante mayo de 2008, comencé a recopilar materiales sobre el tema, con la idea de consensuar con otros colegas una mejor, que abarcara lo que realmente designa el concepto. Durante unos meses reuní papeles, pero las dificultades de todos los participantes hizo que fueran quedando sin modificaciones. Pasando el tiempo, la propia razón que motivara el trabajo desapareció parcialmente, ya que, debido a las críticas levantadas por el artículo inicial, así como por el trabajo de depuración de los administradores de Wikipedia, el artículo fue desdoblado en una versión principal que habla del concepto histórico y de negocios de las factorías, y una segunda interpretación que se dedica al concepto de Jack Greenfield y Microsoft.
Para quien no hubiera visto el contenido original, motivo de polémica, una versión elemental se puede encontrar en The internet Archive, 2006 y 2007.
En fin, además de habernos permitido un trabajo reflexivo sobre el tema, también pudimos ensayar las facilidades de Google Docs (versionamiento, trabajo colaborativo).
Ahora, para cerrar el tema (o no), van aquí papeles y acotaciones surgidas durante estos meses que pueden tener algún interés para valorar las fábricas de software.
Las fuentes: tres publicaciones fueron la base para trabajar: Concepto y Evolución de las Fábricas de Software, de Mario Piattini (que revisó también el trabajo en curso) y Javier Garzás; Software Factories, de Ivan Aaen, Peter Bøtcher, Lars Mathiassen; y Shifting Economies: From Craft Production to Flexible Systems and Software Factories, de M.A. Cusumano. Los tres documentos fueron de mucho interés; los dos primeros proponiendo definiciones basadas en el estado actual, y Cusumano analizando la historia.

Las factorías de software son vistas con cierta animadversión en muchos casos, asimilándolas al establecimiento de un sistema de producción taylorista; en la discusión sobre la misma definición que en éste momento existe en Wikipedia, uno de los intervinientes afirma:

The concept of a software factory is not related to libraries within any IDE, or even the factory design pattern; but rather the organizational implementation of composite application building software engineering concepts. A software factory is a business operations concept of developing software applications through assembling components per specification. It utilizes assemblers, like any factory, who specialize and repeat their assigned tasks. This means that software is made primarily by unskilled labor, rather than engineers. It's more closely related to WYSIWYG web-pages built in DreamWeaver than anything that requires an understanding of code. Unlike that example, however, it implies a a job-floor filled with unskilled labor performing specialized tasks using tools that are designed to facilitate their jobs. You don't need the conveyor-belt maker, the torch engineer, or even a master welder, to repeat a single specific weld all day on cars moving through a factory. Likewise, not everyone involved in the software development process needs to be a software engineer. All they need are an understanding of their job, and useful tools. The requirements gathering, component/tool engineering, and similar jobs are handled elsewhere. The reason I know this is because I worked at a company with a software factory that quickly churned out fully functional applications. They used serious assembly tools and a set of components that meant no one had to even know how to read code

Esta es probablemente una realidad en muchos casos, particularmente para aquellas factorías construídas en países que explotan las grandes diferencias de costo, cuya principal actividad es el outsourcing de empresas localizadas en el otro extremo del mundo: son frecuentes las quejas de los contratantes sobre problemas de comunicación y entendimiento, y sobre la real calidad del proceso usado. Quejas frecuentes para empresas radicadas en India, por ejemplo. Sin embargo, la lectura de Cusumano, y de trabajos precursores de las décadas de los 70, 80 y 90, acercan las investigaciones sobre factorías, a los intentos por formalizar, medir, optimizar, las vías empleadas para la construcción del software. Sin negar la realidad de la visión anterior, es este aspecto, también existente desde su desarrollo temprano, el que ofrece más interés, y el que les da valor a las factorías desde el punto de vista de la ingeniería de software. Bob Bemer, McIlroy, a finales de los 60, proponen trabajar sobre la actividad de medición, mejora de la calidad de los procesos, reusabilidad, utilización de herramientas de productividad. Hitachi y Toshiba, durante la década de 1970, trabajaron ampliamente forjando herramientas y procedimientos de mayor calidad y consistencia, lejos de la imágen del taylorismo de factorías de software dedicadas a obtener contratos con el menor presupuesto posible. Una revisión del progreso del concepto a través de los finales del siglo anterior, muestra una estrecha relación entre la idea de factoría de software y las investigaciones que fueran forjando principios de la ingeniería de software. En buena medida, la idea de CASE, componentes, y la orientación a objetos, aparecen en papeles que relacionan los dos mundos. Más recientemente, la idea de Software Product Lines aparece claramente relacionada con las factorías de software. Hace algún tiempo, y en el curso de esta tarea, se ha comentado aquí el trabajo de Matsumoto, largamente vinculado al desarrollo de factorías, desde la organización de sistemas de producción hasta el desarrollo de líneas de producto. Nada de todo esto da la idea de una visión taylorista del negocio, salvo para aquellos que todavía creen que es posible el desarrollo del software como una artesanía, ni parecería que una organización de este tipo fuera posible con un equipo reducido de planificadores inteligentes, y una masa de ensambladores no calificados.
Fin por hoy. Volveremos sobre esto, quizá analizando bibliografía visitada.

Fotos: Yoshihiro Matsumoto, Michael Cusumano, Bob Bemer.

Un poco de criticismo sobre MS Oslo, II

Continúa la discusión entre Jean-Jacques Dubray y Douglas Purdy, con la introducción de algunas acotaciones de Charles Young. Una discusión farragosa, en la medida que se habla de algo que es un proyecto, sobre una base que a su vez se mueve. Creo que es válida la observación de Dubray, al menos aplicándola a la dirección de las investigaciones de Microsoft de los últimos años:

I am personally a bit sick of that, it seems that Oslo is taking the same path as WCF/WF and it will take years to undo quick "pragmatic" decisions made in the early days of the project. Considering that WCF was announced in 2003, shipped 2007 and being rewritten (one more time...) in 2009 for a release in 2010-2011, it looks like we should expect Oslo to do anything useful in 2014-2015 timeframe. I wish a lot more people would have the luxury to work with these kinds of time frames.

¿Será Oslo solo aplicable para la plataforma Windows? Tan pronto se desenvuelve cualquier discusión sobre el tema, éste se encauza por ese camino. En ese caso, el valor que se discute sobre la capa superior (meta-metamodelo) tendría escaso alcance.
Dubray puntualiza lo que Charles Young piensa al respecto. Todo lo dicho por Young es de mucho interés, pero particularmente sobre los objetivos de Oslo:

In this thought exercise, we are capturing models which are specific to a given technology. We need to be able to specify the metamodel very precisely in order to ensure that our models are valid and well-formed in respect to BizTalk Server. However, we will probably be less interested, in this scenario, in ensuring that our metamodels conform to some meta-metamodel. One reason for this is that we probably won’t have a compelling need to exchange BizTalk-specific metadata with other systems and applications. This could change over time, however. For example, as BizTalk Server evolves further, future versions may exhibit much closer integration with platform-level technologies such as WCF and WF, or standards such as BPEL4WS and BPMN. They may be more deeply integrated into platform-level host environments (this is already the case with regard to IIS-based ‘isolated’ hosts in BizTlk Server). In this case, the ability to exchange and transform metadata on the basis of some meta-metamodel could become an important consideration. Even here, though, we might wish to our meta-metamodelling to address a specific technology platform.

A major theme in Oslo is the reduction of the bar that ISVs and development teams face when seeking to support rich modelling approaches to software development and runtime configuration. Oslo is agnostic with regards to the number of metalayers that are required in any given scenario and makes no assumptions with regard to how platform/technology-specific or independent a particular model needs to be. It avoids forcing conformance to any abstract M3 specification and provides a general-purpose metamodelling language that minimises the learning curve for developers. To all this, Microsoft adds pre-defined mappings to T-SQL and is building additional tooling for generalised visualisation of models and parser generation tools for creating domain-specific modelling languages. They also provide many pre-defined models (e.g., for WF workflows) out of the box.

In our BizTalk Server example, the bar is now set very low. MSchema is a natural choice for defining model specifications whose conformance to the models in the BizTalk management database can be verified, but which can reduce the amount of detail to an appropriate level. The Oslo tooling can be used to create tables in the repository which correspond directly to the tables in the Management database. Access to models in the repository can be via any appropriate and familiar data access technology that can connect to SQL Server. There is no need for developers to engage in a steep learning curve in respect to meta-metamodelling, no need to conform to unfamiliar APIs and no need to inject an unnecessary level of platform independence in the way models are specified.

Charles Young historia las relaciones entre Microsoft y la OMG (UML, metamodels, MOF and MDA), hasta desembocar en las Software Factories y Oslo. Pero eso podría verse por separado. Curiosamente, esta historia de interrelaciones es prácticamente inhallable hoy.

Un proyecto interesante

Mark Dalgarno está comenzando un proyecto que podría ser muy interesante, tan pronto como sea acompañado por aquellos desarrolladores o teóricos interesados en el desarrollo guiado por modelos. Se trata de The Model Driven Software Network, que potencialmente puede convertirse en un foro abierto de discusión sobre el tema, con material y preocupaciones abiertos. Mark suma antecedentes de importancia para darle impulso: Es desde hace tiempo uno de los impulsores de Code Generation, así como de sus conferencias, y un especialista en Lineas de Producto Software. Una excelente combinación.

Software Factories + DSLs, en vía muerta?

Steven Kelly, uno de los desarrolladores de Metacase, arriesga una valoración que pone palabras a los hechos: Steven ve en Oslo, M, Quadrant, un camino divergente y de reemplazo de la publicitada línea de Factorías de Software por parte de Microsoft:

One of the interesting questions about Oslo is its relationship to DSL Tools. Actually, we should say between Oslo and Software Factories (the marketing side), or between M and DSL Tools (the technical side). Technically it seems there is no link -- which means no integration and no upgrade path. On the marketing side, few people seem to have picked up on the fact that Keith Short, co-author of the Software Factories book, moved to work on Oslo nearly two years ago. Steve Cook and Alan Cameron Wills, co- authors of the DSL Tools book, have also left the team, but for UML and MSF respectively.

Of course, people move around, and it's more interesting to hear what people still in those teams say. An Oslo developer writes:

If I look around, I see people doing [declarative, model-driven programming] today in the form of XML schemas and dialects, various textual reps, and frameworks that encode a domain. We went down that path as well, using visual designers and XML. But at some point the pain was too much :) We evolved our approach into Oslo.

Microsoft's "visual designers and XML" presumably refers to DSL Tools, and the comment about the pain being too much is perhaps at least one answer to the question of why Oslo isn't being billed as an evolutionary step along the Software Factories / DSL Tools path. It sounds more like Microsoft have concluded that their DSL Tools are an evolutionary dead end, have taken a step back, and are now heading down a different path. That's the impression I get from Keith Short's blog entry: "both Oslo and the DSL Toolkit have grown from a common belief" in DSLs.

Microsoft are of course claiming both products will continue to be developed, but losing 3 out of 6 main figures from the DSL Tools team is hardly encouraging. Mind you, I think what is needed is even more radical: both Oslo and DSL Tools should be put on hold until Microsoft have figured out what you need for an industrial strength language for describing modeling languages. The resulting languages and tools have to scale to multiple simultaneous users, multiple representational paradigms (graphical, textual, matrix, tabular), multiple platforms (not very likely that one!), integration between multiple modeling languages and multiple models, and evolution through multiple versions of the languages. There are a few more multi's I could add (look at slide 15 from my keynote to the OOPSLA DSM Workshop), but you get the picture. And if you want more than just the picture, get the tool!

El camino a recorrer es evidentemente evolutivo: si en efecto Greenfield, Keith Short, Steve Cook y otros apuntaron a aspectos insuficientes de UML, Oslo marca que aún hay camino por recorrer, y que los distintos emprendimientos todavía fallan cada uno en algo. Sobre las políticas comerciales de Microsoft mucho más se podría conversar, pero será otro día.

El software en tiempos de crisis, II

Mauro, un colega de Córdoba, me acercó la nota de Infobae acerca del efecto de la crisis sobre algunos rubros de negocio de outsourcing en Argentina. No pinta un panorama muy positivo, aunque probablemente habrá que mirar con lupa como evolucione.
Infobae resume declaraciones de Miguel Ángel Calello, de CESSI:

El sector del software y los servicios informáticos (SSI) de la Argentina, una de las actividades de mayor crecimiento luego de la devaluación del peso en 2002, comenzó a sentir los efectos de la crisis financiera internacional. “Ya empezaron a caer las gotas”, ilustró el presidente de la cámara de empresas de la industria, Miguel Calello.

Uno de los principales afectados es la línea de empresas que exportan servicios. Calello estimó que la baja de las exportaciones proyectadas para el sector en 2008, que eran de alrededor de $1.350 millones, oscilará entre el 10 y el 12 por ciento.

En una conferencia de prensa, posterior a la asamblea anual de la entidad, el empresario advirtió que “muchas empresas deberán cambiar su estructura de costos”, como consecuencia de la crisis, para no perder competitividad en los mercados externos.

“Los primeros que se van resintiendo” serán aquellos jugadores que apuestan a una mano de obra barata, como las factorías de software.

Pero la crisis también se refleja en la postergación en la toma de decisiones de compra y en la cancelación de contratos, señaló Calello, y en la parte financiera del negocio, con dificultades en la cobranza.

Igualmente, en la cámara empresaria del SSI esperan con cierta confianza los próximos meses, a la luz de lo ocurrido en 2002, cuando casi todas las compañías afiliadas a la cámara lograron sobrevivir a la devaluación del peso.

Esa experiencia “nos sirve –dijo- para saber cómo manejarnos”. En ese sentido, rescató que “la adaptación al cambio y la creatividad” de las firmas locales ayudarán a generar nuevas oportunidades.

Sin embargo, advirtió que las empresas del SSI no se quedarán de brazos cruzados sino que reforzarán los esquemas de asociatividad para salir a buscar nuevos mercados en el exterior, y además renovarán sus reclamos al Gobierno nacional.

Al respecto, Calello (...) sostuvo que pedirán a la administración de Cristina Kirchner que centralice en una sola área toda la relación del Gobierno con el sector SSI, hoy dispersa entre casi todos los ministerios del Poder Ejecutivo.

También la cámara propondrá una nueva ley para el sector del software, que modifica la norma sancionada en 2005 y que otorgó beneficios impositivos y fiscales por 10 años. Entre los cambios propuestos figura el establecimiento de un plazo de tres años para certificar procesos de calidad, que se contaría a partir del momento que la empresa es autorizada a recibir el beneficio fiscal, e incluir los reintegros del IVA a las compañías que exportan. Según informó la entidad, más de 240 empresas fueron aprobadas para la ley 25.922.

La cámara insistirá, además, con su reclamo para que el Estado considere a las compañías nacionales en sus compras de software. “Si esta industria es clave para el Gobierno, y la que más ha crecido en los últimos años, lo único que falta es que le compren. Tiene que entender que el gasto en tecnología local es una inversión”, advirtió.

Otra necesidad del sector es facilitar el acceso al financiamiento. “Un enorme porcentaje de la inversión se hace a través de capital propio. Tenemos que trabajar en la constitución de capitales de riesgo. Esta industria necesita inversión, no necesita crédito”, explicó Calello.

También apuntó contra las universidades: dijo que las casas de altos estudios “no están para proporcionar servicios que compitan con el sector privado, sino para formar capital humano”, en referencia a los contratos de servicios que varias universidades firmaron con organismos gubernamentales.

En cuanto a la agenda digital que el Gobierno asegura se lanzará antes de fin de año, aclaró: “No es una agenda para la industria, sino que es una contribución del sector para la sociedad. Muchas veces se confunde y se cree que es un plan para la industria, y es importante remarcar que no es así”.

Además, pidió que se cumpla el principio de “neutralidad tecnológica” en las compras oficiales, para defender la propiedad intelectual y la inversión en investigación y desarrollo.

“Defendemos a la empresa local, sin importar su bandera. O sea, a aquella que está afincada en el país y participa del ecoclima de la industria. No queremos defender a las empresas golondrina. A partir de esta crisis, vamos a ver las que vinieron solamente a aprovechar la mano de obra barata”.

Para 2009 la cámara planea crear un centro de capacitación de alto nivel, que no será el mismo tipo de educación que ofrecen los planes mixtos de becas, denominados Ctrl F. El centro privado trabajará para empleados de los asociados o terceros que quieran formarse. Uno de los perfiles que formará será el de los consultores, para que las personas mayores de 40 años puedan reinsertarse al mercado laboral.

En las palabras de Calello no sólo se observan los riesgos específicos de la crisis, sino también alguno propio de la interminable falla argentina, particularmente las dificultades de financiamiento. Un problema compartido con todas las empresas, especialmente si por su tamaño no pueden optar por financiación internacional. Y un problema que la crisis general agrandará.

Sin duda habrá retraimiento de la demanda internacional, y seguramente el outsourcing de servicios tendrá problemas. Como ya se ha dicho, el software argentino debe aumentar la calidad de su salto al mercado exterior. Y la crisis puede significar pérdida de contratos, pero también nuevas oportunidades, si se sabe buscarlas. Esta es una mala época para los gigantes. Así como hemos visto el fracaso de muchas evaluadoras de riesgo incapaces de advertir el fallo de los grandes bancos (o interesadas en no ver), así también quienes deben "poner las barbas en remojo" en ésta época son los grandes jugadores, aquellos que facturan servicios y productos que no cuadran con una crisis. Parecen acertadas las previsiones de CESSI para mantener competitividad.
No está de más recordar un reciente estudio español sobre las oportunidades de éste momento:
"los Emprendedores son los que menos padecen la crisis al disponer de estructuras muy ajustadas y eficientes, fruto de la gestión eficaz y continua de máxima rentabilidad de los recursos." "Entre los entrevistados, más del 65% revelaron las oportunidades que se presentan en un mercado parado y azorado. Las posibilidades de consolidar el proyecto y hacerlo crecer aumentan con las reestructuraciones de empresas y plantillas" (Tech Sales Group, "Los Emprendedores, los más optimistas ante la crisis")

El software en tiempos de crisis

Vinnie Mirchandani comenta con optimismo las estadísticas de Software Magazine acerca de la persistencia de la aparición de nuevas empresas entre las 500 mayores. En otras condiciones hubiera descreído de su visión, pero quizá bajo condiciones de crisis sea posible una mayor diversificación. Como en otras áreas, la crisis puede representar oportunidades: el costo de las grandes empresas puede ser difícil de manejar para ellas, y llevarlas a situaciones de bajas posibilidades de maniobra. La necesidad de recortar costos puede favorecer a pequeños emprendimientos. Los grandes proveedores de outsourcing (India particularmente) pueden verse reemplazados por competidores nuevos, y los proveedores americanos tienen ventajas de proximidad. Los mismos indúes lo vienen tentando desde hace algún tiempo (Cognizant o Tata en Argentina, Brasil, Uruguay, Chile). Proveedores capaces de trabajar con pequeños equipos ágiles y basados en herramientas de desarrollo rápido pueden alcanzar un lugar. Habrá que recoger mediciones...

Leyendo a Matsumoto

Un aspecto relevante de la conferencia sobre Software Product Lines de 2007 fue el aporte de Yoshihiro Matsumoto. Decía la nota introductoria de SPLC 2007:

Yoshihiro Matsumoto is Adviser of ASTEM Research Institute of Kyoto. He started his career in Toshiba Corporation in 1954, where he took initiative in the applications of software to real time control systems and in building Toshiba Software Factory for those domains. After he spent 35 years in Toshiba, he switched to academic field and served a professor at Kyoto University, Osaka Institute of Technology, and Musashi Institute of Technology. He received Dr. Eng. degree from the University of Tokyo, and Fellow in 1982/Life Fellow in 2004 both from the IEEE.

Es notable el desconocimiento común sobre la actividad y logros de investigadores y profesionales japoneses en software, si nos atenemos a los medios usuales de difusión de noticias tecnológicas, aunque esto vale también en menor medida para la actividad de investigadores europeos. Lo más usual en las publicaciones de noticias tecnológicas es la atención hacia papeles de trabajo con orientación comercial, donde suele haber mucha hojarasca...Más profundamente, es probable que este desconocimiento provenga del distinto modelo de actividad en Estados Unidos y Europa, frente al japonés. En el caso de éstos últimos, el patrón de desarrollo es el de grandes empresas con investigadores empleados o academicos e institutos asociados. En el caso de Occidente, es mucho mayor el número de emprendimientos individuales o de pequeñas empresas, aunque también pese la acción de grandes conglomerados empresarios y estatales.
Como una confirmación de esta situación, Matsumoto ha logrado mención en el último tiempo gracias a su colaboración con Microsoft en la aplicación de ideas de Greenfield en Microsoft Japón (1 y 2). Pero su trabajo de investigación y de implementación sobre Factorías de Software y el sustrato que implica, tiene más de treinta años (cerca de cuarenta en realidad), siempre en Toshiba , y luego en la Universidad de Kyoto. En estos días, sigo su keynote en SPLC 2007, y su presentación sobre la Factoría de Software de Thosiba. Matsumoto trabajaba por una, y la denominaba como tal, tan temprano como 1977; y si me atengo a sus afirmaciones de 2007, basados en preparativos iniciados a finales de los sesenta. Volveremos sobre ésto.

Oportunidad para el outousourcing en Argentina

Pablo Pizarro me hizo notar (gracias a las facilidades de del.icio.us) la existencia de esta nota de BussinesWeek, de gran interés para Argentina y otros países de América Latina. Rachael King escribe sobre un fenómeno que era esperable: en la medida en que la industria del software en India (y otros países precursores del outourcing) se hace estable, sus costos se incrementan. Sumado esto a la creciente caída del valor del dólar, de la generalización de la subida de costos de India (y otros países que están pasando a una nueva fase de su desarrollo), ya las diferencias entre presupuestar en India o hacerlo en América Latina, no son tan grandes para la industria estadounidense (o europea). Sumado a las diferencias horarias, se está creando un mundo de oportunidades.
BusinessWeek sobre los costos indios:

Companies that traditionally rely on India for offshore IT services have been looking for that something beyond India for years, citing such reasons as high employee turnover and unreliable communications. But the search has taken on added urgency recently, especially for U.S. companies, as a weakening dollar has boosted the cost of IT services priced in India's rupee. Over the past five years the dollar has declined about 16% against the rupee. High real estate costs and expectations for tax increases also have diminished India's allure.
As outsourcing to India becomes more expensive, North American companies are more inclined to "nearsource," keeping work in the Western Hemisphere, where they can operate in a closer time zone. In years past a company could save 40% to 50% by hiring Indian firms to handle IT and other services, says Atul Vashistha, chairman at neoIT, a management consulting firm. Should the U.S. dollar continue its descent, that differential would shrink to 10% to 20%, he estimates. "If you're only going to have a 20% savings, clients start to think about time zone," Vashistha says.
(...) How much longer the world's companies will have financial incentive to outsource to India is a matter of lively debate. India's "advantage as an offshore location is fast eroding—its attractiveness takes a hit with each passing day," analysts at Forrester Research (FORR) wrote in a January, 2008, report. Forrester catalogued some of the well-known challenges, such as increasing staffing costs, turnover and strained infrastructure (BusinessWeek.com, 12/11/06). Yet, there are newer challenges as well, including the falling dollar and expected tax revisions that may increase the cost of relying on outsourcing providers.

Sobre la comparación de costos con América Latina:

Contracts are written in dollars, and as much as 60% to 80% of Indian service providers' revenue is in U.S. dollars, but more than half of their costs are incurred in rupees, according to an October report from Forrester. Indian outsourcing powerhouses like Wipro are feeling the squeeze. They've strived to cut costs, and now they're raising prices to keep margins from narrowing further. "We are relentlessly driving for higher pricing for our services and have seen price increases from our customers in the range of 3% to 6%, and our new customers are coming in at around 5% higher than our average," Wipro Chairman Azim Premji said on a conference call with investors on Jan. 18.
Duke University professor Arie Lewin estimates that the benefit of doing business, from a labor-cost point of view, in such locales as Bangalore, India, will disappear for some companies in three to four years. That's due to a combination of dollar depreciation, wage inflation, and other costs. Others say it will take longer. "Costs are escalating, so the level of labor arbitrage isn't as great as it used to be, but that's not to say labor arbitrage is disappearing, nor will it disappear in the next 10 years or so," says Sid Pai, partner and managing director of TPI India, a sourcing advisory firm.
Indeed, while costs are increasing in India, the country is generally less expensive than Latin America and most other locations, especially for companies that don't require high-end software developers. The average annual salary for an IT worker in the U.S. is about $75,000, according to a late 2007 report by Alsbridge, an outsourcing consulting firm. In India it's about $7,779 and in Argentina, it's slightly higher at $9,478. In Brazil, the annual wage jumps to $13,163, and in Mexico it climbs to $17,899. "The bottom line is that there aren't great alternatives with the scale, quality, price structure, and the lack of risk of India," says Stephanie Moore, vice-president at Forrester.

Sobre Argentina:

Kimberly-Clark (KMB) had time zone in mind when it hired Cognizant Technology Solutions in Buenos Aires to handle tech support for its SAP (SAP) software applications.
Kimberly-Clark was drawn by the available talent and the fact that the company has Argentine operations but also because geographical proximity and similar time zones make collaboration easier. "We picked Buenos Aires for a number of reasons, but we really felt from supporting SAP, it was the right place to be," says Kimberly-Clark Chief Information Officer Ramon Baez. The company also outsources application development and maintenance to Cognizant in Chennai, India.

BusinessWeek enfoca a México, Argentina, Brasil (especialmente) como posibles receptores de outsourcing en estas nuevas condiciones. Y queda claro que los competidores indios son promotores de este cambio, señalando a Cognizant, Tata, Wipro, e Infosys, como empresas de ese orígen que están activando la ventaja de la diferencia horaria, costo y calidad de recursos.
King de todas formas apunta que la escala de Latinoamérica está lejos de las posibilidades de India, particularmente. La oferta de desarrolladores (u otras áreas de outsourcing) será siempre menor a la esperable en India. Pero la oportunidad existe, particularmente en la medida que se puedan ocupar nichos de especialidad y mayor valor.

El desarrollo de software es un arte?

Rodrigo Corral ha publicado en su blog una entrada sobre la idea del software "al modo industrial" que se explica desde su nombre: "La falacia de la industrialización del desarrollo de software ".
Más de una vez aquí se ha hablado de este tema: en realidad forma parte de la temática de éste blog, y no hace mucho se ha escrito sobre ésto. Como en muchos puntos lo veo de forma muy distinta, creo que debería dedicarle algunas líneas, a modo de extensión de lo que dejé en su entrada como comentario.
En primer lugar, creo que Rodrigo escribe pensando en la industria del software, en empresas específicas, y en políticas comerciales y de recursos humanos. Es probable que en este terreno tenga razones para sus afirmaciones sobre la necesidad de reconocer el valor de cada desarrollador.
Pero no comparto que se extienda el cuestionamiento al propósito de establecer criterios que normalicen el proceso de construcción. Si aceptamos que existe una ingeniería de software, se debe aceptar también que sus intenciones son reducir el riesgo y la incertidumbre en la construcción de software, establecer procedimientos, medir y proyectar, utilizar patrones repetibles.
Por supuesto, el desarrollador tiene importancia. Pero un equipo, y un plan de construcción, no pueden depender de las individualidades: desde hace mucho, reducir la indeterminación ha sido una preocupación generalizada, ante la evidencia de que sin criterios claros de manejo del proceso, un proyecto puede convertirse en interminable, o mucho peor, terminar dramáticamente sin lograr sus objetivos. La historia de la industria está plagada de estos casos. Además, el software debe ser mantenible: no basta crear un software por única vez, sino que debe sostenerse en el tiempo: si dependieramos de las individualidades, cada vez que se produjera una baja del equipo de trabajo, la situación sería calamitosa.
A diferencia de lo que Rodrigo mencionara, como bien se puede ver aquí, creo en la positividad de todas aquellas líneas de investigación que tienden a asegurar procesos más confiables, sea en la utilización de procesos repetibles de manejo del ambiente de construcción (Administración de cambios, seguimiento de defectos, manejo de configuración), como en las herramientas mismas de modelado y generación (generadores de código).
No creo que ninguno de esos elementos vayan en perjuicio del desarrollador, del recurso humano, sino que proponen una actividad más creativa, particularmente en el caso de las nuevas generaciones de 4GL, que permiten poner el acento en el modelado, en lugar del "picado de código".
Quizá la línea de investigación de Líneas de Producto Software sea el ejemplo más generalizador y demostrativo de qué es lo importante del "sofware como industria": SPL propone el planeamiento anticipado, la utilización de patrones, el reuso de partes, la existencia de un repositorio de componentes, la utilización de herramientas de generación de código.
Finalmente, quiero hacer notar que una vía artesana de trabajo, considerando el volúmen que adquiere la intervención de la informática en la economía y la sociedad, si fuera realmente el paradigma aplicado, haría que un alto porcentaje de desarrollos corrieran totalmente por detrás de su necesidad.
En fin, repitiendo lo que le escribía a Rodrigo, "no me gusta la idea de que la construcción de software es un arte, y el programador, un artista. Reconozco que en su construcción hay lugar para la creación y para la belleza (de un algoritmo o de una solución de arquitectura), y que forma parte de la motivación, pero también a esa disposición se la puede calificar con otros nombres, más cercanos a la ingeniería. No me opongo a su existencia, y es excelente trabajar con colegas que den soluciones brillantes; pero no creo que sea conveniente basar una estructura persistente en individualidades, porque dependeremos de ellos. El software debe ser mantenible, y debe tener tiempos de construcción estimables, o al menos planeables. La metáfora de la fábrica siempre la interpreté en ese sentido, y estoy seguro que todos aquellos que han rondado esta idea, lo han hecho en la misma dirección".
Estoy seguro sin embargo, de que la diferencia con sus afirmaciones se reducen a un matíz, que sin embargo quizá sea de importancia.