Attended a small event organized by ThoughtWorks in Pune, more on that here. This article primarily focuses on the session on Role of architect by Vivek Singh. The brief on session follows.

## Role of architect

Being a technical coach

If we use analogy of football game, the role of an architect in a software project is that of a coach in football. Architect is to know and guide his team about all latest techniques and work methodology, correcting them where needed.

Taking delivery ownership

In general in software industry it is seen that architects design and recommend technologies and methodologies, but if a software project fails to deliver/has issues, the blame goes on either team or “project manager”. The failure is generally put with execution, which may not be entirely fair. Architect of an project has and should take an equal ownership of the project and there by being part of its success or failure.

Being a coach who plays- very important!

Have you seen a football coach? He goes on field and shows things to team members by “doing” them. Doing is important. An architect who has not written a single line of code fr years, would be for sure far less competent to understand the problems being faced at ground level. One of the the techniques which can be effectively used here is to go for pair programming for small stories (In case of Agile projects). This way the architects would not get bogged down by daily routine of “doing work” at the same time, will have there hands on going on.

Its important to do/code, but at the same time architect has to keep a track of the 10K view of things.

Understand more than application architecture

Software systems are getting more and more complex and its important for the architects to understand not only how the application in question works, but a bigger picture as in how the application is going to interact with other applications.

Dev process, team org.

Architects in general leave it upto the project manager to define and manage the team, the development process and documentation part of it. Its imperatively important that architects do attend the daily stand up and “listen” to team members and understand the issues being faced in dev process and team dynamics.  Architects should also be part of the retrospects and reflect on the areas which need improvement and areas which are strong points of the team.

Manage technical debt

Its important for an architect to manage the technical and design debt in an project.

The last word: Documentation

Most of the developers, agile practitioners are anti-documentation types, going by the argument that “code” is the “document”. While the process of “documentation” may not be important, but the process of design and thinking is important. Also there are multiples metrics collected in a typical SDLC cycle, but its important to see what is really useful and sustainable over the lifecycle of the project. As Deming puts it:

The most important things cannot be measured