Before joining this project on a full time basis I was invited to spend time evaluating the existing architecture and make recommendations before the development phase would commence. During the architecture review & analysis process I have identified a number of risks, in light of project constraints, including application’s laborious authentication and authorization requirements. To address this risk I proposed integration of a well known .NET compatible COTS software access control and authentication component.
Luckily the organization’s Enterprise Architecture (EA) has already authorized utilization of such component, and even already possessed an enterprise license for its use.
A large (eighteen person) meeting was called to discuss future placement of the solution in development, test, and production environments. Heads of various environments as well as select technical staff were present. Utilization of various EA resources, including the access control component, was on the agenda.
During the meeting the technical lead representing the component stated that only the authentication part of the component is usable within the enterprise. Naturally, I questioned why the wealth of authorization functionality is not available for the project’s use. The technical lead didn’t have a good answer and responded by saying that nobody is using it. I passionately pushed further explaining how much this project would benefit from such functionality, I went through the key features, and even volunteered to assist the tech lead with configuring the component to make the authorization functionality work.
After the meeting the product’s chief architect and I reflected on the stubbornness of the technical lead to even consider looking into utilization of the access control functionality of the component. We both felt that the technical lead took the stance of “if it’s not broken don’t touch it” and was afraid to look into our request.
Soon after the meeting the program manager requested that this firebrand architect not be taken to other “high level” meetings. It turns out that what I thought was a passionate appeal to utilize desired functionality was perceived as arrogance.
Reflecting back on this event, quite some time later, I see the obvious mistake. It’s not that the action of the appeal for desired functionality that was wrong; it’s the presentation and timing that was off. After receiving a mediocre answer from the technical lead I should have documented my case and presented it offline to the program manager who was also present at the meeting. Since this was my first meeting with these high level representatives I had no sense of the existing political situation and pre-existing issues. A smarter move would have been to listen, observe, think, and then speak – offline. This was not the first time I participated in such a high visibility meeting, but this was the first time I ran into a group of highly sensitive individuals.
Three months later, after I have regained full confidence of the program manager, I was placed into a leadership role that required me to participate in similar high visibility meetings.
The moral of the story is to listen, observe, think, and understand the environment and the political situation first; and only then to speak.
- Firebrand Architect on duty: CK