
The topic of organizational politics is not new. The concept surfaced in 1958 and in early 1980's the topic was actively studied and analyzed. There is no definitive guidance since it's a challenging topic to study; after all this is about the behavior of people. There are many factors that shape the game of politics: individual values and ethics, organization's structure and the way of life (e.g. "cooking books"), environmental conditions (e.g. market stress), and performance reward criteria (e.g. measuring and rewarding the wrong results). What's clear from research is that there is a distinction between an actual political behavior and a perception of a political behavior. For a software architect it's important to recognize and manage both.
Design choices in software architecture are often based on experience and human factors, but architects often don't recognize this. It's natural since most software architects came from the trenches of software development where programming activities are closer to the actual implementation and hence more structured.
Some questions to consider:
- Does your organization openly recognize design constraints? E.g. organization has made a commitment to J2EE platform for solutions of type X.
- Is the effort of analyzing design alternatives, if exists, seriously considered when a design approach is selected?
- Are you aware how you personally avoid, reduce, or promote organizational politics? Not all politics are detrimental. The political game can be played to promote the goodness of software architecture design and implementation process.
Read the post here.

Comments
PowerPoint Architecture (CapGemini)
Sander Hoogendoorn
Principal Technology Officer Capgemini
HERE
You might wish to also take in Sander's blog post "Death by Landscape" in a similar veign
HERE
In the land of GRC, who is the sane person?
Norman Marks on Governance, Risk Management, and Internal Audit