The Mission of a Software Architect

Recently, I read Steven Devijver's The YAGNI Argument (You Ain't Gonna Need It) and found a link to one of Martin Fowler's IEEE articles Who needs an Architect? in it. What I didn't know was that this article was 5 years old and was impressed by how up to date the statements were. It led me to start thinking: What is the Mission of a Software Architect?

Maybe with the years of experience the view changes so much that a deeper understanding of the mastermind experiences becomes possible. Some insights:

• Architecture is communication
• Architecture is the common sense in a team about design aspects
• Although, there's no theoretical limit to get a better design result, architects are their own enemies

I have tried to understand the anatomy of project teams since my study. I've read several books from Tom DeMarco, Daniel Goleman and others. Psychology is an important part of this understanding. If you don't have empathy, a keen sense for a certain situation or what makes the work comfortable for team members, the project results are predictably less efficient.

One of the most important credos for me is based on a thesis by Reinhard K. Sprenger (I found no English pendant, sorry) from his Mythos Motivation: every new team member starts with 100% motivation and leaves the team with 50% or less. You can demotivate your team members, but there's no real chance to motivate them.

Demotivation is caused e.g. by

• disrespect
• distrust ("Trust is good, control is better" phenomenon)
• necessity
  • to act against once own disposition or experiences
  • to abandon quality
• quality of working environment

For me, disrespect is the worst killer of team communication. So, I have to understand where the borders of respect lie that I'm not allowed to violate. Psychology describes the emotional patterns behind this for our mind (the rational), but the effective sensor for violations is our subconscious mind (the emotional).

Today's developers are highly-specialized and want to work independently. Such creative heads can't be controlled - if we assume for a moment that such a behavior would be useful at all. You can tell them what to do, but not how to do it. So, a successful software architect or project manager will be a moderator or mediator based on a management by objectives.

Communication is an important point here. The software architect's focus is the big picture. But, we can't expect that every team member knows all contexts. So, we have to assist developers when creating the architecture's building blocks. Interfaces, reuse, etc. of such artifacts have to be discussed to get the developer into the right direction.

Team members resist to act against their experiences. If you already know how to do it to get a good result, why change? It is possible that the team finds a better way to do it and you need extra discussions to change one's mind. But, it is not rare to find that a manager with less experience thinks she knows better. My experience tells me that this doesn't work. Never tell a pro how a pro has to do it. So, I always assume that I'm not the pro in the game as long as I can prove that my suggestions are better. Most interesting with this is, that even if I have a better approach, a lot of those discussions show me that there are new aspects in it I've to consider the next time.

Did you ever observe bad managed teams? For me a fantastic phenomenon: you will find at least one person that doesn't allow that the team will strand. There's something in every team member that resists to fail even in the worst environments. If the frustration hasn't reached the level of intolerability this helps to keep dead horses ridden for a long time. For me, it's part of the learning process to develop a sense for the right moment to give up ideas, concepts, architectures, designs, frameworks, implementations, etc.

The enthusiasm to resist to fail is something I also recognize for quality of work. For me this correlates to motivation. The will to produce project results of good quality is 100% at the beginning of a project. Project adversities reduce this. You can argue that every project has it's restrictions. Sure. But, a lot of them are results of long-term inabilities.

The quality of the working environment is a concrete result of such inabilities. If a manager has no focus on this she can't expect efficiency of labor.

A study (German PDF), presented in December 2007 by the German department of labor, based on a representative survey with 37.000 people in 314 companies from 2006, tells us that there's a proven correlation between business culture and profitability. This can influence up to 31% of the financial success of a company. Successful companies have a strong focus on this.

For me this study tells me that a project can loose up to 31% efficiency because of what I discussed above.