Microsoft Certified Architect

The MCA PM has left the building

The PM is gone, long live the PM. I could go on, got a million of 'em...

I've been the PM for the MCA program since inception and wanted to give a year-end report card on the program and introduce the new MCA PM. I’ve recently taken a new position inside of Microsoft and while tough to move on, felt the opportunity for the program and myself were too great for me to stick around.

This year has been a significant year for the MCA program. We now have over 100 certified as MCAs worldwide. The mix is as hoped between Microsoft and non-Microsoft architects, worldwide representation, and infrastructure and solutions architects. While the number are even between the numbers of men and women certified, we have both and I am very proud of that. The process is continuously open to all that are interested and the process to achieve the certification is solid. People are starting to ask for MCAs as they have big, high-risk IT projects they are starting, and people with the MCA certification are sought after to top-level positions.

The community of architects that have achieved the MCA (and many of those that have not been as successful or have failed, worked on the feedback provided and come through again successfully) are an amazing group of people. IT has been my please and a true honor to work with these people. I can say (without any reservations) that the MCA community is by far the most dedicated and humble group of people I have had the good fortune to work with and each one of them is responsible for the success of the program and community.   

On the less positive side, the term IT architect is still not generally agreed upon by everyone, but the work done by Microsoft, and by organizations like the International Association of Software Architects (IASA) and The Open Group are helping to solidify the notion of what an architect is, what value they bring to a project, and what skills they must have to be successful as an architect. The public web site for the MCA program is not as easy to navigate as I like and the great whitepapers and articles written by the MCA community are not as prominent as I would like.

That brings me to the last topic for this blog entry, and that is introducing the new PM for the MCA program, George Cerbone. George came through the program as an Architect Evangelist for Microsoft based in the North Carolina area of the US. Since achieving the certification he has continued to grow himself as a person and an IT architect. He has also been a strong advocate for the MCA program and worked hard to grow the community and support the program.

You’ll likely see him post here after the new year and with his skills, he’ll be able to grow the program and the community in this breakout year. Welcome George, and congratulations!

-andy   

 

Changes to the MCA program

Don't know if you saw, but at TechEd in the US (6/4/2007) we opened the registration for the MCA program permanently. We’ve done that in conjunction with other changes based on refining and growing the program.

What we’ve found – IT architects that are at the level we certify will achieve (or not) the credential regardless of any obstacles and with or without any support. If you tell an architect of this caliber that they must prepare for an interview with other practicing architects and they will have 2 hours to prove their skills in the 7 competencies and myriad sub-competencies, they will. The people that are not as experienced as we are certifying will struggle regardless of the support provided them, and too much support is not very helpful.

What we’ve tried – We implemented a screening process where candidates were screened by MCAs to assess their readiness to enter the program. This helped with save some people the frustration of preparing for the certification when they clearly were not at a level where they would be successful, but this has had limited success as the assessment is not to great depth. To support the candidate we have set the program up with no support/coaching by MCAs, connected candidates with MCAs for 1:1 coaching, and connected candidates with (up to) 4 MCAs to help them prepare. None have helped the candidates.

What we are doing – The program will now be open year round. There will not be a screening process so the potential candidate can enter the program when they feel they are ready. There will not be a time limit to complete the certification, so if the candidate starts gathering the evidence they submit to the review board and find they need to hone their skills and experience in an area, they can pause during the process and continue once they feel ready to continue. This will also make it easier on the candidate if work gets too busy to allow proper time to prepare. There are (and will be additional) assets the candidates will have access to that will help them with preparing. The MCAs have created sample documents and videos to provide tips and tricks that are available when the candidate needs them. There will not be a requirement to synchronize schedules with an MCA to receive their coaching help.     

What Color are Architects

A while back my group at work did personality training based on colors, very much like the letter (Type A personality) or animal (beaver and squirrel) tools that do the same thing. In it there are four colors, red, blue, green, and yellow. You answer a number of questions and are sorted based on the responses on the conscious and subconscious levels. Red is the leader type, yellow the cheerleader, green the motherly type, and blue the “show me the data and let me research” type.  I ended up being yellow-leaning-towards-red in conscious and subconscious.

All of this got me to thinking about what color the atypical developer, engineer, architect, CTO, and CIO are and how that may indicate areas you would have to grow based on your career direction.

