Two weeks ago I joined the board that reviews candidates for certification as Microsoft Certified Architects: Infrastructure and Microsoft Certified Architects: Solutions.

I also attended a very insightful talk about the MCA Experience that was delivered by George Cerbone from Microsoft Learning.

In compiling my experiences on the board both in reviewing and interviewing candidates and deliberating their certification outcomes, the experiences I gained from achieving the certification myself and the lessons learned from George’s presentation, I thought it would be wise and useful to publish some additional material regarding certification from architects wishing to attain the certification.

As a primer, I suggest you read me previous post which provides some insight into the actual process. This post is located on my old blog at MCA certification process and details my personal experiences at being run through the process and achieving certification. It contains many insights regarding the process and should be considered to be additional content to be absorbed over an above this post.


In preparing for the review it is critical you realize your time and the board’s time is valuable. The board does not get paid for their work, and typically take time out of their own working day to certify the candidates. It’s a labour of love, and we’d really like to pass you.

So really expend the energy you need to to choose the best possible case study that demonstrates all of the competencies required of you as well as the architecture skills you’re expected to demonstrate. The seven competencies you will be rated on are extremely important, namely:

  1. Leadership,
  2. Communication,
  3. Organizational dynamics,
  4. Strategy,
  5. Process and tactics,
  6. Technology breadth ,
  7. Technology depth.

Many candidates fall down because they’re less focused on those listed in 1-5 and almost seem to make the assumption that if they’re successful in 6 and 7, that the rest will come naturally. This is patently not true. It is critical you are able to demonstrate leadership in the teams you work in (either positional leadership e.g. team lead or as an influencer e.g. architect <—> CIO and CEO conversations), that you are able to communicate effectively in articulating your approach, solutions and strategy to a wide audience, that you are able to deal with conflict and that you take a strategic (rather than break/fix or tactical) approach in the work that you do. You will need to be able to demonstrate these skills.

The best place, I feel, that you can demonstrate these is in your case study. If you’ve done it before in the real world, it is very likely you’ll be comfortable in dealing with difficult situations in the QA. Don’t ignore them and don’t let them derail you.

One of the most obvious areas of communication that people seem to ignore are the frameworks and constructs required of an architect. It is pointless having ideas in ones head if they can’t be translated into a format that other architects or engineers can understand. Typical examples of these are people missing the ability to demonstrate skills in UML or any other format for describing process and flow. It is incumbent on the candidate to demonstrate that they have the means to adequately describe the architectural components in a format that can be easily understood by other architects and members of a solution delivery team. In failing to do so the candidate is actually demonstrating that they have no methodology for gathering and articulating these details. Put something in your case study that will provide actual evidence that you do this and that you know what you’re doing. Under no circumstances include material of this nature in your case study unless you were intimately involved in the creation of the material.

Remember, the most important part of your case study, other than it being a project or solution of enterprise scale, technically relevant (no 1957 case study of supercomputing in Area 51) is evidence, evidence, evidence and something that benefited the business not just IT! Don’t pick the coolest project your were involved in, pick the case study which demonstrates responsibilities and accountabilities you carried and architecture strategies and deliverables you created.

At a basic level, you must articulate the business problem you were addressing, the business requirements that were defined, how success was measured, the organizational dynamics you encountered how you derived and refined an architecture and how you drove that architecture into the business. Naturally each of these will require some artifact you created as a proof point of the architecture work you have performed. It is strongly recommended that you follow the template provided to ensure you’ve covered all areas appropriately. It is there to make your life simpler.

In your area of breadth knowledge, take the time to understand the other solutions that are out there. The board does not expect you to know each and every competing solution, but they would like to see evidence that you can compare and evaluate solutions for fit in a number of scenarios. Try to remember that even though this is a Microsoft Certified Architect certification it is actually technology agnostic. People from Microsoft’s competitors that are not nearly depth experts on Microsoft technologies have been certified and some sit on the board. You might even encounter one.

Lastly, reading up about a subject is unlikely to see you through the process. You’re far more likely to succeed with the few things you actually know intimately than a general awareness of stuff in general.

As a general note, proof read your submission a million times if necessary. Before each board review the material is well read by the board members. The material submitted helps the board members form an initial impression of the individual as well as formulate the questions they may ask. Spelling mistakes, grammatical errors, incomplete paragraphs and bad structure may all lead the board members to wonder what type of material is being produced in your own organizations and customers.

