It happens to all Enterprise Architects sooner or later. Someone doesn't agree with your architecture and they would rather implement a solution in a way that doesn't match the current technical road map. Sometimes the resulting discussions can be quite civilized and profitable for both parties. However, to make that more likely, and to prevent a disagreement from escalating beyond where it should, here are some ideas that I have found useful.
When you are first told that someone wants to deviate from your carefully thought out architecture, don't get defensive. I think this is quite natural when the objection to your ideas comes from someone more senior than you in the company and it may happen regardless. You don't need to immediately defend your work. It's best to say something like, "That's an interesting idea, let me think about it a bit" and then go somewhere else and do just that.
Likewise, back away if you feel yourself getting angry. Showing anger at someone else's ideas when they happen to conflict with your own is not going to help you.
In some organizations, an Enterprise Architect can "pull rank" and simply inform people that disagree with them that they will follow the Enterprise Architecture. Giving people orders is probably not the best way of dealing with the situation. You may get public compliance but they could be resentful and may look for a way to circumvent you at the first opportunity.
Let the people who disagree with you know that you value their input and that you are glad that they feel strongly enough about enterprise architecture to come talk to you. Set up a time (usually not right away -- the next day or later would be good if the matter is of utmost urgency) to discuss their concerns in more detail.
When the meeting starts, let them do most of the talking. You should stick to asking questions, pointing out areas of actual agreement (sometimes this works really well) and admitting to any mistakes that you might have made that actually led to the disagreement. I know the second thing is hard to do, but sometimes when one side in a disagreement admits mistakes, the other side makes concessions as well. The key thing is that you are not trying to "win" the argument. You are trying to bring the sides together.
When they are done presenting their points, don't argue with them. Thank them again for caring enough to come to you and tell them that you will get back to them as soon as you can. Then, go away and think carefully about what they said.
You need to think carefully about the degree of disagreement. Is this an issue where you need to go to the wall (i.e. the CIO/CTO) and insist on getting your way? Keep in mind that could be damaging in the long run, but it is sometimes necessary. Is there any middle ground that is reasonable? Is it possible to use some sort of objective test to decide between the alternatives? Is this an issue that should go to the Architecture Review Board? Normally, if you don't have enough support at the Architecture Review Board on the issue in question, then perhaps you should consider accommodating the request.
If you do have to oppose the request, try to refer to the organization's architecture principles when doing so. You might also want to give the person who disagrees with you a chance to address the architecture review board and make their case. You should find out if it is possible for them to do a proof of concept for their idea. The key thing is that you need to make sure that they do not suffer anything resembling humiliation as a result of disagreeing with your architecture. Many times, the person opposing you will be a valued member of the organization. Keep in mind that they may be more valued than you are :-) and treat them the way you would expect to be treated in their shoes.
No comments:
Post a Comment