-          Most developers and engineers I’ve met are in the blue area with very little skill in the red, green, or yellow areas; they research on their own and work in closets, popping out every now and again for sustenance. As they gain experience they typically grow in the red quadrant and become a technical lead.

-          CIOs are almost always red; they point in a direction and people follow; no doubt, no question, that is the direction. They grow the other skills to become better and can move, but normally spend their time in the red quadrant.

-          CTOs seem to be based in blue but have grown their green and yellow, but especially their red quadrant. They’ll listen to others, gather information through channels, and then they point in a direction and people follow; no doubt, no question, that is the direction.

Architects come in a lot of flavors, and depending on what type of architect will be slightly different in where they come from and what they grow. But, most experienced and seasoned architects that I have met (and that is way more than anyone should have to meet) are well balanced between all of the colors. They also recognize the traits of each quadrant in themselves and others, and are able to flip from one color to the other without much thinking about it.

-          Junior architects tend to let the red overshadow their personality, but can effectively move to whatever quadrant the situation calls for.

-          More senior architects tend to hover in the green quadrant and can move to any color in the blink of an eye.

-          Technology-founded architects grow from blue to red to green.

-          Business and strategy-based architects tend to start at red or blue and grow the blue and red skills, then yellow, and finally the green skill.

Is there a point Andy? Well, yes. I’d offer the suggestion that if you are growing your career you consider growing your interpersonal skills. To do that, you would likely need to take a hard look at yourself, figure out where you are starting, which skills you have, and where you could stand to grow. If you are technical, you likely could care less about business stuff, and likely could stand to look at how you can work better with others.

Is all this absolute? Absolutely not. This is purely anecdotal evidence I have gathered through a long career in IT and what my experience is. But, if you have an objective look you may find that there is some good information there that will help you with your career and overall growth.

Andy, when are you opening the application process again???

The question I seem to be getting the most right now is when will we open the public application process again. Our web site says early 2007 and it is getting to be early 2007. I'm working right now to reopen the application process in April/May/June timeframe. A couple of thoughts of why that is my target.

• Capacity - This process is very labor intensive for the people going through. They have a lot of work (about 60-120 hours) to prepare for the interview. They also work with 4 or 5 different MCA advisors that help them prepare with 4 separate and specific goals. We have limited MCAs and, as you might imagine, architects stay quite busy. Getting the candidate and the advisors connected and the candidate creating the documentation they submit take s a little time and commitment. We don't want to have more people going through the process that we can support in a timely fashion so we don't want to open the process to new applicants to early or too often.
• Timing - When I say "let's open the application process" it takes a few months to align all of the pieces to make it happen, and to give the people that are interested a chance to figure out if they truly are interested in going through the process. That said, I’ve just started focusing on where people are in the pipeline and when we will be able to reopen the open application process.
• Need – How often is often enough? My gut feeling is once a year is good for now, and as we get more people certified and have more capacity to support people going through the process, we can adjust that timing. For now, my master plan will be to open the application process once yearly, but will review where candidates are in the pipeline, how many people are interested in applying (based on how often I am contacted and by how many), and what goals I’ve set for growth of the program on a quarterly basis.

Anyway, like it or not, there’s you answer. If you have comments and suggestions, I’d love to hear them.

-andy     

 

The time is your worst enemy

Why is the time such an enemy when facing the review board? Did you ever dig into the overwhelming amount of sub-competencies that are checked, measured and evaluated? For each competency and sub-competency you must get a tick from most (if not all) members of the board in order to get a passing score. If possible, the MCA board would give you all the ticks on the planet, just give them enough evidence through your answers.

So, let’s do some math:

• There are 7 competencies, each one having about 6 sub-competencies. On my last count there were 55 separate discrete sub-competencies, which means 220 ticks in total (55 for each board member).
• Timewise you get 30 minutes of presentation time, 2x4x10=80 minutes of assessment and 5 minutes of closing; that accounts for 115 minutes of review time.

That gives you no more than 2 minutes per sub-competency or just under 30 seconds per tick! Questions asked are at least 10 seconds long, so your answers should be quick, crisp and to the point – or you’ll burn your time out. Learn the cycle: listen; think; answer; shut-up. If all runs well, you can feel ticks piling and reviewers smiling.

