Professional Scrum Master, Project Manager, IT Business Architect (JEE, Spring, ICEfaces/JSF) Author of the book "ICEfaces 1.8: Next Generation Enterprise Web Development" Rainer has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

The Mission of a Software Architect

02.20.2008
| 9655 views |
  • submit to reddit

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.

References
Published at DZone with permission of its author, Rainer Eschen. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mittal Bhiogade replied on Wed, 2008/02/20 - 5:12pm

"what matters at the end of the day is openess of mind and willingness to listen/learn to others" - would make any software developer or architect as well project successful.

Mittal

Alex(JAlexoid) ... replied on Wed, 2008/02/20 - 5:29pm

In my opinion, an architect can't lead a project technicaly if he/she commands NO respect.

And respect goes both ways... I worked with an architect that thought that he knows the "truth" and another wth the same expereinces that was forever open to critisizm. Working with one and the other was SO different.

I think that opennes and ability to listen is MOST important to the management team, the developers may be not as open.

Rainer Eschen replied on Wed, 2008/02/20 - 6:10pm in response to: Alex(JAlexoid) Panzin

[quote=jalexoid]

I think that opennes and ability to listen is MOST important to the management team, the developers may be not as open.

[/quote]

Why you limit this to the managers? I think communication should be open in both directions. A developer that isn't listening can't recognize what is important to the project. For me it would be nice if she could put herself into the architects role for a better understanding, as I do it for the developer's role.

Springsteam Blog - Next Generation Java Development

Alex(JAlexoid) ... replied on Wed, 2008/02/20 - 9:53pm in response to: Rainer Eschen

I am saying that openness for developers is not AS crucial as openness for leaders.

Leaders are rare... most people are followers. That is EXACTLY why I put developer's need to be able to listen as lower priority. Though a developer has to be open, because openness is the key to being a good team player, as being able to follow a leader. Listening is a bit another quality in my opinion....

But, hey...  We can dream of a perfect team.. Where everyone is open and a good listener...

But in reality we still need "monkey coders from India" and such...

Mittal Bhiogade replied on Wed, 2008/02/20 - 11:19pm in response to: Alex(JAlexoid) Panzin

I think openess and listening are very like packaged skill. We at least need to make an attempt to build harmonic teams rather than dream/wait for ideal/perfect team. We got to start from some where !!!!

Mittal

Rainer Eschen replied on Thu, 2008/02/21 - 12:34pm in response to: Alex(JAlexoid) Panzin

I don't really understand this separation :-) But, maybe because I need both for a communication to "lean in both directions". Even as an experienced architect I need know-how from the developers to drive the team into the right direction. To have only "followers" is not enough to me. Managing doesn't allow to have a deeper look into everything by yourself. For this I need my specialist giving useful feedback to get a best-of-breed decision for the next iteration(s).

Guillermo Schwarz replied on Fri, 2008/02/22 - 5:06pm

By definition architectural decisions are transversal to the systems and the modules within the system. (Irreversible or not, althought I agree that the best architectural decisions are reversible and therefore good architecture destroys the need for architecture, while bad architecture only increases the need for architecure).

 Therefore an architect should be able to define the architecture of several projects at once, if he is good at it.

A good architecture can be reused in several projects, otherwise it is just something particular for a problem set. If requirements change, the architecture must be thrown out the window and a new architecture should be found. That doesn't happen in practice when good architectures are found, then why an architect must be used duringt the whole duration of a project.

Simply because the architecture is so restricitive (for a reason) and developers (like Neo in the Matrix) is always trying to find new ways to do the same olf stuff. The junior developers always stumble across problems because the rookie is always making architectural decisions he shouldn't be making, the architect is rather layed back trying to control everything by predicting what every single developer can possibly think and trying to direct him into what is already proven as correct. This is possible in the Matrix because it is just a movie.

 In real life the architect must be an experieinced developer who made the same mistakes and made projects fail and like the Phoenix he was reborn from the ashes (to be burned again ;-) just kidding, to help others not to get burnt. If he succeeds or not just depends on if he saw the movie or not... I mean if he already made something simmilar or not.

Anyway, developers are so ingenious. I spend a lot of time removing unnecessary code!

Developers always think there is a limit for what can be done. This is encouraged by computer science departments telling that every program is equivalent to a Turing machine and that no program can knowingly stop (the undecidable problem, misinterpreted). P != NP and therefore all code can't be reused. Nice news for hardware manufacturers and software factories.

This is the leit motiv of the architect: to think of problems in advance, lecture developers, control them, patrol them, and then act surprised when they don't follow the rules... Solve problems once and forever. Also I like to simplify the development by using proxies, although that makes the architect less relevant. The architect makes itself irrelevant by simplying the code. Then any monkey can program. Not quite, but you get the idea.

They decide to tackle bigger projects and they need you again.

 No developer knows everything and of course no architect knows everything. Actually architects tend to forget, because they code less, both because they solve the same problems with less code and because they tackle the problems other developers fail at. It doesn't make much sense to use an architect where a coding monkey can do fine.

I mean no offense to monkeys, being a monkey veteran myself.

The utmost simplicity is what architects should strive for. To create abstractions that simplify the program to the mimimum. For example to create the dependency rules of the application and all screens, all the database schema and the business rules are dervied from it. Can you imagine something like that?

PJ Murray replied on Sat, 2008/03/08 - 3:25pm

Interesting posting .... but great links, well worth following.

Ash Mughal replied on Thu, 2012/01/26 - 2:13am

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.The term also refers to documentation of a system's "software architecture." Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects

advanced java

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.