Friday, April 22, 2011

ArchitecT contains the T of Team

As a consultant I’m mostly assigned on jobs in the architect role. So I’m actually talking against my own function here. Nevertheless I want to share my opinion.

During an intake I had a discussion with the interviewer(never a good idea) about the role of an architect. In their organisation an (application) architect only creates the software architecture and then throws his solution over the wall to the development team. What’s even worse is that the original architect takes only a cursory glimpse at the progress from time to time. This made me wonder how they knew that their software architecture was working as expected. Apparently that wasn’t important, it is up to the development team to implement the architecture ‘correctly’.

A successful software project requires the initial vision to be understood, communicated and potentially evolved throughout the entirety of the software development lifecycle. For this reason alone, it doesn't make sense for one person to create that vision and for another team to (try to) deliver it. One of the consequences is that you see a lot of developers struggling and cursing the architecture because they’ve never been told what the vision behind the architecture is.

I tend to approach this problem in a completely different fashion. With the idea of  self-organising teams, I involve the whole team in (almost) all design decisions. By doing this they understand and support the vision, we get a shared ownership of the architecture and a much better result in the end.  

My role extends from putting together a high-level design that is sensitive to the context and environmental factors at the beginning of a project to a continuously adjustment and steering of the team vision and architecture.

No comments: