Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Monday, December 19, 2005
El arquitecto de software
Al hilo de una conversación en BarraPunto sobre "Telecos e informáticos, los más solicitados", se discutió mucho sobre los colegios oficiales de ingenieros en informática, como siempre.
Uno de los comentarios que más puntos recibió consideraba comprensible que los ingenieros de nuestra especialidad abogasen por la implantación de colegios oficiales, siempre y cuando los ingenieros dejaran de "codificar" y se dedicasen a las tareas para las que realmente fueron concebidos y preparados.
Considero que este señor tiene parte de razón, aunque la línea que separaría un tipo de tareas de otras estaría bastante difuminada dado que la diferencia parece algo subjetiva. Sobre todo si tenemos en cuenta las típicas tareas que podría desempeñar un Arquitecto de software (y recordando que la aserción Architects Don't Code es un anti-patrón, es decir, algo totalmente incorrecto y a evitar). Algunas de estas tareas las mencioné en un comentario que puse de respuesta en BarraPunto pero las vuelvo a mencionar aquí:
Una de ellas, la número 3, la considero la más importante de todas y, paradójicamente, la que en general en la industria informática se tiene menos en cuenta. Hay que pensar que esta tarea no sólo sirve para cuidar la calidad de un desarrollo, también para evitar complejidades innecesarias, reutilizaciones de código no empleadas, y que ciertos personajillos se aseguren un trabajo de por vida a base de escribir código inmantenible.
Actualización 19-AGO-2007: Leyendo una entrada del blog de Ayende se me ha ocurrido otro elemento importante que hace un arquitecto de software: revisión arquitectural del sistema (pues la revisión no arquitectural de cada uno de los cambios de cada programador es una tarea demasiado larga como para que sólo la lleve a cabo una persona) para que el sistema no se convierta en The Blob (otro antipatrón). Ah, y Ayende también está de acuerdo en que Architects don't code es un antipatrón.
Actualización 27-SEP-2007: Veo que me siento totalmente identificado con las palabras de una acojonante entrada de Ted Neward, la cual voy a citar (énfasis añadido):
How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard.
Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out.
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
This is asking a lot of an architecture, granted. But that's the ideal.
What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have.
Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is always the right answer.
Actualización 09-FEB-2008: Voy a citar dos fuentes más de información que expresan muy bien lo que es un arquitecto de software o la calidad del software que éste debe perseguir.
La primera es un párrafo del mítico libro The Mythical Man-Month, válgame la redundancia, citado en esta entrada de Scott Rosenberg:
The goal of "conceptual integrity" or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
Por último, dos párrafos sueltos de una entrada de Ayende Rahien titulada "Don't meake me THINK!", que habla sobre arquitectura y usabilidad:
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
[...]
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Actualizacion 17-MAY-2008: Don't Let Architecture Astronauts Scare You es una interesante entrada de Joel Spolsky que desmitifica al perfil de arquitecto-soluciona-todo. No es que se meta con los arquitectos de software (aunque alguna frase sí me ha dolido, como Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve), sino con el aire marketiniano que se le da algunas veces a cosas relacionadas con la arquitectura, pero que al final acaban resolviendo algo interno (no visible al usuario).
Y me ha dolido porque pienso que la arquitectura sí es algo util de resolver/perfeccionar, dependiendo del punto de vista claro. Y aquí voy a usar el símil que el mismo Joel ha utilizado: ?le interesa al cliente de un supermercado saber que los productos se llevan en camión desde el almacen? No. Pero, ?es por eso menos importante la eficiencia de los procesos internos para que el cliente pueda disfrutar de su producto finalmente? No.
Actualizacion 02-NOV-2008: Es triste como parece que España sigue igual en cuanto a la mentalidad de muchos informáticos. Cuando alguien te diga cosas como "¿Programando a los 50? No, por favor" o "A ver cuando me ascienden para dejar de programar", es que no es un auténtico ingeniero de software con vocación, y me apuesto a que no sabrá ni siquiera lo que es un arquitecto de software (un puesto de lo más relevante, y que precisamente suele ser la aspiración de los que quieren progresar en su carrera pero sin dejar de programar, puesto que es su pasión).
Uno de los comentarios que más puntos recibió consideraba comprensible que los ingenieros de nuestra especialidad abogasen por la implantación de colegios oficiales, siempre y cuando los ingenieros dejaran de "codificar" y se dedicasen a las tareas para las que realmente fueron concebidos y preparados.
Considero que este señor tiene parte de razón, aunque la línea que separaría un tipo de tareas de otras estaría bastante difuminada dado que la diferencia parece algo subjetiva. Sobre todo si tenemos en cuenta las típicas tareas que podría desempeñar un Arquitecto de software (y recordando que la aserción Architects Don't Code es un anti-patrón, es decir, algo totalmente incorrecto y a evitar). Algunas de estas tareas las mencioné en un comentario que puse de respuesta en BarraPunto pero las vuelvo a mencionar aquí:
- Estudio de nuevas herramientas, librerías, componentes.
- Elaboración de guías de estilo de codificación.
- Revisiones de las implementaciones/parches de los programadores.
- Implementaciones de partes globales de un sistema, que posteriormente serán utilizadas por los programadores (p.ej: creación y mantenimiento de una herramienta base, un "framework" del negocio).
- Formación a programadores.
- Generación de pruebas unitarias y de regresión, y planes/herramientas para la automatización de estas pruebas.
Una de ellas, la número 3, la considero la más importante de todas y, paradójicamente, la que en general en la industria informática se tiene menos en cuenta. Hay que pensar que esta tarea no sólo sirve para cuidar la calidad de un desarrollo, también para evitar complejidades innecesarias, reutilizaciones de código no empleadas, y que ciertos personajillos se aseguren un trabajo de por vida a base de escribir código inmantenible.
Actualización 19-AGO-2007: Leyendo una entrada del blog de Ayende se me ha ocurrido otro elemento importante que hace un arquitecto de software: revisión arquitectural del sistema (pues la revisión no arquitectural de cada uno de los cambios de cada programador es una tarea demasiado larga como para que sólo la lleve a cabo una persona) para que el sistema no se convierta en The Blob (otro antipatrón). Ah, y Ayende también está de acuerdo en que Architects don't code es un antipatrón.
Actualización 27-SEP-2007: Veo que me siento totalmente identificado con las palabras de una acojonante entrada de Ted Neward, la cual voy a citar (énfasis añadido):
How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard.
Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out.
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
This is asking a lot of an architecture, granted. But that's the ideal.
What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have.
Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is always the right answer.
Actualización 09-FEB-2008: Voy a citar dos fuentes más de información que expresan muy bien lo que es un arquitecto de software o la calidad del software que éste debe perseguir.
La primera es un párrafo del mítico libro The Mythical Man-Month, válgame la redundancia, citado en esta entrada de Scott Rosenberg:
The goal of "conceptual integrity" or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
Por último, dos párrafos sueltos de una entrada de Ayende Rahien titulada "Don't meake me THINK!", que habla sobre arquitectura y usabilidad:
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
[...]
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Actualizacion 17-MAY-2008: Don't Let Architecture Astronauts Scare You es una interesante entrada de Joel Spolsky que desmitifica al perfil de arquitecto-soluciona-todo. No es que se meta con los arquitectos de software (aunque alguna frase sí me ha dolido, como Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve), sino con el aire marketiniano que se le da algunas veces a cosas relacionadas con la arquitectura, pero que al final acaban resolviendo algo interno (no visible al usuario).
Y me ha dolido porque pienso que la arquitectura sí es algo util de resolver/perfeccionar, dependiendo del punto de vista claro. Y aquí voy a usar el símil que el mismo Joel ha utilizado: ?le interesa al cliente de un supermercado saber que los productos se llevan en camión desde el almacen? No. Pero, ?es por eso menos importante la eficiencia de los procesos internos para que el cliente pueda disfrutar de su producto finalmente? No.
Actualizacion 02-NOV-2008: Es triste como parece que España sigue igual en cuanto a la mentalidad de muchos informáticos. Cuando alguien te diga cosas como "¿Programando a los 50? No, por favor" o "A ver cuando me ascienden para dejar de programar", es que no es un auténtico ingeniero de software con vocación, y me apuesto a que no sabrá ni siquiera lo que es un arquitecto de software (un puesto de lo más relevante, y que precisamente suele ser la aspiración de los que quieren progresar en su carrera pero sin dejar de programar, puesto que es su pasión).
Labels: General, Ingenieria, Programacion
# posted by knocte @ 2:47 pm 
