Friday, September 28, 2012

What do software architects really do? - Review

Original Paper:
Name:  What do software architects really do?

By: Philippe Kruchten
This paper is published in 2008 and written by Philippe Kruchten, who was a Philippe Kruchten is professor of software engineering in the department of Electrical and Computer Engineering of the University of British Columbia. Qualification shows that he can answer the question “What do software architects really do?
This is one of the interesting papers that I have read. This made me interested because of two reasons. First, it is the language style that the writer has used. Then, it is the graphical representation that is used in this paper. At the start, writer take a nice opening with the dialog captured from the OOPSLA workshop in Vancouver in the fall of 1992. If I ask, the question “who is an architect?” answer can be given in the domain of the question “What do software architects really do?” This simply mean that this paper actually answer two questions, which I mentioned above.

Deviating from common definitions that can be found in the internet, this paper gives a more practical and measurable definition to the architect and what he does. In this paper, he talks about some common mistakes, which he call as “antipatterns” which fails software architect or software architecture team. As example “creating a perfect architecture, for the wrong system”, “creating a perfect architecture, but too hard to implement” was two antipatterns that is listed in the paper.
In the next section writer start talking about “Roles and responsibilities of an architect” where he mention eight main roles and responsibilities. We can see that not all of them talks only about the architecture of the system.  After that writer gives a nice graphic that clears, “What architect should do?” This graphic is drawn using, how the time of an architect is allocated. Here writer identify 3 main areas, where is spent.
1.    Architecting: architectural design, prototyping, evaluating, documenting, etc.
2.    Getting input: listening to customers, users, product manager, and other stakeholders (developers, distributors, customer support, etc.). Learning about technologies, other systems’ architecture, and architectural practices.
3.    Providing Information: providing information or help to other stakeholders or organizations, communicating the architecture, project management, product definition.
Writer recommends that, architecture should spend his time on these this in a 50:25:25 ratio.
In the next section writer shows, how each antipattern affects the above ratio. In addition, all of these faces are represented in graphs too. These graphs make it really easy to identify how those antipatterns effect in one site. Comparing these graphs will give you a clear idea of how damaging is each antipattern. If we take a team, these ratios will change from individual to another. These ratios will depend on the phase of the project; at the beginning, there will be more internal focus, where as in the development and transition phase there will be more outward focus. According to the writer, our main consideration is the ratios of the whole team taken together. This team ratio should hover somewhere near 50:25:25.
In last section, writer gives us a nice method of identifying and measuring the ratios. He elaborates on, how we can really implement this system in a practical way. Furthermore, he gives us a way of identifying how each work by a architect can be categorize as a inward outward or architecting. This is simple method that will not cost you anything for trying. Therefore, try this in your workplace. Let the writer know your experience in that.
Reviewed By: Romesh Malinga Perera, Undergraduate, University of Moratuwa.