The only reason why I would want to be an Architect is to have the street cred

I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important (Martin Fowler)

 

What does an Architect do?  If we're talking about building a bridge, then probably the person is in charge for designing the structure, calculation, cost and what not. Would a Software Architect be a direct counter part to this role?

I would consider an architect as someone who's responsible for making the difficult decision. These decisions are the ones that are hard to fix if not impossible to undo.

So for a Software Architect, what are these key decisions most likely be?

Aligning long term plan with long term vision

A software architect is probably asked to ensure that the overall software system supports the business goal for the specified amount of time.

Deciding on the expensive stuff

Someone needs to be responsible for making decision on team model, framework selection, third party services and more. It would make sense for a Software Architect to do this.

Coordinating the work

A Software Architect is also probably responsible to send the message to the rest of the team. Sending out the mandate from the mothership.

Taking the blame

The bad (good) thing though, this person is probably most likely will get the blame if there's a catastrophic issue with the produced software system.

 

With that out of the way, does it mean we need a Software Architect on every project?

We need an architect when things are hard to change

Things that are often perceived as hard to change might not ever change, or at least can easily be designed so that it can easily be changed.

We need an architect to guide the development teams

It takes a super human (er.. super-developer?) to do the role of a Software Architect as described above well. Making thorough decisions upfront requires black magic (although some might argue it should be called ’╦ťexperience'). With the amount of variables, and moving pieces, only people with the best of knowledge on both the operational and business long term vision can take up on the responsibility.

Unless a Software Architect can confidently predict everything upfront with little room of failures, most Architects should be with the team, attend stand ups, take part of code reviews, take on critical user story/work items/task, do unit test, not break the build as much as the next guy. More importantly, this person is responsible for sharing the vision and long term business goals with the rest of the team.

Christopher Deweese, a 2009 microsoft MVP Solution Architect puts in his blog:

The truth is, every developer is a little bit of an architect.  Some of us just care a little more than the next guy.

A good idea is a good idea despite who had thought of it. And at times, those might not come from the most senior person in the room. It is up to the culture of the team to empower people to own the problem together and therefore be as caring as the next guy.

  1. Ronald Widha » Blog Archive » Das Hanselman wants a piece of this! says:

    [...] topic is discussing something that is close to my heart; the role of an Architect, especially an Agile Architect. What's the difference between a senior [...]

  2. Muhammad Irfan says:

    He is the one who cares more about the long term business goals which require constant determination and patience....

  3. ronaldwidha says:

    To me it sounds like you're describing what all good developers should be.

  4. Husain Al-Badry says:

    Nice post. I do agree that every developer needs to take on a responsibility of ensuring their piece fits in well with the overall design. However, this is largely dependent on the size of the project. Agile project should always have an architect type of role in the team, that person could be a part time dev and his job would be to overlook the way dev is going on a day to day basis and provide guidance for the developers throughout the project to make sure the overall picture fits together (from business requirements down to the deployed product). Projects that design up front and don't have design involvement through the project will be almost guaranteed to deliver a different product to what was designed, technology just has too much to offer now a days!