In December, I received an email asking how much should an infrastructure architect understand about solution/application oriented architecture. Also, the architect expressed interest in the MCA program for infrastructure architects.
Yes, candidates need to understand the basics of application/solution architecture so he/she can technically explain their infrastructural design decisions for their applications. For example, if a company wants multi-tiered infrastructure architecture for a .net solution or a J2EE solution, we start examining the application component physical behavior (network activity, resource utilization profile, etc...). If we're discussing a multi tier architecture with .net with a browser based solution, then we might have a presentation tier (IIS) communicating with a business transaction management tier (which could be a separate IIS server of the same) which would then communicate with a resource tier (like SQL Server). Understanding basic behavior of basic decomposed application components (like ASP.net, ADO.net, or even for J2EE: EJB, JSP) is important. This is the same if they are promoting Middleware (like MQ-Series, BizTalk, MSMQ, etc..).
If we understand the behavior basics and the application architecture velocity of change (example: the unique impact to the presentation tier ASP.NET component on IIS), then we can make infrastructure architecture adjustments to improve the viability of the solution. An example might be scalability concerns in the future for the specific system: we could then use a larger machine with only partially populated memory and processor slots on the presentation tier web servers so the system can vertically scale without changing the machine.
But you don't have to be a developer. You just need to talk to and learn from the application architecture team about behavior patterns of different components they are using in their architecture, know the vocabulary, etc...Also, there are many good areas to study to work with them better.
While their systemic / non-functional models are usually less than desired, the application architecture field has developed good functional design models which are important for infrastructure architects to understand so they can speak the same language:Unified Process oriented artifacts Use Case diagrams, Sequence, etc...)Common Methododological processes: example: Waterfall, Unified Process, TOGAF, MSFEnterprise Architecture Framework Vocabulary: example: ZachmanPatterns: The Gang of 4 book was great at understanding harvesting observed best practices. Microsoft published a book a couple of years ago on Enterprise Solution Patterns that explains the basic structure well. (I liked the book but didn't always agree with all of the infrastructure oriented patterns in it: but I thought the structure was 80% there)
These are good areas to know and if one is interested in the MCA in the future, it's critical for the MCA board as one board member will always be a Solution architect. They will test that a candidate can communicate with them (the Solution board has the same challenge: an infrastructure architect sits on every Solution board)
As for the MCA program, I'm glad to see so many people expressing interest in the program. It’s very tough but valuable program where I encourage skilled, experienced professionals to undertake. For those without the enterprise level experience, Microsoft is developing more of a multi-knowledge testing model for those wanting to transition into it rather than going straight for the MCA.
For candidates interested in the MCA:Look at the MCA core competency website and examine the sub-bullets of each area.
Architects demonstrate 3 core capabilities: Knowledge, Experience and Perspective
Think about demonstrating all 3 capabilities in all 7 MCA core areas of measurement.
The board measures on 7 core areas:LeadershipOrganizational DynamicsStrategyCommunicationsTechnical DepthTechnical BreathTactical
The board currently is made up of 4 people (2 Microsoft, 2 non-Microsoft, and one person must be a solutions architect)
Every board wants candidates to pass the examine:
However,Each board member must attain actionable evidence from the candidate (through written, presentation and Q/A) for the sub-bullets of each area. Then, after the candidate leaves, the board members must defend their decision to the other board members with actionable evidence
To understand what they must do, have a friend interview you for 5 minutes on Organizational Dynamics for a specific architecture you completed.
Then, based your answers, the friend must rate you overall Exceeds, Meets, Nearly Meets, Does not meet
Based on evidence they attained for the sub-bullets of organizational dynamics.
Organization Dynamics: Candidates show that they are able to recognize the key stakeholders in a project and that they can work with those stakeholders to drive a project to a successful conclusion. They present the ability to pick the right battles at the right time and then recognize the political landscape that influences a project within an organization and then influence organizational politics for the success of their projects.
1) Adeptly maneuver through politically-charged organizational situations
2) Effective in building mutual partnerships and networks with parties or organizations
3) Relationships with other architects and project stakeholder
4) Have an awareness of the internal legal organization and ensure legal guidelines are met
5) Be comfortable with compromise and conflict
Then, for each sub-bullet, ask the friend what evidence they attained. Challenge them about that evidence. Was it actionable activities you did or just general statements or nothing. They must back up their classification.
This will give you an idea of the board dynamics.
I hope this is helpful.