Who needs an architect?

I was asked to read a PDF writing by Martin Fowler, named who needs an architect. The publication is entirely about what architecture is and how is it important to the team.

I think, the reading is really about leadership. What type of leader you want to be? Because really, all an "architect" is, is a technical leader. It is a person that understands both the business needs and the infrastructure and software needs to tackle a particular problem. And leadership is really that, seeing the solutions of problems and accepting new challenges.

One of the things that I saw the most important is the relevance of agile methodologies in the role of an architect's team. Agile methodologies are a set of known structures of work that rely mostly on intense team collaboration, both internal (development teams, ops teams) and with the client teams, both business and developers. They are a set of ideas that will allow us to improve ourselves constantly by looking constantly in retrospective at ourselves.

Martin Fowler also describes a difference between two types of leaders. The kind of guy that imposes ideas upon others. That can not go with the flow of each day, and of each team, and also identifies the importance of the role of the leader that can communicate effectively with others. That improves this ideals that are really, more natural and understanding than what the Architectus realodus is.

What I take from this reading is that. How can we make teams appreciate their work? How can we make teams follow somebody for the conviction that they are leaders in some aspects, but that they themselves are a key role in executing this tasks. Both the team members, as much as the team leaders have key roles in making projects happen, and in overcoming more and more and newer challenges.


Diego Canizales 

:)

Comentarios

Publicar un comentario

Entradas populares de este blog

Software Architecture

Software architecture is about common ground . Common understanding and standardization of means to solve this problems is the way to get somewhere. The way I see it, software architecture is about getting that common ground to be as easy to read, and maintain as it could be. Sometimes, in the software world, and us as developers, we tend to move fast. We tend to want to go different places and learn new things, or actually just develop different things. This constant moving of parts is no good for our proyects. For example, when we hire someone new because we need help in solving our particular problem, we have to teach them about the problem first, and then teach them how to use our particular set of tools, and then teach them how our architecture actually looks like for them to kind of understand where we're heading. The better the common ground  is, the better the new developer will be able to see where we're actually really strong, and where we're actually really weak....
Leer más

Is Design Dead?

The philosophy that is behind some of the software development practices that we commonly use in our workplaces, have grown around a vast necessity of winning the race. Sometimes, we forget that winning the race is not as important as ensuring that we will always be able to win the race in the future. This being the case, the new era of software design paradigms have born, like eXtreme Programming, which bases it's main ideas in doing things as agile and as fast as possible. Enabling projects and developers to have this level of agility, and has got some pro's and con's to consider. For starters, XP programming is based around the idea that you have to really do things, not just think about doing things. Cutting time in the design phase of the process, and giving it to the implementation and testing stages of the process can be a two-edged swords: You have a solution that's ready to use right away, but you're not a hounded percent sure that it will not represent mo...
Leer más