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.