If you are like me, when you get your results it is binary - you either passed or failed.  I'm going to cover both sides here.

You Passed

Congratulations!  I know it was a long and arduous process.  Now what?  Look at your feedback and take it to heart.  If you did this as a way to further develop your skills, you should find ways to incorporate the feedback into your career development. Give feedback to Microsoft about the process.  Get your MCA logo and put it on your business card, blog, and anywhere else you can use it under the programs terms of use.  Find out who the other MCA's are and find ways to network with them.  Find people that are interested in the program and mentor them.  Get active on the MCA mail list.

The biggest thing is to sign up and do a board where you can sit on the other side.  I find that doing a board is one of the best mental exercises I have ever done in my life - it is challenging to come up with the right questions that demonstrate that someone meets or doesn't meet a competency - particularly in the soft skills.  I always learn something new from each of the other board members and also from the candidates. 

You Didn't Pass

Ok, you didn't pass.  It is very disheartening and there are a number of different thoughts running through your head about the equity of the process and the fairness of the board.  I'd encourage you to stop for a minute and really take a hard look at the feedback.  The board spent a significant amount of time and thought putting together your feedback and it will tell you the areas where you didn't provide sufficient evidence to pass the certification.  Remember, this is not a numerical formula that can be calculated - the board is making a justification based on the guidelines of the strawman.  The feedback is very valuable and will tell you where you didn't provide evidence of meeting the competencies.  Remember, this is one way of measuring an architect - it doesn't make you any less successful in your career - it just tells you how you aligned with this particular measure of an architect.  You might even find some areas that you want to work on from a personal or career standpoint.  Once you have reviewed your results and taken some time to reflect, contact the program and provide feedback to Microsoft Learning.  You might also consider going through the board again in the future - discuss with your contact in the MCA program if that is a viable option for you.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

I can think of no more humbling experience than going in front of the board.  I have been on both sides and it is an emotional experience.  It is two straight hours of grilling, going back and forth, and even a little adversarial in questioning techniques at times.  The best advice I can give is "Don't take it personally and be honest about your limitations".  Having sat on a few boards you come to realize that this is a difficult thing to do from a certification standpoint.  Every MCA I know wants there to be more certified architects and wants everyone that comes in front of a board to pass.  But they understand that they have a duty to ensure the bar for the certification remains consistent and that every candidate meets the guidelines of the competencies - and they only have two hours to accomplish that goal.

Here is the process from a board member's perspective:

• Review documentation for up to 12 candidates and try to make enough notes to ensure that in the future I can recall some things that I want to find out more about during the board review
• Right before the specific board, I review the documentation for the candidate and my notes one more time to refresh my memory.  I have about 5-10 minutes to do this.
• Find out from the moderator what the specific technology depth areas are for the candidate
• Discuss and settle on a sequence for each of the board members to ask questions - we do it one at a time so we don't question over each other and we each have 10 minutes (which we can give to others on the board if we want)
• On my Windows tablet I have a document that has all of the competencies and every bullet underneath each of the competencies (we often refer to this as the strawman)
• During the presentation I am scanning the competencies (and bullets) to mark down notes and areas covered by the candidate.  I am also noting the presentation flow, style, and timing to evaluate the communication skills of the candidate.
• After the presentation I listen carefully to the questions from the other board members and the answers from the candidate - I will continually go back to the strawman and mark down notes and whether the candidate meets or did not meet a certain item within a competency. 
• When it is my turn to ask questions, I try to ask questions within a small range of competencies to try and get evidence of meet or doesn't meet for each item within those competencies.
• After the first round of questions, we break and the board discusses what parts of the strawman have not been covered yet or if the board is showing does not meet.  Based on the candidate and the board's specific expertise, we determine who will ask about specific items. Remember, we are trying to make sure that we cover every item on the strawman - we are looking for evidence for every sub-bullet for each of the competencies.
• We go through the second round of questioning and I continue to focus on filling out the strawman with meets/does not meet and a note for each, asking my questions when it is my turn. 
• After the candidate gives their closing remarks we go to board deliberations.
  • This begins with everyone on the board giving a pass/don't pass vote
  • We then go through every item on the strawman and give a meets/does not meet at the detail level and then at the competency level
  • As we do the competency level meets/does not meet we provide feedback at the competency level
  • Then we do an overall pass/don't pass vote - 3 out of 4 people need to pass the candidate for an overall pass
  • Finally, we do overall feedback

