Name: What do software architects really do?
Download: http://goo.gl/906Yk
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.
No comments:
Post a Comment