(My) definition of the architect's role: "Software Architect is someone who is able to break down customers (=product owners, sponsors etc.) vision in more or less fine grained software artifacts"
I prefer the term "vision" over requirements, because most of the time requirements happen to be unstable and the customer actually unsure.
An architect should also immediately inform the customer about the impacts of his functional and non-functional requirements. Pro-active consulting in the definition phase about
the consequences of high availability, modularization, distribution, security etc. is crucial and safes real money. The architect should be especially well experienced with possible problems and side-effects.
To provide a real value to the company, the architect should not only sell his ideas to the developers, but also convince them with hard facts and be open for feedback (a single architect just cannot be smarter, than a whole
developer team). The problem here: it is very hard to convince developers with PowerPoint, Visio or plain UML-diagrams. A better idea is to verify the high level ideas with Proof Of Concepts - small applications or code snippets, and some test results (memory consumption, scalability, performance, testability). This easiest the communication a lot. Developers feedback will be a lot better, and there is no better concept explanation, as high level and clean Java, Ruby, Scala etc. code. Furthermore the PoC could evolve to a concept prototype and the could be used as a sample for a tutorial for new developers.
...my definition of developer's is: "Developer is an architect, who just don't want or is not able to deal with the translation of high level requirements into low level code, and enjoys to code more". Therefore an architect is a developer, who enjoys the translation and likes communication, meetings and everything else what is needed to extract the requirements from the customer.
An architect should be only a temporary role. Otherwise it will be harder to keep up with the technology and you will end up in an "ivory tower":
"...From the 19th century it has been used to designate a world or atmosphere where intellectuals engage in pursuits that are disconnected from the practical concerns of everyday life. As such, it usually carries pejorative connotations of a wilful disconnect from the everyday world; esoteric, over-specialized, or even useless research; and academic elitism, if not outright condescension..." [from wikipedia]
Comments:
We sometimes say something along the lines of: A non-coding architect is a scary concept/useless. Now to explain ourselves we can point to this entry :)
Couldn't agree more with this post, especially the ivory tower part. Nothing more frustrating then trying to deliver the 'architects' vision when they've been away from the technology too long.
One one client site I work at the team swaps the Architecture role around every project which seems to be a nice way of dealing with it.
That's the best definition of an archtitect / developer I ever read!
Posted by
Harald Pehl
on August 12, 2010 at 05:11 PM CEST
#
The idea that an average developer is capable of translating ideas into software doesn't survive the first contact with reality. An average developer can write a good code and solve design problems within a single software component and that's at best. At worst, a a tech lead has to define all the important parts of the algorithm, leaving "an average developer" with coding only. And then do the code reviews, to make sure it's done well.
I like your definition of the architect, though and I also agree that the position can not be permanent. In my experience, the architect nicely transition to tech lead role in the implementation phase. He does not have to follow through the whole project in that role, just to the point where the major components are fleshed out.
Posted by
Anton Goldberg
on August 12, 2010 at 09:58 PM CEST
#
Hi Anton,
I consider an average developer to be a motivated and interested one. In this case he would be able to translate the requirements into software artifacts. But some developers just don't want to do this task or are not capable to (e.g. because of lack of political skills :-)).
However: a non-political developer is less harmful for the company, than a non-technical architect. This may not be true for a project :-)
thanks for sharing your opinion!,
adam
Posted by
adam-bien.com
on August 13, 2010 at 01:14 AM CEST
#
I agree in most parts to your opinions Adam. However, I would also agree with the comments that the average developer is incapable of performing this task, due to a lack of training or a lack of a natural ability to think outside of the technical elements of a given project.
For me, and for many fellow Architects, a Software Architect, (or Solutions Architect in my case), exists to manage expectations for the customers, as well as breaking down their vision into artifacts. They are also there to represent the development team, including each individual developer, ensuring their opinions, and experiences, are protected and encouraged within a project.
The Architect should move from one developer to another, on a regular basis, identifying any concerns, and filtering out the thoughts of the developers to be used as input into the final solution architecture. This is essential, as each developer has skills and experiences that differ and can be extremely useful in the development of a system or solution. Those developers may not have the capability to translate that into a single unified architecture, or conflicts may occur between developers on which path to take during the development of an architecture, but the Architect can manage this on both a requirements and a technical front.
And I thoroughly agree that a Software / Solutions / Technical Architect should stay hands-on in the development of a solution. The Ivory Tower scenario is all too familiar, as is the scenario where an Architect's role crosses over to the Project Management role, which means the development team is no longer represented or protected. I could write much more on this subject alone, but I will spare you from a rant and stalk you on Twitter instead.
Posted by
P J Laszkowicz
on August 24, 2010 at 05:05 PM CEST
#
nice post.
Posted by
rhodmie sagum
on August 25, 2010 at 02:04 PM CEST
#
Also an architect identifies the constraints/limitations within which the SW needs to be designed. It could be memory space, time to perform, etc.
I totally agree that the SW Architect should stay hands-on with latest technologies and coding practices. Because the programming language/SDK is another factor shaping the SW architecture
We sometimes say something along the lines of: A non-coding architect is a scary concept/useless. Now to explain ourselves we can point to this entry :)
/Mattias, Developer/Architect
Posted by Mattias Bergander on August 12, 2010 at 03:41 PM CEST #
Hi Adam,
Couldn't agree more with this post, especially the ivory tower part. Nothing more frustrating then trying to deliver the 'architects' vision when they've been away from the technology too long.
One one client site I work at the team swaps the Architecture role around every project which seems to be a nice way of dealing with it.
Posted by Martijn Verburg on August 12, 2010 at 04:11 PM CEST #
That's the best definition of an archtitect / developer I ever read!
Posted by Harald Pehl on August 12, 2010 at 05:11 PM CEST #
The idea that an average developer is capable of translating ideas into software doesn't survive the first contact with reality. An average developer can write a good code and solve design problems within a single software component and that's at best. At worst, a a tech lead has to define all the important parts of the algorithm, leaving "an average developer" with coding only. And then do the code reviews, to make sure it's done well.
I like your definition of the architect, though and I also agree that the position can not be permanent. In my experience, the architect nicely transition to tech lead role in the implementation phase. He does not have to follow through the whole project in that role, just to the point where the major components are fleshed out.
Posted by Anton Goldberg on August 12, 2010 at 09:58 PM CEST #
Hi Anton,
I consider an average developer to be a motivated and interested one. In this case he would be able to translate the requirements into software artifacts. But some developers just don't want to do this task or are not capable to (e.g. because of lack of political skills :-)).
However: a non-political developer is less harmful for the company, than a non-technical architect. This may not be true for a project :-)
thanks for sharing your opinion!,
adam
Posted by adam-bien.com on August 13, 2010 at 01:14 AM CEST #
I agree in most parts to your opinions Adam. However, I would also agree with the comments that the average developer is incapable of performing this task, due to a lack of training or a lack of a natural ability to think outside of the technical elements of a given project.
For me, and for many fellow Architects, a Software Architect, (or Solutions Architect in my case), exists to manage expectations for the customers, as well as breaking down their vision into artifacts. They are also there to represent the development team, including each individual developer, ensuring their opinions, and experiences, are protected and encouraged within a project.
The Architect should move from one developer to another, on a regular basis, identifying any concerns, and filtering out the thoughts of the developers to be used as input into the final solution architecture. This is essential, as each developer has skills and experiences that differ and can be extremely useful in the development of a system or solution. Those developers may not have the capability to translate that into a single unified architecture, or conflicts may occur between developers on which path to take during the development of an architecture, but the Architect can manage this on both a requirements and a technical front.
And I thoroughly agree that a Software / Solutions / Technical Architect should stay hands-on in the development of a solution. The Ivory Tower scenario is all too familiar, as is the scenario where an Architect's role crosses over to the Project Management role, which means the development team is no longer represented or protected. I could write much more on this subject alone, but I will spare you from a rant and stalk you on Twitter instead.
Posted by P J Laszkowicz on August 24, 2010 at 05:05 PM CEST #
nice post.
Posted by rhodmie sagum on August 25, 2010 at 02:04 PM CEST #
Also an architect identifies the constraints/limitations within which the SW needs to be designed. It could be memory space, time to perform, etc.
I totally agree that the SW Architect should stay hands-on with latest technologies and coding practices. Because the programming language/SDK is another factor shaping the SW architecture
Posted by Sugumar Govindarajan on October 08, 2011 at 12:01 AM CEST #