You will notice that I mentioned the strawman multiple times above.  The strawman is the guidance for meeting the certification and helps keep the bar consistent from candidate to candidate.  The strawman does not provide a numerical formula that rolls up though - it becomes a judgment call based on looking at the overall meeting of the strawman.  The areas where I have seen someone pass everything but one competency and still not pass the overall certification are the strategy competency and the technical depth/breadth competencies.  For example, I personally have a hard time passing a candidate who cannot link the strategy of the business with the architecture even if they do well in all of the other areas.

As you can see above there is a lot of information being gathered during the board review - roughly a two hour period of time.  Here are some things you can do to help yourself out during the board review:

• Make sure your presentation is tight and under 30 minutes.  You will be cut off exactly at 30 minutes.  Remember that the presentation is the only time you control the board - make the best of it.
• Make sure you present your project in light of the competencies.  I wouldn't be blatant, I would tell a story, but make sure that you are providing evidence of as many of the competencies in your presentation.
• Be passionate during your presentation - you are selling you and your abilities.
• Make sure you differentiate "we" v. "I" during the board review.  Be humble, but communicate what specifically you did.  Don't represent other's work as your own.
• Listen to the questions being asked, clarify and understand what is being asked, and answer what was asked.  The board is looking for evidence and asking you specific questions to gather this evidence.  When you don't answer a question because you didn't understand it or because you are evading it, you waste time and the board may not have the opportunity to ask questions that cover the entire strawman.
• Don't be afraid to say "I don't know" or "I'm not 100% sure, but I believe it would...".  You will not be able fool the board on your knowledge - but if you are honest and provide an answer that shows you can make a very educated guess based on logic and understanding it helps out tremendously. 
• Be prepared for rapid fire questioning - you most likely will be cutoff by the board during a response if they board member feels they have the answer they need (they are also mindful of time and want to get through every item on the strawman).  I have seen candidates get flustered by this, just expect it.  If there is an important point where you feel you were cut off and want to provide it, ask the board member if you can finish.  Think of the board as an important customer that is a little confrontational - you would expect to get beat up a little but still be respectful and get your point across.
• Be prepared for role play in different scenarios.
• Expect this to be stressful - every person that I know has felt that they did not pass when they finished (even those that have done exceptional).  It is emotional and you will likely replay many of the questions in your mind afterwards.  You will think of a bunch of ways to answer questions differently. After you are done, you can't worry about it anymore.
• You will probably think that the board members are not very nice by the time you are done.  It isn't meant to be that way, but the board is focused on trying to gather evidence.  As I mentioned above, the board is very interested in passing as many people as they can - the certification will not have the notoriety until there is some type of critical mass.  They aren't trying to create an adversarial environment and it isn't purposeful, but I can't think of a way to go through the process without the board asking the tough questions and doing a lot of context switching.  As a candidate, it feels personal, but as I mentioned above: "Don't take it personally".

Again, as you go through board review you will be stressed and you will be asked questions to the point of exhaustion.  It isn't on purpose, but a byproduct of the process.  I'd rather you were prepared for it so it was not a shock.  Getting through the process and passing is a great feeling - it is a tremendous sense of accomplishment.  I personally think it would be worth the pain.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

Architect is an overloaded term.  While the efforts of the MCA program, the work done by several organizations (including the Open Group, IASA, and IEEE) have helped identify the skills needed and process used, there is no single taxonomy describing the levels and types of IT architects.  Nearly every organization has their own definition of architect and what it means in one company will most likely differ from another - if fact there may be differences within a single company or even a department or on a single project.  Some of the titles I have seen have included Chief Architect, Enterprise Architect, Solutions Architect, Infrastructure Architect, Software Architect, Application Architect, and [Insert Product or Technology Here] Architect.  Figuring out how to certify and standardize the terminology is very difficult, but Microsoft came up with a definition when it introduced the Microsoft Certified Architect.  There are basically three incarnations of this certification: Solutions, Infrastructure, and a product specific ones for Exchange SQL Server, and the Windows Platform.  I am going to focus on the Solutions Architect competencies.

