Software Architect

There is no ‘I’ in architecture

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel

'Coz sharing is caring

97 Things Every Software Architect Should Know – 27/97

I know, there really is an ‘i’ in architecture. But it‘s not a capital ‘I’, calling attention to itself, dominating discussion. The lower-case character fits neatly within the word. Its there only because it fulfills requirements for proper spelling and pronunciation.

How does that relate to us as software architects? Our egos can be our own worst enemy. Who hasn‘t experienced architects who:

  • Think they understand the requirements better than the customers.
  • View developers as resources hired to implement their ideas.
  • Get defensive when their ideas are challenged or ignore the ideas of others.

I suspect any experienced architect has fallen into at least one of these traps at some point. I‘ve fallen into all of them and learned painful lessons from my mistakes.

Why does this happen?

  • We‘ve had success – Success and experience build self-confidence and allow us to become architects. Success leads to bigger projects. There is a fine line between self-confidence and arrogance. At some point the project is bigger than our personal ability. Arrogance sneaks in when we cross that line but don‘t know it yet.
  • People respect us – Tough design questions provide a critical safety net. Our own defensiveness, arrogance, or emphasis on our experience can result in missed design questions.
  • We‘re human – Architects pour themselves into each design. Criticism of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.

How do we avoid it?

  • Requirements don‘t lie – With correct, complete requirements, any architecture that meets them is a good one. Work closely with the customer to make sure you both understand the business value each requirement provides. You don‘t drive the architecture, the requirements do. You do your best to serve their needs.
  • Focus on the team –These are not just resources; they are your design collaborators and your safety net. People who feel unappreciated usually make a poor safety net. It‘s the teams‘ architecture, not yours alone. You provide guidance but everyone does the heavy lifting together. You need their help as much or more than they need yours.
  • Check your work – The model is not the architecture. It is only your understanding of how the architecture should work. Work with your team to identify tests that demonstrate how the project‘s architecture supports each requirement.
  • Watch yourself – Most of us fight our natural tendencies to defend our work, focus on our selfish interests, and see ourselves as the smartest person in the room. Pressure pushes these tendencies to the surface. Consider your interactions for a few minutes every day. Did you give everyone‘s ideas the respect and acknowledgement they deserved? Did you react negatively to well meaning input? Do you really understand why someone disagreed with your approach?

Removing the ‘I’ from architecture doesn‘t guarantee success. It just removes a common source of failure that‘s entirely your fault.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an engineering leader with a successful record in building, nurturing, managing, and leading a multi-disciplinary, diverse, and distributed team of engineers and managers developing and delivering solutions. Professionally, he oversees solution design-development-delivery, cloud transition, IT strategies, technical and organizational leadership, TOM, IT governance, digital transformation, Innovation, stakeholder management, management consulting, and technology vision & strategy. When he's not working, he enjoys reading about and working with new technologies, and trying to get his friends to make the move to new web trends. He has written, co-written, and published many articles in international journals, on various domains/topics including Open Source, Networks, Low-Code, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at the University level during his graduation days.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.