It is one of those catchy heading you deliberately create to grab attention. (So is the case with the latest Microsoft Architecture Journal). I strongly recommend budding architects to read this article. I believe this is one artifact (the Architecture Journal) that MS churns out that carries unbiased views.
“The role of an architect in software development has come under attack of late. On software projects, the title Architect is often ambiguously defined and the value provided by architects is not easily quantifiable. The perception that architects live in an “ivory tower” disassociated from the realities of delivering a software solution contributes to some of the animosity toward those of us with the title.
This article presents a defense of the practice of architecture in software development. It defines the qualities of an effective architect and describes the skills required to succeed in this profession. The article examines widely held perceptions of architects and some of the mistakes that architects make which contribute to negative perceptions. Ultimately, the intent is to show the value good architects bring to a software development effort.”
.gif)
We do need Architect, if only everyone understood and agreed on what an architect does.
What do architects really do? What are their roles and responsibilities?
1. Defining the architecture of the system
All the usual technical activities associated with design. Understanding requirements, qualities, extracting architecturally-significant requirements, making choices, synthesizing a solution, exploring alternatives, validating them, etc.; For certain challenging prototyping activities, the architects may have to use the services of software developers and testers.
2. Maintaining the architectural integrity of the system
Through regular reviews, writing guidelines, etc. and presenting the architecture to various parties, at different levels of abstraction and technical depth.
3. Assessing technical risks
These role is in support of project management, but on very technical risks, managers may not have the expertise to identify and
4. Working out risk mitigation strategies/approaches
5. Participation in project planning
6. Proposing order and content of development iterations
For many effort estimation aspects, or for the partition of work across multiples team, managers need the assistance of architects.
7. Consulting with design, implementation, and integration teams
Because of their technical expertise, architects are drawn into problem-solving and fire-fighting activities that are beyond solving strictly architectural issues.
8. Assisting product marketing and future product definitions
The architects have insights into what is feasible, doable, or science fiction and their presence in a product definition or marketing team maybe very effective. As you see, beyond item #1, many activities involve some other party: project management for example, and are not merely focused around the architecture, the design, the architectural prototype.
We need also to keep in mind that the good architects should bring a good mix between domain knowledge, software development expertise, and communication skills. Once we identify (and possibly refine) the long list of what we expect the architects to be doing, the next question is: how do we keep a good balance between all these activities. How do we avoid the temptation to always, day after day, week after week, solve the most urgent problem, or the most interesting problem, or extinguish the latest fire? (The squeaky wheel syndrome) Or conversely bring forward the question: do we have the right people with the right expertise in our current software architecture
Your thoughts? Please share your comments!
References
Kruchten, P. (1999). The software architect, and the software architecture team. In P. Donohue (Ed.), Software architecture (pp. 565-583). Boston: Kluwer Academic Publishers