Below are each of the competencies and the exact verbiage from the Microsoft Learning web site.  As you look through the competencies, you should think about evidence that you can provide that establishes that you meet the competency.

Leadership

Official Statement

Candidates demonstrate that they can develop partnerships with stakeholders both inside and outside the organization on their projects, that they can mentor others, that they develop and form strong teams, and that they achieve successful results.

• Ask thought-provoking questions that result in actionable technological patterns or solutions
• Actively mentor others
• Provide thought leadership by enabling others to see things from a different and better perspective
• Influence decision makers
• Champion structure, process, best practices, and standards
• Promote the capture and reuse of intellectual capital
• Effectively build individual partnerships and organizational networks

My Comments

I look at leadership as the ability to influence and grow people within the scope of a project.  The tough thing is that candidates have a variety of roles, experiences, and styles as it pertains to leadership.  This makes leadership a difficult competency to evaluate as part of the board review.  A few points to think about when providing evidence of your leadership:

• What roles have you taken on during your projects?  Do you have a managerial relationship with the team (I look at whether you write evaluations for team members as an indicator) or are you in a matrix relationship where you work with the team, but as another team member with architectural responsibilities?  Be clear on your role and how that drives your actions that influence the overall project team.  Either role is ok, but the board will probably ask you different types of questions based on your role. 
• How do you develop the skills of those around you? 
• Do you have any situations that you can discuss around difficult members of the team or those that had differences of opinion on the process, standards, or technology?  How did you handle it?
• Where do you usually become engaged in a project?  What examples do you have of influencing the strategic direction of the project?
• What project management tasks do you take on?
• Based on the cultural environments you work in, how do you display leadership qualities?

Communication

Official Statement

Candidates demonstrate that they maintain well-written and accurate project documentation, and that they can present information about a technical subject in a concise and measured manner. Candidates are able to influence others, they manage conflict effectively, and they customize their communication to the needs of the target audience.

• Effective listener and astute observer
• Communicate effectively and persuasively to different audiences (for example, executive or technical)
• Effectively mediate and manage conflict
• Document designs and specifications that follow company practices
• Communicate needs as well as deployment and operations standards to infrastructure architects
• Effectively facilitate meetings
• Possess good presentation skills

My Comments

Communication is an area where your evidence will most likely show up in the documentation, your presentation, and your interaction with the board.  I believe that the best thing you can do in front of the board is listen to their questions, make sure you understand what is being asked, and answer what is being asked.  I am amazed at the number of people that come in front of a board review and don't listen to the actual question being asked to them - they don't answer the question or answer a slightly different question.  The board is asking very specific questions, many of them open ended questions.  Make sure you answer what is being asked.  This doesn't mean that you should always provide short, quick responses.  You need to listen to what the board member is driving towards and answer appropriately.  It is ok to clarify, bad form to cut someone off during their question.

Other areas to look for evidence in demonstrating this competency include:

• Who in the organization do you communicate with during a project and how often?
• What are your documentation standards - how do you know you have done the right amount of documentation?
• What is your process for turning a solution over to the infrastructure folks?

Organizational Dynamics

Official Statement

Candidates demonstrate that they can recognize the key stakeholders on a project and that they can work with those stakeholders to drive a project to a successful conclusion. Candidates recognize the political landscape within an organization that can influence a project, and they can influence organizational politics for the success of their projects in turn.

• Understand organizational structures, relationships, and influencers
• Adeptly maneuver through politically charged organizational situations
• Effectively build organizational partnerships and networks
• Build relationships with other architects and project stakeholders
• Possess an awareness of the internal legal organization and ensure that legal guidelines are met
• Exhibit comfort with conflict and thrive in situations that require negotiation and compromise

My Comments

I view organizational dynamics as very similar to leadership but directed outside of your project and project team.  Every senior level architect has to deal with the "internal politics" of an organization and understand how to maneuver to ensure the business is getting the appropriate solution.  This means balancing the needs of multiple stakeholders and being able to drive to consensus.  To develop evidence of this competency, I would look in the following areas:

