Sunday, March 15, 2009

The role of organizational politics in Software Engineering and Software Architecture design

This is a very important topic I've been examining for a number of years. While my Ph.D. work on "the cost of organizational politics on software engineering" is many years away it's important to raise the awareness of this subject matter.

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.

It's good to admit that politics play a role in the design process. Actually it's healthy to admit so as it shows maturity of an organization or a team / person.

Remember that you as an architect make conscious and unconscious decisions in your day to day activities that may be perceived by others as political decisions. To protect yourself from unintentional consequences be sure that your personal priorities do not become your team's agenda, else the team chemistry is going to change and you're not going to like the result.

Constantin K.
Firebrand Architect®

No comments:

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...