But what happens when a candidate is underprepared and the presentation misses the point? First 30 minutes are out, the exploration of Technology depth will shave at least another 20 minutes off and the last 5 minutes will turn into an awkward ‘thank-you-this-was-very-frustrating-experience’ mumbling. The available assessment time is reduced down to mere 60 minutes, which is a bit more than one minute per sub-competency, or around 16 seconds per tick. Assessors need 8 seconds to bark-out the questions so there are less than 8 seconds allocated for your answer. If you are lucky. And often you are not lucky…

Trust me, in such situations you will feel the crunching pressure in the room when board members will rapid-fire questions out of frustration – they want to give you those damn ticks, if you’d just give them the darn evidences! And it is your time you are burning in vain! Give us something! Answer! Answer! Answer!

I heard of some miraculous recoveries after offensively bad presentations, but don’t bet on it – if your documentation and presentation didn’t create a good background for at least one half of the measured sub-competencies, if your answers are not short and to the point, you are doomed and there is not much you can do about it. Better luck next time, mate!

No pressure, of course. J

MCA World Tour

I'm on the road right now hosting MCA review boards. Two weeks ago we were in Singapore and had some very interesting interviews. One candidate from Korea and one from Japan came through and that required us to engage a translator service to translate the documents submitted, and then used interpretors for the interview. Lots of great learnings from those two interviews about the difficulty of translating concepts as well as how the overall process would have to be modified to support the differences in language and culture. Congratulations to Jeok Wee Tan (Singapore's first MCA) and Toyoki Matsamura (Japan's first MCA)!!!! 

Last week and this week I'm in India hosting review boards and then back home for a bit.

BTW, we have posted the first batch of MCA biographies on http://www/microsoft.com/learning/mca.   

Andy Ruth

Microsoft Certified Architect Program Manager   

Couple of sample questions

I tried to avoid writing too many sample board questions as MCA review board is very free-flowing and you never know where the interview will head to. But the pressure is on and here is another batch of random questions that happened on past boards I was on. Enjoy!

1. (candidate claimed that he is a project team leader since the dawn of time)

• How do you assess personality styles of your people?
• How would you mentor someone who is demotivated, confused and frustrated?
• I did a capital mistake for the third time. You have 1 minute to fire me off the project.
• What was the last book on management you read? What did you learn out of it?

2. (candidate claimed that he is strong in IT operations)

• How do you gather systemic (non-functional) requirements from solutions architects?
• What is a SLA measurement unit for: Resiliency, Reliability, Availability, Recoverability
• What is the difference between Problem mgmt and Incident mgmt in ITIL [IT Infrastructure Library]?
• How would the networking architecture change if you’d move from IPv4 to IPv6?

3. (candidate claimed that he is strong in SW development architectures)

• Compare REST, SOA and EDA [Event Driven Architecture]
• Select two construction patterns and diagram their concepts
• Talk about MDA [Model-driven Architecture]. What do you know about MTS [Model Transformation Language]?
• What is Anti-pattern? How do you prevent them happening?

4. (candidate claimed that he is data-centre savvy)

• What is the current wattage density of data centre (Watts per square meter [or square feet if you are from non-metric part of the world])?
• What is the ideal temperature inside data centre [either Celsius or Fahrenheit is fine]? What happens if temperature is higher or lower?
• What are the critical elements of the data centre autonomy? How long can facility survive without water income? Why?
• Explain concepts of Datacenter virtualization. Or, talk about Project Blackbox (if you know it).

Behind the closed doors

Let me try to explain what happens when the MCA candidate leaves the room and the Architecture Review Board (ARB) starts the deliberation process.

The board’s first exposure to evidence of competencies comes through the submitted documentation. It is here that the first impression is formed about the candidate and the interest and questions to be answered during the review are formed.

By the time the candidate finishes their presentation, they usually reinforced the opinion of ARB about the level of competencies. It is the interview process that follows that finalizes the level of each competency.

The hard-to-believe fact is that everyone in ARB wants the candidate to pass, not to fail. During the interview process each ARB member will do his best to uncover the evidence for each competency (and sub-competency). If there is not enough substance in the answer, the board member will try harder, dig deeper and offer several chances for recovery. It may look like interrogation East-European style (especially when I’m on the board) but all the board members want is enough evidence to defend their decisions.

Why? When the moment comes to put markings by the candidate’s competencies, each mark must have a rational explanation. For example, why did I think that candidate demonstrated ability to build organizational partnerships? Where did I see it? How can I justify the passing mark?

Unless I have enough defending material for my decision, I can’t be the candidate’s advocate – which is what I desire to be. On the other hand, I must be a gatekeeper for the advocacy of other members of the review board. Sometimes we cancel each other out, and sometimes agree one way or the other without discourse.

When a candidate does well, I need to call out and identify what specifically was impressive. When they do poorly, I need to both identify where they need to improve as well as tell how. If the candidate is not a match for a MCA programme (in other words, they suck eggs), the interview flow first grows to the insane intensity and depth and is then often terminated prematurely.

As I said before, it is rather unfair: really good candidates get an easy(er) ride, while (sub)average people will be dragged feet-first on the gravel road.

The submitted documentation

I spent last couple of nights reading the whole bunch of documents submitted by board-ready candidates. Sifting through pages and pages (and pages) of material made me very aware that there is obviously not enough guidance on what to put in and how to structure the required documents.

Competencies document
Please don’t bother explaining what leadership (or tactics or strategy) is. Trust me, everyone who will read the document understands what it is, why it is important and what the pitfalls are. Also, don’t explain what your role or job description required from you in the given competency – it will not show that you actually do have it – it will just show that the organization you work for would *like* you to have it. To round-up the picture, please don’t write about what you know regarding the competencies and what you can/could do – this is not what a reviewer will look for.

Think of the competencies document as an extension of your CV – describing specific facts or actions regarding each required competency. So, instead of talking how mentoring is important part of leadership that you practice, give several cases of mentoring: when did you mentor whom? How did you do it? What were the results?

Technology depth
In case you missed it, we are asking for an expertise in a technology, not a product! Active directory or Exchange is not a viable competency for an infrastructure candidate. Identity, Directories or Messaging – name something that spans more than one product. And don’t name more than two of them – trust me, you’ll get hammered on each of the technologies you claim. You have to be able to explain different vendors in your selected technology space, compare their implementations and architectures, explain the future, limitations, alternatives and core strengths. Select carefully and get ready – the ride through the depth of selected technology is very thorough and often quite rough.

Case study document
Think hard when you are selecting your case study - you must be able to defend the case end-to-end, even if you were personally involved only in one portion of the project. It is irrelevant if you didn’t participate in the requirements-gathering phase or if somebody else is doing the operations and maintenance of the presented solution. You must understand the lifecycle of your case – it is *your* case after all! You must prove your leadership, strategy, tactics, organizational dynamics, communications and technology expertise on the submitted case. If your case covers just portions of that, be prepared to be investigated on the missing pieces.

It is all in the preparation – some review boards can be as easy as spring breeze while others are rough drag through the quarry.

Common fallacies around MCA programme

MCA is too expensive

When was the last time you heard of well-regarded MBA programme that is cheap? On the other hand the $10K is the training budget for two years of any senior IT professional (2-3 conferences per year). And the MCA programme is not here to make a profit – it is a cost-recovery (calculate the cost of each review board member for a week plus all the mentoring time). No, MCA is not for engineers, it is for people who are able to gather business requirements, translate them to appropriate language and audit the execution.

 

MCA is not endorsed by academic world

This is a chicken-and-egg problem. Why would academic endorse something that is not proven, tested and verified through several years long cycle? MCA programme needs to show clear ROI, certified people need to prove their qualities and the process behind the programme needs to be tested and verified. Compare it to other serious certifications, such as CISSP in security field or PMP in Project Management – they were not developed by academic world either.

 

MCA is not recognized by clients/HR/employers

That is such a fallacy! Looking at Exchange world nobody wants to have a large-scale Exchange deployment without a formal stamp of MCA-Messaging person (formerly known as Exchange Rangers). I already saw job postings where MCA is a huge advantage to get the position. I also know at least one big (and I mean BIG) System Integrator where you have to pass the MCA certification in order to keep the title of an Architect.

 

MCA is too hard (also MCA is too elitist):

I never heard of a soldier who would whine that Navy SEAL training is too hard or too elitist. MCA programme is a top-gun certification and is not easy to achieve. The goal is that industry starts to value the MCA logo as second-to-none when it comes to credentials of IT professional. If that means we need many years to grow the MCA community, so be it. The quality bar should stay high.

Many MCA fallacies that spawn on the web forums are stemming out of the misunderstanding of the target audience for MCA. MCA programme is not necessarily for old pros who worked with .NET and SQL Server since the dawn of time. If someone spent countless hours installing, testing, uninstalling and reformatting in Beta-ville, that does not make him an IT architect. Architect title is not the new black for engineers – it is a stand-alone profession with its own roots and own destiny.

Just like never-ending battle between construction architects and civil engineers, there will be a battle between IT engineers and IT architects for the top of the hill. Derogative terms used to describe MCAs in some forums ("Microsoft-certified project managers @ $10K a pop") are just the beginning.

But I take it as a really advanced form of flattery to an IT Architect profession.

MCA certified architects as of October 2006

Total certified: 148

MCA Breadth: 70

    Solutions: 48

    Infrastructure: 23

MCA Depth: 78

    Messaging: 78

 

Geographic distribution:

North America: 91

    MCA Breadth: 48

    MCA Depth: 43

Non-NA: 57

    MCA Breadth: 22

    MCA Depth: 35

MCA mentoring

Each MCA candidate is allowed four mentoring sessions to prepare for the Review Board interview. However, each of these sessions is scheduled separately, so a candidate might or might not meet with the same mentor more than once. For this reason, mentors will report the assessment of a candidate's readiness back to the MCA Programme after each session to provide background for the next mentor.

The candidate is expected to drive the schedule of mentoring sessions. However, the candidate is not the best judge of own readiness for the Review Board interview so mentors will always assess their current readiness state and give feedback of the probability of passing the Review Board as on the day of the session.

Although a candidate is entitled to four mentoring sessions, he or she is not required to use them all. The only requirement is that at least one mock interview be held with a mentor. If mentor feels that the candidate is ready for the final Review Board interview after the first mock interview, the candidate may be recommend for an earlier date of Review Board.

Session One – Selecting a project

• Conducting a candidate skills assessment (against seven program competencies) to identify areas of strength and weakness.
• Determining and discussing the best project to showcase skills of the candidate with respect to the seven program competencies.
• Discussing mentor's experience with the document preparation and interview process.
• Providing clear, actionable feedback to the candidate to improve readiness for the interview.

Session Two – Reviewing the initial draft of documents

• Jointly reviewing the submitted documentation thoroughly.
• Suggesting additions or deletions to the documentation. 
• Advising the candidate on the Review Board documentation submission.
• Assessing the candidate's level of preparedness for the Review Board interview.
• Providing clear, actionable feedback to the candidate to improve readiness for the interview.

Session Three – First mock interview

• Conducting a mock Review Board interview with the candidate covering all seven program competencies to prepare candidate for the Review Board interview. If possible, the interview should be conducted in person. If not, Live Meeting or other technologies should be considered.
• Sharing mentor's experience on the board process, including the timing and format of the interview. 
• Assessing the candidate's level of preparedness for the Review Board interview.
• Providing clear, actionable feedback to the candidate to improve readiness for the interview.

Session Four – Recommendation to Schedule for Review Board

• Conducting a mock Review Board interview with the candidate covering all seven program competencies to prepare the mentee for the Review Board interview. (same as above)
• Sharing mentor's experience on the board process, including the timing and format of the interview. 
• Assessing the candidate's level of preparedness for the Review Board interview and recommending that he or she be approved to schedule an interview.
• Mentor to provide the recommendation to MCA Programme that the mentee should be scheduled for a Review Board interview.
• or: Mentor to provide a detailed explanation to MCA Programme in the event that candidate can't be recommend for the Review Board interview.

Broken egos, smashed pride

How do I know that the screening for the first open round of MCA invitations is over? Because my mailbox is starting to fill with opinionated emails ranging from "I'm sooo lame, I'll never be an MCA architect" to "This MCA is sooo lame, now I don't want to be MCA certified".

To all candidates that were accepted: congratulations, well done!

And to all that were not accepted, all I can say is that you got the feedback what to work on. So WORK ON IT, don't indulge in the discussions how useless and unrealistic the MCA programme is! As the old saying goes, your drug dealer is not your friend. You can improve, you will improve and you will apply again. Right?

To publicly answer some of the questions I got:

• Besides a micro-core of the initial seeding architects, every single MCA candidate went through the initial phone screening as well. [My screener was Carol Roy and it was the strangest interview I ever had: a French-Canadian Solution Architect talking to an East-European Infrastructure candidate. You can imagine.]
• There are no relaxed requirements for Microsoft employees. Actually my personal (highly subjective) opinion is that MS folks have much tougher time in the MCA programme as they all wear the stigma of single-vendor, single-technology bias. [The first thing I'd ask an MS employee would be something about UNIX or Java]
• There is no quota set for any stage of the MCA programme. If all candidates would fit, we'd accept all of them. Likewise, there were some review board sessions in the past when not a single candidate passed. [The quality bar is not moving based on the supply and demand.]

Simon started his own thread regarding his experience with MCA programme. He is a real mensch as he is blogging about experiences without knowing whether he is accepted into the programme or not.

MCA and Intercultural issues

As the MCA programme grows there will be many unforeseen aspects and hurdles on its path of expansion. One of them is the approach to different languages and different cultures as the programme expands beyond American-centred boundaries.

Let’s tackle the language issues first.
You may disagree but the fact is that English is not the only language on this planet. Despite the widespread adoption of English as the second language in many countries [accelerated by the US dominance of IT and the internet in recent decades], countries like Japan, Korea or even places like France, Germany or Italy can perfectly run the vast majority of their IT business in their native languages. Yet the (English speaking) MCA review board expects that candidates will be able to cover a vast area of knowledge space in a very short time in the language that the board understands (aka English). In 10 minutes slots there is not much time to translate each English question to your language, do the thought process, translate the results back to English and hope that the words chosen will be understood by the juror. Trust me, I have been there and English is my 5th language – it was as tough as hell. How much slower is the communication process for the non-English speaker you ask? I’d say I had to process information at least 2-3 times faster than a native English speaking candidate just to keep up with the pace dictated by the review board.

Should we allow interpreters (or other means of translation) to help candidates from major language groups to communicate with the board in their native language? Definitely. Should we allow more time per candidate if they are non-English speakers? Well, maybe. If there is more time allowed, are we not discriminating against English-speaking candidates? What if the candidate is more than fluent in English yet demands more time just to gain the advantage and makes his review board session easier? On the other side we can be brutal saying that the language of IT is English so all MCA candidates should be fluently conversant in English (in other words, English fluency should be one of required competencies of an MCA candidate). This may sound as an obvious assertion but it is a road to numb cosmopolitanism and would not be accepted well. When there will be enough multi-language MCAs certified, this issue will dissapear as review boards will be conducted in the local language. But that might be quite far away.

It gets worse when we add the intercultural issues.
Intercultural competence is the ability to communicate with people of other cultures. Good communication includes the sensitivity to issues such as different cultural traits and the ability to ask hard questions the proper way. Let me give a couple of examples:

1. The typical individualistic questions on the review board resonate particularly bad if the candidate is from the collectivist culture (such as Brazil, China, India, Korea and others). Individualist cultures thrive and collectivist cultures stare blank at questions like: “What did you do personally on that project?”, “What would be your worst failure?”, “How was the goal of your team different from the goal of the client?”
   
2. Cultures with high power distance can’t handle the Organizational Dynamics in the same way as cultures with low power distance. Particularly bad questions for high power distance cultures (Arabic, Asian, Latin America): “Describe the situation when you opposed your manager”, “How do you mentor others”, “Why didn’t you just ask the executive?”
   
3. How about risk-averse versus risk-taking cultures? In risk-averse cultures (such as Germany or Japan) you can’t ‘just do it’ and every step of the project will be planned, tested and verified to death. Asking questions such as: “Would you use the beta version of the next-generation product?”, “Describe top 3 risks on your project”, “Are you keen on outsourcing?” is particularly interesting as the answers from risk-averse cultures might be absolutely correct yet will be marked as wrong by the juror from the risk-taking culture.

MCA Study guide for Dummies

This is very amusing: http://eplanetlabs.com/mca.html

For the MCA programme where you have to work with a mentor for at least 6 months and then sit the review board of 4 inquisiting people, you pay “just $29” and you will “pass on your First attempt”? Yeah, right.

But wait, there is more:
“To Succeed in This Certification You Need Not be Technology Expert, Just Buy this Study Guide and Read it Well, You will Pass This Certification Easily, ....We Guarantee it. Success Pass Rating of This Study Guide is 96.8%“

I mean, there are less than 100 Microsoft Certified Architects on the planet yet “By reading our MCA Study Guide product thousands of professionals succeeded in their Certification exam”

I was disgusted at first but then I found it quite flattering – someone is trying to make a profit out of the MCA programme already!

If all the required years of IT experience didn’t give you enough common sense to avoid such fabulastic offers, you really deserve to buy this stuff!