• Where do you usually become involved in the project?  During the idea formation, once the project has been approved, or once the team has been assembled?  How do you influence the business aspects of the project based on entering a project at different points?
• Are you working with the business stakeholders?  How?
• Do you have any situations where business stakeholders had differing opinions that you had to mediate?  How did you handle it?
• What are your relationships outside of the technology team?
• What legal regulations have influenced your project?  What were the tradeoffs?
• Based on the cultural environment, how do you have to modify your approach to managing situations?

One story here - I was talking to someone once who was interested in the certification and I asked him how he gathered information from the business stakeholders.  He said he didn't do it (he let the business analysts take care of it) because he didn't like the visibility with the "higher ups".  He wouldn't pass this competency.

Strategy

Official Statement 

Candidates apply their knowledge of technology to further organizational goals within their vertical industry. They understand the principles of project management and interact with project managers to complete projects successfully. Additionally, candidates understand the economic dimension of projects and how costs influence the available choices for technology.

• Explain the business strategy of their own organization
• Use enterprise frameworks (for example, the Zachman Framework for Enterprise Architecture or The Open Group Architecture Framework [TOGAF]) to map the business strategy of the organization to a solution architecture
• Demonstrate knowledge of industry-specific trends with respect to architecture
• Balance the needs of users, management, operations, support, finance, and technology with the strategic needs of the business, including business benefits and vendor pricing implications
• Demonstrate an understanding of future trends in technology and how they impact the current and future state of your solution
• Describe how you applied knowledge of industry regulations (for example, HIPAA, Basel II, Sarbanes-Oxley, or HL7) to create your solution
• Understand how operational frameworks (for example, Control Objectives for Information and related Technology [COBIT], IT Infrastructure Library [ITIL], or ITSM) impact your solution
• Understand how techniques for achieving operational excellence (for example, Lean Six Sigma, Total Quality Management [TQM], or Capability Maturity Model [CMM]) impact your solution

My Comments

Strategy is the one competency where there is a big difference between a senior developer and a solutions architect.  I look at strategy as two major components: 1) Understanding and driving technology based on business decisions and 2) Monitoring and understanding what is happening in technology that will drive changes to your architecture. 

Let's look at the first component of strategy - business strategy drives architecture.  In my mind every project has a reason for being that begins with the business justification.  Because every project consumes resources including people, money, and opportunity cost, it is important to understand the business justification for the project.  I personally like to understand the project return on investment.  It can be a very simple equation of understanding the true costs of the project and the expected benefits in financial terms to the business.  I am amazed when I talk to architects and they don't know what the financial upside for the business will be for a successful project.  If you don't know the parameters of success, how can you drive the appropriate architecture?  I also understand that there are projects out there where financial upside isn't the reason a project is occurring (compliance projects are a great example), but understanding the success criteria from a business perspective is a very important part of understanding the strategy.  Furthermore, if you work in a specific industry, you should be able to discuss the industry specific trends and regulations that will drive the technology over time.

The second part of strategy is an awareness of what is happening from a technology perspective in the industry so it can be incorporated into your solutions when appropriate.  This includes the ability to look at a technology and say "that's pretty cool" and being apply to say "that will solve problem x for us".  I recall once asking an architect what new advance in technology he was following and most excited him.  He responded "Aspect Oriented Programming".  I asked him what that will do to help out his business and he couldn't come up with a single thing.  That told me that he didn't link business and technology in a strategic fashion.

The third part here (and in my mind not as critical as the first two) is knowing regulations, frameworks, and continuous improvement mechanisms.  I tend to break it down into the following:

• You should be nearly an expert on any regulations that impact your solutions.
• You should have a decent understanding of operational frameworks such as ITIL. You don't have to be an expert, but should be conversational with it and understand the major components of it from a support standpoint.
• You should know enough about enterprise architecture frameworks to discuss them, but you may not have implemented them or used them directly.  You should understand their value and how what you do fits into an enterprise architecture.
• I believe that the continuous improvement techniques will be very dependent on your experience and industry - although most architects I have worked with have had some SEI/CMM experiences in their past and understand the value.

Process and Tactics

Official Statement

