As part of an ongoing series of articles covering the skills and process that people go through in order to move into architecture I thought I'd have an exploration through the landscape of professional qualifications. The key discussion topic was driven from a recent conversation on whether architectural qualification are valid, whether they enhance an architects skills or validate the architect as being more 'architecturally capable'.

I've split the article into what architectural qualifications mean to several different parties, such as individual architects, companies that use architects and the architectural industry as a whole. This is mainly because each of these parties have very different requirements and goals around professional qualifications, reasons to obtain them, and what value they provide.

The Individual view

For the individual architect obtaining a professional, industry recognised qualification can bring several benefits. First, architecture can sometimes be a little intangible. We don't physically produce anything, and often what we produce is proprietary for the industry we are in, making it very hard to measure the quality or validity of output. Possessing a qualification such as TOGAF proves that you know the correct terminology, can recognise architectural artefacts and impacts and are likely to provide architectural documents to a reasonable standard. Its treated somewhat like an architectural 'kite mark', ensuring that there is an inherent quality to the content.

For the working architect its also good to know that your colleagues and peers can understand the content that you produce. If you create a TOGAF or Zachman aligned document you want to know that your colleagues can consume it, and that as a practice it will fit into your overall approach.

Lastly, it makes you a more attractive resource, if you are seeking employment. It's a very good selling point for recruiters and employers as, explained above, its an industry standard, so brings with it a certain quality level when filtering applicants for a role.

Corporate view

Companies can often see qualifications like the ones described here as being overly academic and not really driving their overall goals, in terms of focussing on delivery or project specific issues. Qualifications can be an expensive and timely activity to put your teams through, so are often sidelined entirely, or put at such a low priority that they never materialise. Delivery objectives take over, and all the talk of being a 'people organisation' goes out the window.

Key things a company has to recognise though is that endorsing a professional framework can provide many benefits to them:

• 1. It shows potential recruits that they are serious about their architecture and that they are prepared to invest in their people
• 2. It's a handy metric in the review process. Send everyone on a course, and their pass mark is a very good metric in what can be a very ambiguous process (employee reviews)
• 3. Where a practice aspires to ensure a consistent level of service to other departments from its architects, knowing that they are all qualified to the same level, and know the same content. This somewhat equalises the organic way a team forms.
• 4. Lastly it's also a good measure of capability. It may sound harsh, but being an architect is a hard role to perform successfully and consistently. If you are unsure of the calibre of the people in your team, an effective way of measuring it would be to send them on a course and measure the results. Similarly if you are trying to build a trainee or junior architect programme they can serve as a good graduate gateway. If a graduate architect wants to consider themselves a fully functioning member of the team, then passing TOGAF or the BCS qualification should be a required qualification.

Industry view

In terms of industry recognition, possessing industry standard qualifications gives you a place in a larger community. There are often social activities and online groups that you can join and participate in. When you look at an architects profile online, there are few keywords that indicate evidence of qualifications and experience. TOGAF, Zachman, BCS and ISEB are the key words I typically look for to determine if a candidate is not only affiliated with, but claims accreditation with one of these bodies. This marks them as a professional architect.

Types of Qualification

There are two recognised industry qualifications for architects, one is based on the TOGAF framework the other being a British Computer Society accredited qualification in Enterprise and Solution Architecture. Obviously there are many books discussing architecture and architecture processes, and even other frameworks such as Zachman, but none of them contain courseware, exams and accreditation processes.

TOGAF

TOGAF is very much a framework. By this I mean it is not a guide as to how to be an architect, it will not tell you how to do the day job, but rather describes an approach. It's a standard methodology and process to enable you to take up an out of the box toolkit. It should, however not be applied in this format. Success with TOGAF is very much a case of assessing the framework, trying the elements out in your organisation and seeing what works for you and does not. If you try and wholesale adopt TOGAF as your architecture practice's methodology you will rather quickly find yourself hitting issues with delivering anything.

BCS, Enterprise and Solution Architecture