You don’t know what you don’t know:

After you’ve completed your documentation you’re ready for the board. In my experiences so far the presentations have gone reasonably well. It’s the question and answer sessions that do not go so well if the candidate is not suitably prepared! See above!

Typically when things have gone wrong it’s because the candidate has misrepresented the scope of their work and is in essence trying to paint a picture of their involvement in the project that is far greater than their actual involvement was.

Be aware that it is extremely likely that the board will consist of highly competent subject matter experts that will easily be able to assess your level of competence in your claimed depth, breadth and vertical areas of knowledge. They will not ask unreasonable questions, but they are likely to ask you to draw diagrams of your architecture, run through how you got to the architecture you did, discuss the critical conversations you had with various stakeholders in the business and IT departments and will check your knowledge in your breadth and depth technology areas. Many of the members of the board will have performed those duties numerous times and also have interviewed prospective staff for employment at their own organizations. The breadth expertise on the board will extend beyond Microsoft’s technologies too. For example, my breadth expertise extends to many areas, but as an example extends across Active Directory, Novell eDirectory, OpenLDAP, IBM Directory Server and many Identity and Access Management solutions. People who claim directories and security as breadth areas are pretty likely to be well tested by me, despite my being an employee at Microsoft!

So, speak about what you know. Be competent in the areas expected of you and… be very aware of falling into a trap of claiming depth knowledge in a subject area where you only have breadth knowledge. It is always better to say, “I don’t know,” than to fall into a pattern of wasting the time you have at your disposal to prove you’re architect material.

Before you came into the room you were already under pressure from the mind games you had been playing with yourself. You will come into the review with a great deal of uncertainty and one of the most common outcomes is that you will try to prove you know everything! Rather recognize the pressure you’re under, accept that it’s there and focus on what needs to be done only. It’s normal to feel that way, but you need to consider that in conversations at your company and with customers you will also be under pressure and the board needs to ensure that pressure will not make your judgement questionable. The questions will be fair and they are not designed to trick you. All they will be doing is probing your expertise. It is never a good idea to get too defensive or becoming aggressive. These can often be perceived as arrogance. The board knows very well the pressures that you’re experiencing. We’re you’re peer industry architects and have been through the same process ourselves.

A fantastic hint at what is to come can be found in the InfoPath/XML self-assessment form you complete as part of the application process. Take some lessons from that. Figure out where you can improve and even consider delaying the board review until such time as you think you have covered the areas you consider important.

Also, realize the board is also human and can make mistakes. You can never be sure what type of question they may ask, but if you think the approach they’re taking in solving a breadth or depth problem is less suitable to one you think may work then be prepared to say so convincingly i.e. evidence, expected outcomes and benefits. In my own review I did not like a scalability question that was thrown at me, so I asked clarifying questions in order to understand what was trying to be achieved and then gave the board an alternate solution I felt was more appropriate. I’m not quite sure how they took it, but they did pass me! I’ll bet they found my approach fascinating and that they learned from it.

Don’t do it because it sounds cool:

Sure, being an MCA sounds like an important certification. It is; but it’s important for a specific type of skill, it is not the be all and end all of certification! As an example Microsoft also provide Microsoft Certified Master (MCM) certifications for specific technology domains. It is essentially the equivalent to an MCA. Whereas an MCA is a certification for the architecture domain of knowledge, the MCM certification for Messaging encompasses the messaging knowledge domain, and MCM: Messaging candidates will be expected to be able to architect messaging solutions based on Microsoft products (email, scheduling, unified communications technologies) and have depth technical knowledge of the products. The MCM is just as hard to attain and is meant for people who have the career sights set on being depth technology experts.

Pick the certification that suits your skills and career goals. Both the MCA and MCM certifications are advanced level certifications that require deep skill and years of experience in their knowledge domains. It is very rare someone would be competent at both because, at the risk of sounding absurd, the types of people that chase them are typically different characters all together.

Lastly, don’t assume because your title is Architect in your current organization that you’re a natural fit for the certification. The certification is an industry benchmark, not an intra-company grade scale or peer benchmark. Check the competencies, check what work you’ve done and be sure that those map to what is expected of you.

This post is governed under the site terms of use and by the Creative Commons Attribution-NonCommercial-NoDerivs license. Original work of Natasha Anne Mocke.You may republish this work as long as explicit credit is given to the author.