Candidates demonstrate that they can gather and refine project requirements from both a technical and a business perspective. They design, create, maintain, and verify models of the deployed infrastructure. They also create effective project artifacts. They exhibit the ability to refine project goals and the tactics that are necessary to achieve those goals as the project develops.

• Use methodologies and/or frameworks to provide predictability to IT and ensure repeatable success on IT projects
• Gather and analyze both technical and business requirements
• Envision and create a solution that meets requirements and can be implemented using modeling techniques and mapping their points of integration
• Prove the feasibility of a design (for example, POC, pilots, or prototypes)
• Use capacity planning techniques to ensure scalable designs
• Create the design artifacts that are required to deliver and to maintain the solution
• Understand the impact of internal policies (for example, service level agreements [SLAs])
• Guide a solution through to completion and audit compliance with specifications and the overall intent of the architecture
• Review the ongoing implementation for opportunities for improvement and refine the model as requirements change, implementation choices evolve, and so on
• Contribute to technical project management

My Comments

I think of process and tactics as the ability to get a project done successfully in a predictable manner.  In the solutions space, this boils down to methodology and techniques for repeatability.  I would look in the following areas to demonstrate evidence of this competency:

• What methodology do you generally use?  For what types of projects does this methodology work well?  Where doesn't it work well?  What other methodologies are you familiar with and do you incorporate some techniques from them in your projects?
• How do you ensure that the solution meets the business requirements?
• How do you ensure the quality of the solution?
• How do you determine the right amount of infrastructure/hardware so your solution will scale/perform appropriately?  How do you know what is appropriate measures for scale/performance?
• What artifacts do you always produce?  What do you sometimes produce and why?
• How can you ensure that your solution will fit into the data center and meet their policies?
• Do you have situations where you refined your architecture/design during the project - how did that impact the project?
• What roles have you played in project management?

Technology Breadth

Official Statement 

Candidates understand architectural best practices and are able to apply them across a breadth of technologies to orchestrate a solution. Candidates can articulate their views on the future development of a technology, they understand the interaction between infrastructure and solution architecture. They use these insights to design appropriate architectural solutions.

• Apply architectural and engineering concepts to design a solution that meets operational requirements, such as scalability, maintainability, security, reliability, extensibility, flexibility, availability, and manageability
• Think abstractly and demonstrate effective application of service-based, object-based, and component-based modeling
• Effectively adapt solutions to the capabilities and constraints of the infrastructure
• Demonstrate a range of software development skills, such as:
  • Data access and transactions
  • Factoring and refactoring
  • Tiers and layers
  • Application of patterns
  • Integration strategies
• Have a broad architectural knowledge of several technology areas and be able to compare and contrast multiple vendor offerings in those areas
• Learn new concepts and gain expertise quickly

My Comments 

Many people when they look at this certification they think that because it is a Microsoft certification they only need to be skilled in Microsoft technologies.  I have seen people that have failed because they did not have enough skill outside of the Microsoft technology stack.  The MCA was built around the philosophy that it would be technology agnostic - an architect deeply skilled in BEA or IBM technologies would have as good a chance at passing as someone deeply skilled in Microsoft.  If you are deeply skilled on Microsoft's integration platform, I would expect that you would know a fair amount about competitors to BizTalk.  If you were deep on ASP.NET and the Microsoft web offerings, I would expect you to know a bit about PHP and JSP.  Not only would I expect you to know a bit about them, but understand the scenarios when a different vendors' product might be better choice. 

Additionally, you should have some breadth of knowledge outside of your competency area.  Most good architects I know can pick up new technologies very quickly because they have experience in a related technology.  

Technology Depth

Official Statement 

Candidates demonstrate that they have a detailed knowledge of the concepts and application of at least two depth competencies. Candidates also demonstrate the ability to quickly assimilate information about new technologies.

Examples of depth competencies include, but are not limited to, the following:

• Component and solution modeling
• Solutions frameworks (for example, the Microsoft .NET Framework and Java 2 Platform, Enterprise Edition [J2EE])
• Integration, as evidenced by knowledge of traditional enterprise application integration (EAI) products such as Microsoft BizTalk Server, IBM WebSphere, or BEA WebLogic
• User experience, including smart clients and adaptive UI
• Data structuring and management

My Comments

