Relationships and Architecture

Over the last couple years, I have been working out the implications of having a new architecture practice in an organization previously without one. A key issue that continues to surface is how important relationships are to architecture. This is true particularly when previous architecture decisions require governance to enforce and inform downstream project decisions. Lately, there have been several cases where a customer of a project has desired to purchase a given product and due to the impact to the architecture of that product and the fact that it does not promote key principles, something in the project had to change. This has meant that either the nature of the project had to change – implementation to investigation, project scope had to change, or even that the project, as stated, had to be cancelled altogether. It is at this point, when relationships have played an important role, in terms of defining an approach to communicate project changes. Here are a few of the lessons that I’ve been learning about relationships when it comes to communicating project governance decisions.

 

DOs

1. DO use good stakeholder management techniques to determine who will care about certain decisions and why? By correctly identifying these people, I have saved myself time in re-explaining and re-justifying the rationale for a particular decision.
2. DO communicate early and often. Once you have identified the stakeholders and their motivations, make sure to communicate to them as early and as often as possible. I have found that perfectly sane people generally take a day or two to acclimate themselves to a change in direction, especially if it’s for reasons that they don’t completely understand. The earlier you can begin this process, the better.
3. DO include your boss in the stakeholders list. It might seem obvious and probably will depend slightly on the relationship to your boss and level of delegated authority you have, but it’s generally always a good idea to have your boss agree that a particular principle is applicable or that your suggested changes to a project are correct. Otherwise, you might find yourself discussing things with people, simply to have to back pedal when your boss gets brought in. Or, worse, if he brings himself in. This one might be more clearly stated, DO acquire or verify the authority/validity of a decision before communicating it.

 

DON’Ts

1. DON’T assume that just because someone has heard you that they agree with you. It’s easy to become so convinced that what you’re doing is correct that you don’t take time to examine body language or ask probing questions. Silence isn’t agreement. Not that you won’t have to still make the decision to change a project, but you might discover something about the user or project manager’s requirements or motivation you weren’t aware of that might influence a change.
2. DON’T communicate the decision in terms of architectural benefits. Chances are the stakeholder won’t care about “architectural integrity” so don’t forget to use contextualization and empathy to consider this stakeholder’s chief motivations, vocabulary, and communications style. Make sure to approach them on their terms and in their terms.
3. DON’T be afraid of conflict and debate. Conflict can definitely escalate to unhealthy or unhelpful levels of intensity, so managing conflict is important, but don’t avoid it. Many decisions are only internalized by both parties as they are processed through debate and rationalization. It might be necessary for things to become slightly heated before a change is viewed as valid or even understood. Don’t provoke an argument, but don’t smooth it over either. Conflict is like debt, you can defer it, but you can never avoid it.

 

These lists are not exhaustive, so I would be glad of comments to this post that share your examples. I have definitely been shocked at how important relationships are to good architecture decision and governance. Managing these relationships well, starts with the realization that people are more than a means to an end and that collective contribution toward decision making (“group think”), though painful, is more effective in the long run than simple “because I told you so” tactics. Externalizing assumptions and internalizing decisions – relationships help facilitate both of these.

Advertisement