Microsoft's Architecture MVP Changes

In late February of 2008 Microsoft dissolved the Microsoft Architecture MVP award as part of realignment of the MVP program to be more product oriented. Dissolved is a wrong word … so read on. This came as a surprise to many award recipients - including myself – who lost a “nice to have” title. This development, however, had a very positive impact on the Architecture MVP community, because it forced the architects ask themselves some hard questions about their role in the community and the role Microsoft plays in the software architecture discipline.

This post features some highlights from the ferociously bubbling listserv.

At first there was confusion. Participants understood the reasoning behind moving towards a product oriented approach, but they couldn’t fathom the disappearance of the architecture competency. Then there was anger – well summarized by one of the participants: “I believe the shutdown of the MVP Architect program is just one more piece of evidence that … Microsoft does not appreciate the role of the architect in driving large buy decisions.”

Then a word of wisdom came from Simon Guest. In order for the MVP program to grow the structure has to change. MVPs will be aligned to a product, but will be able to select a discipline such as architecture. Simon then called for an open forum at the MVP summit in Redmond on April 15^th.

Identity crisis started to emerge – some participants, including Martin Fowler, voiced their reserved opinions about the value of the MVP award. Valid questions arose – why do architects communicate so little with each other? What role do architects play in organizations? What do they do for Microsoft? The consensus was clear – although there is a clear need for robust architecture communities the MVP award infrastructure didn’t make individual architects feel part of a single unit.

Finally discussion merged onto taking proactive steps to define the scope and purpose of the group. Familiar questions arose: how do we define different types of architects? What are the definitions of architecture and architect? Should we just take some definitions from IASA? Microsoft has established a work space where the discussion of these various topics will commence.

There are no clear answers, but there are good questions – Microsoft is moving in the right direction albeit at its own pace.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Listen. Observe. Think. Speak. When passion limits your potential.

This post is a reflection on the past behavior that landed this firebrand architect into a counterproductive situation and, temporally, put him in a penalty box. Let this be a warning to others.

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