When you pick your technology specialty, I can almost guarantee you that someone on the board will be deep in that technology also.  Nearly everyone I have met that has passed the MCA has been amazing with their technical acumen in multiple areas.  I recall when I walked in to do my board; I was shocked because there were people on the board that were published luminaries in their fields.  I have yet to see a candidate be able to fake their way through the technical areas of the board.

The big question here is trying to figure out the level of depth that is required to meet the competency.  I believe that in your depth areas, you should be able to be a skilled implementer.  If you stated that your depth area is integration, I would expect you to know the WS-* specifications, know how to write WCF applications, and write BizTalk code/maps.  It doesn't mean that I would have you get on a whiteboard and start writing code, but I would want to discuss some of the finer points of the technology and the whys of the technology tradeoffs (when to use specific channels in WCF for example).  I believe that a good architect will write code at least a couple of times a year to keep their skills sharp.

Summary

As I have mentioned many times before, the commentary is my opinion on each of the competencies.  Prior to interviewing candidates during the week the review board members go through several exercises to build a “strawman” to certify against so that they don’t let individual biases and the candidates prior to you interfere with their rating of you; all candidates are measured against the same criteria and measured to the same level.   If you decide to go in front of a board, I'd recommend finding an MCA and getting a second opinion of the competencies to obtain further perspective.  Additionally, before you go in front of a board, review the competencies and be very honest with yourself.  Get second opinions from friends who will be brutally honest with you.  If you truly believe you meet the bar - go for it. 

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

What else should you do to prepare for your board interview?  Not much really.  I believe this to be a certification that you either know or don't know prior to going in front of a board.  For example, if you were weak on methodologies you really can't learn the pros, cons, and nuances of the agile family of methodologies just before walking into a board.  If you were weak on the breadth of a particular technology, you wouldn't be able to develop the skills in that area beyond the marketing fluff in time.  You really possess or don't possess the competency and can provide evidence on demand during the board interview. 

So what do I suggest?  Review some areas where you might have let your innate skills atrophy a bit.  If you are deep in integration technologies and have worked with Tibco in the past, do a quick review of their latest offerings and what they have that is new, or what other companies might be offering these days.  If you haven't worked on a non-agile project in a while - take a pass at the popular notions in the RUP space.  Don't spend too much time with this because it won't pay dividends.

If you know someone that is already an MCA you may ask them to conduct a mock board review for you.  You could also request one from the program.  If you take this route, please ask the person to be very critical - you are going to be better served by finding out what you need to work on prior to going in front of the board.  If they tell you that you will pass, be skeptical and re-review the competencies - don't let them set your expectations because I have heard too many times where a "mentor" has been wrong.

I also suggest relaxing and not worrying about it too much.  In my mind it is kind of like the SAT.  You really can't study for it, but you might review some things you already know or concepts you have worked on in the past.

As with any type of test like this, there will be some stress leading up to the board.  There is not a lot of advice I can give other than deal with it the way you handle stress in other situations.  If you are traveling to the board, make sure you get there a day early with plenty of time to relax with a nice dinner or movie the night before.  Put aside your other distractions like work e-mail and focus on a fun and relaxing evening in the city where the board is held.

You also might try to request a time slot for the board that works best with your natural "best time of the day".  There are three boards a day - morning, after lunch, and late afternoon.  Based on how your body clock works, and how far you traveled, you might try to match that up appropriately.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

Now that you have decided on a project and pulled together all of your documentation, you need to put together a compelling presentation.  I am going to assume that if you are an architect that you know how to put together and deliver a great presentation and avoid the common mistakes.  Even if you are an experienced presenter, I recommend reviewing some presentationtips.  I personally only have one major pet peeve when watching others present - reading the slides.  Please don't read the slides - I can read them myself.  I want to hear the story.

Prior to beginning your presentation the facilitator will ask you for a couple of technical depth areas.  This is meant to be a technology not a product - you would not pick BizTalk, you would choose integration technologies.  This certification is for an architect, not someone that is a specialist in a particular product.  Pick carefully the areas that you know well - not just the product you know well.

