Approaching this topic as an Architect, I've taken the view of splitting this into two parts, the first is an overview of the MetaModel that describes a professional role, the second is more extensive and applies that MetaModel onto the Architect role.

MetaModel for a professional role

Any professional role comes with a common set of terminology, activity description (processes) and method that allows for a common language within its industry. Architecture is no different from this, for example, if you are a practicing Architect within company '1' and you move to company '2' there should be a consistent set of architectural language across both companies, within some variances, based on company practices.

Similarly because the activities, the 'what', of being an Architect are based on the structures they follow, such as Governance, Design and Assurance they tend to be common in nature, whatever the industry or the subject. Conceding that the detail in the activity is different, such as whether the design or business subject is Telco, Financial or Marketing, but detailed knowledge of that subject makes someone a subject matter expert, not an Architect.

Lastly we have the Method, or the instruction set, the 'how' to perform architectural processes. This is the bread and butter of being an Architect, this is the way you think about framing an argument across a variety of stakeholders, or the way you research and collate a set of options on a decision paper.

Applying the above model to being an Architect

So applying the above model to the role of an Architect we can list out several key items that would populate this MetaModel. Note that this isn't exhaustive, but rather an initial set of data, the common things you should really know. This should be treated as a starting guide, a set of terms or topics to make sure that you are at least aware of and ideally able to describe in good detail. I stress this as I've held quite a few interviews for Architects and been surprised how many candidates are not familiar enough with some of these terms to be able to describe them in sufficient detail.

On top of this I've added a section on who would engage in the topics raised here, after all there are several types of Architect, and knowing what they are and what they do is vital to being a functioning architect. Note that these roles are largely taken from the TOGAF model.

Roles

• 1. Enterprise Architects
• 2. Solution Architects
• 3. Service Architects
• 4. Application Architects
• 5. Data Architects

Terminology

• 1. Architecture Review Board
• 2. Governance
• 3. Assurance
• 4. Solution Design
• 5. Architectural views, such as Conceptual, Logical and Physical
• 6. Building Blocks
• 7. SOA - Service Oriented Design

Activities

• 1. Stakeholder Management
• 2. Review and approvals cycles
• 3. Decision papers & impact assessment, including things like Change control
• 4. Stakeholder specific formatting of designs, tailored to their specific viewpoints
• 5. Architectural levelling, such as 10,000ft view, 50,000 view etc. Used commonly to describe the level of detail a solution is at.

Processes

• 1. Modelling processes, i.e. How do model solutions
• 2. Discovery processes, such as how a process, system or application works
• 3. Documentation processes, such as common MS office based work
• 4. Options papers, where several options are presented, they are compared and a recommendation is put forward to form a complete argument
• 5. Alignment to Principles and Patterns - Showing Architectural thinking and alignment to Strategy

I would consider all of the bullet points above as key things to be aware of i