The BCS, previously ISEB, course is a tough one. Its an intensive course, covering a lot of content. My advice with this one is that it is not a purist architecture course. You'll need to be aware of ITIL, PRINCE2, Six Sigma and a slew of coding and development technologies. It doesn't require you to have in-depth knowledge on those subjects, but rather to understand what they are, how they work, and how they interplay with architecture. My recommendation is that you have to be a practicing architect, with a few years experience in a tough environment to pass this one.

Further reading

I can heavily recommend a book titled 'Enterprise architecture as Strategy', it's a great read and covers a lot of useful information. Rather than being a theoretical architecture book, I've found myself actually referring back to it at times during my day to day role. Enterprise Architecture as Strategy

Lastly, as I've mentioned above, there is a significant architecture framework, the Zachman framework that is very good to be familiar with. You can read more about Zachman here.

The last few articles in this series have documented what I consider the standard approach to becoming an architect to be, the TOGAF role structure and the key concerns around performing the role of an architect day to day.

I've built the foundation of understanding the role, specifically to ensure a level of understanding of the attributes and activities of an architect. This is key, as in this article I'm specifically looking at the idea of whether or not it is possible to fast track the journey to become an architect. Posing the question, could you take an individual with the capability to perform the role and move them in quick succession through a series of tasks to establish possession of the skills required to operate as an autonomous architect in their own right.

Let me start by saying that there are several assumptions associated with this scenario. The individual, the 'candidate architect' would have to be aware that they are on a journey to display their skills as an architect. The capacity or capability to perform the role would have already been pre-judged as being present, and the candidate would have a knowledgeable support network around them.

What should they be tested against?

As stated above, I've already put together my view on the activities an architect performs. There is a key factor here in differentiating between architects and subject matter experts (SME's). This is import in that these two categories of role are very different, but can often become confused with each other. To understand exactly 'what' we should test candidates against we need to understand the difference between these two type of role.

Subject matter experts

Subject matter experts are people with deep knowledge in a business area or capability. They have deep understanding of their area of functionality, but its a very narrow view. Typically their skillset is specific to a field of business services or technology, such as payments, networks or services. They do not have a breadth of insight across multiple fields or processes. This makes them ideal team members if you want detailed information, at a very granular level, but if you want someone who can be reapplied over many content areas, SME's will struggle as they will be outside of their comfort zone.

Architects

In comparison to the SME description above, Architects have a much wider breadth of knowledge across many fields of technology and business capabilities. They may have more detailed knowledge in one or two fields, specifically where they came from, but as a rule they have limited visibility over other process and technologies. This means that as a member of a team, they are deployable across the whole spectrum of a solution as their skills are not specifically tied to one area of knowledge.

Flexibility and not detailed knowledge

From the descriptions above we can determine that the skills an Architect should have are not based in a specific technology or business process. They should sit above this, as they should understand how to examine and interpret technology solutions and business processes, but they should not have detailed knowledge of them, as that's why you retain your SME's.

When you consider this, it effectively dictates what you would ask a candidate architect to prove. You would NOT ask them to understand each of your business areas, or processes, but instead ask them to show the skills to discover those areas, integrate with the SME's and extract the right information that is pertinent to the solution.

What's missing from this process?

The above describes the technology and business process discovery but it intrinsically hints at needing stakeholder skills and interpersonal skills to be able to operate successfully. They are a little harder to measure as they are less tangibly proven.

The second big factor missing here is the experience and ability to handle the pressures of going through this process. Knowing a task is one thing, but presenting that task back, thinking around it, defending your position when appropriate, or moving on it when its not, are all skills gained from actually going through the architectural process. Experience of previous roles gives people a depth of character that gives them confidence within a business operating model. At its simplest description, discovering and documenting options is a key skill that can be learned. Presenting that options paper back to senior stakeholders with confidence, explaining the process, facing down challenges and holding your nerve is an entirely different skill that is not learned, but more like 'forged' through going through the process repeatedly.

So in summary, I'd say that yes, there is a fast track to 'learning the skills required to operate as an architect'. But I'm separating out that just having the skills does not mean that the candidate can operate as an architect, they need that forging experience to have the confidence and prescience in a room to carry through their architecture directives.

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