The thing to remember with the presentation is that it will be the only time during the board review that you are in control - the remainder of the review will be controlled by the board members.  Your job is to tell the story of your project in a fashion that will communicate how that scenario demonstrates that you meet the competencies of the MCA.  The trick is to tell it as a story - not as a rehash of what is in your documentation.  Here is a rough set of topics I suggest you might pull together your presentation:

• A little bit about you
• Information about the project
  • What business problem does the project solve and how does it accomplish that objective?
  • What is the reason that someone decided to spend money/resources on this particular project?
  • Who composed the team and what was your specific role on the overall team?
  • What was the timeline and budget?
• The project itself
  • How did you gather the requirements?
  • What tradeoffs did you make and why?
  • How did you ensure quality?
  • What type of methodology did you use and why?
  • What types of team/organizational challenges did you run across?
  • How was the project documented?
• The technology
  • Show me the overall architecture
  • What was unique from other projects?
  • What was challenging?
  • How did you know that the solution met the requirements?
  • What was your technical contribution?
  • Highlight something from your technical depth area.
• Deployment
  • How did you deploy the solution?
  • What did you do to ensure that the infrastructure of the solution met the appropriate requirements?
  • How will the solution be managed going forward (bug fixes, enhancements, changes to the infrastructure)?
• Project results
  • How did the solution perform against the original business justification?  Technical requirements?
  • What problems did you encounter after deploying?
  • What lessons did you learn?

Remember, you have 30 minutes to present - you will be cutoff at exactly 30 minutes so you need to ensure that you are getting your points across in an efficient manner.  I also recommend as you put together your personal outline, that you start to cross reference with the competencies published for the program.  Not just the high level competencies but also the sub-bullets. It is important to ensure you are showing the board how you meet the competencies.  However, you don't want to directly show how you meet the competencies - you want the board to come to that conclusion on their own.  I recommend that you do this through stories and anecdotes about the project.  For example, if you had a tough situation between two stakeholders you might discuss your role in that conflict and what you did in that situation.  If you had a junior development team, how did you bring them along to make them productive?  This is a much more interesting way to present yourself and is much more compelling to the board.

You don't have to cover every competency and every sub-bullet as part of your presentation.  In fact, it would probably be difficult to cover everything.  Just remember that the board will look at every competency and every sub- bullet and will ask you questions about ones you have covered and in particular the ones you did not cover.  If you provide strong evidence of meeting a specific area in your presentation, you may not be questioned on it later.

As you put together your presentation you should be aware of the "I" vs. "we" statements you make.  If you are like me, you tend to try to shine the light on the team and have become very accustomed to saying "we" around the accomplishments of the team.  This certification is about you - so don't be afraid to differentiate the times where you want to highlight your accomplishments instead of just the team.  The board is trying to understand your role and impact on the project, not just your ability to be a part of a functioning team.

You need to practice your presentation a few times beforehand and get your timing down and keep it under 30 minutes (I suggest you target 26-27 minutes just so you ensure you finish on time).  I don't advocate over practicing because it can take the passion out of the presentation.  You need to maintain your passion and excitement and if it becomes unnatural or rote the audience will know it.  You know your project and yourself well and you should be passionate about the subject.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

Once you sign up for the program you will be asked to provide a set of documentation.  This documentation will include a resume/CV/work history, a summary of the project you will present, and a write up of how you meet each of the competencies. 

One thing you should consider as you put together your documentation is how to make the information as efficient as possible for the reader.  The documentation will be the first impression you make on the board and I guarantee they will read every word.  Recognize that the board will have up to 12 candidates in a week.  If you multiply your documentation by 12, you will realize that the board has a huge volume of documentation to read before they start seeing candidates.  I am a fan of getting the right amount of information into the documents to demonstrate your competencies and NO more than necessary. 

The documentation step also presents the first choice you will need to make as part of the process - you need to choose a project that you will present.  I encourage candidates to find a project where they can best show off all of the competencies.  Realize that the first component of the Board questioning will be about your project and how you demonstrated meeting the competencies as part of that project.  Sometimes that might be a project that is a couple of years old and it may not represent the largest project you have worked on.  Additionally, the project should have been successful.  I also encourage candidates to reuse artifacts if possible from their project as long as it represents their work (not absolutely as full author, but where you directed the efforts and was responsible for the artifact).  The goal is not to make additional work for the candidate, but to provide the best set of information about the project that demonstrates the competencies of the candidate. 

The write up of how you meet the competencies should be your opportunity to present yourself - don't be afraid to brag a little bit about your abilities and why you should be an MCA.  When I am on the board, I tend to focus on this document because it is the best "holistic" view of the candidate.  Review the competencies again and make sure you are addressing each competency.  Your resume/work history should be a fairly straightforward document.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

Before you apply, I would recommend that you think long and hard about why you are motivated to get the MCA.  The process is expensive, difficult, time-consuming, and a highly emotional experience.   

The MCA is one way to measure an architect.  You may be an architect and extremely successful, but you may not have the competencies to be an MCA as it has been defined by the certification.  The certification is for practicing architects with a very broad set of skills that have proven experience creating significant architectures.  Take a close look at the competencies and be very honest with yourself.  Are you deeply skilled in all of these areas?  If you are deficient in an area you may not pass.  There are some architects in the industry that are well published and highly respected that wouldn't pass the MCA because they don't possess all of the competencies.  I have good friends that I respect greatly that haven't passed.  That doesn't make them any less of an architect - it just means they are not an MCA as defined by that particular measure of an architect. 

Here are a couple of the reasons that I have heard as I have asked people why they wanted to obtain the MCA:

Reason: I have my MCSD/MCSE/MCDBA/etc. and this seemed like the next logical step.
My Response: This is a very different certification than any other.  If you want to get your MCA make sure that you meet the definition and have the appropriate experiences.  I don't believe this is a certification for someone that just wants another acronym to stick on their business card.

Reason : I believe that the MCA will help me get more opportunities and increase my salary.
My Response: I don't know what the return on investment is for achieving an MCA, but I can tell you from personal experience that my salary hasn't increased because I am an MCA and I haven't charged up the company ladder because of it.  I think it has opened a couple of networking channels I didn't have in the past.  The reality is that as of this writing there are fewer than 100 MCAs in the world.  A lot of people have heard of it, but don't know much about it.  Employers aren't making it a criterion for selection of employees.  If you get your MCA today you will likely not notice much material change in your life in the short term.

Reason : I am in customer facing role and would like to have the MCA stamp of approval to help make my customers more comfortable.
My Response: Today, this may help you a little, but be prepared to explain the program to you customers and prospective customers.  Deep knowledge of the program is not widespread so it probably won't have huge results today.

Reason : I have realistically looked at the competencies and believe I have the right skills to achieve the certification.  I would like to get a board of peers to review me and either confirm that belief or help me understand what I need to do to improve .
My Response: This is a very appropriate reason to want to get the certification in my opinion.  If you decide you want to try to achieve the MCA, you need to take an approach that if you don't pass that the feedback will be something you can use to improve yourself. 

If you have made it this far and still think you want to apply, I think you should.  Go to the Microsoft Certified Architect site and fully comb through it (there are a lot of resources there if you spend some time).  I believe that in a couple of years when the total number of MCAs and the general awareness increases, the prestige of the certification will drastically increase for those that have achieved the MCA and it is always fun to say you were one of the first ones certified.  If you have the competencies, it is great to get in early.  Furthermore, once you are an MCA you have an opportunity sit on a board to certify new MCAs - which is one of the best mental exercises I have ever had.  It is also a way to build out a network of people around the world that have a common experience - I have built some great friendships from this that I wouldn't trade that have made the whole thing worthwhile.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.

In early 2005 I was asked if I would sit on the initial board for the Microsoft Certified Architect (MCA) program while it was in its beta stage.  Because there were no certified architects already, the board consisted of only non-certified people.  As a condition of being part of this board I was required to come back through the second board and attempt to be certified.  I was surprised and excited when I passed and became a fully fledged MCA in Solutions in March of 2005.

Over the last couple of years I have sat on a couple of boards and have mentored a number of people who have gone through the program.  Recently after I finished a board in Istanbul, I reflected on the program and thought I would write down the "What would I tell a candidate" series of posts about the process.

This series will cover the following topics:

• Why do you want to get the MCA?
• Preparing the documentation
• Putting together your presentation
• What else can you do to prepare for the board?
• The competencies
• Going in front of the board
• What to do with your results

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.