Shaun Mccran

My digital playground


Recruiters, treat your role advertisements as if they were first dates

My most recent interactions with recruiters, both from agencies and in-company, have left me slightly bemused by how they perceive the balance of the employee - recruiter relationship. I've had several experiences where this newly burgeoning relationship has felt very one sided from the very first contact and has been difficult to progress very far due to significant reluctance on the recruiters part to share any information at all.

Recognizing that their objective is to locate a candidate of sufficient quality to get into the face to face interview stage I can normally give them a little leeway in their single mindedness, but there seems to be a growing trend of only providing information pertinent to the employer, not the candidate.

So with the issue above in mind I've put this article together to explain the key elements that I think recruiters MUST include in their role advertisements to ensure that both candidates and recruiters have access to the information they need to make a reasoned, informed decision on the role. I've equated this to a dating analogy, as whilst thinking this through I found that I could draw some simple parallels between the two scenarios.

Think of the 'first date' scenario. Two different individuals meeting for the first time, each giving away small items of detail about themselves, revealing information that might make them appear more attractive to the other, but not quite revealing the entire picture. Each person is judging exactly what the best pieces of information are to reveal, what information they think will portray them in the best light, what will create additional interest, causing the other person to want to dig deeper, to create a more meaningful engagement. Each person has specific expectations from the other, there are typical subject that are normally covered and it all normally happens within certain civilized constraints, i.e. everyone wants certain snippets of common information, but is also aware of staying away from controversial topics. This is all jockeying for position to assess compatibility.

Now lets apply that thinking to the initial conversation between a recruiter and a candidate. Recruiters are trying to ensure compatibility between their role and the candidate, yet often they only come to the table armed with the specifics of the activities of the role and little else. Its fine for them to have demands of candidates, but in my view they also need to cover the following things to ensure that they are giving confidence and assurance to candidates that they actually care about compatibility with them.

  1. 1. Business model and moral compass: What the company actually does, how it makes its money, i.e. its business model and how it sees its self in society, i.e. its moral compass. How do you judge whether it is agreeable to your own, if this is omitted from the description?

  2. 2. Company sector and product set: What types of company are they? Financial? telecoms? Marketing? What do they sell or manufacture? It's not uncommon now to find advertisements that don't actually list what type of company they are, or whether the role is specific to a certain product set.

  3. 3. Salary and benefits: Always a controversial one this, but so many advertised roles do not feature a salary figure, or even a salary range to give an indication of where it sits within the market. This is a key factor for candidates, but also a key bargaining chip for recruiters so is often the last thing they give away. The other important factor with the salary figure is that it is an extremely good marker for the role's expectations. A high figure, or something that stands out from the market is likely to include other factors that in the role that warrant that figure. No salary is too good to be true, there will always be something in the role definition that has impacted that figure. An accurate figure also shows that the company advertising actually understands the role well themselves, and its position within the market. You have to balance this figure with the next point, the location.

  4. 4. The role location, and travelling demands: Pair this with the point above about salary and you have two key counterpoints to each other. Location obviously dictates where you base location is, but also consider travelling requirements as these can, and should have an impact on the salary. Regional locations, cities, secure sites and remote offices all play a factor in influencing both salary expectations and the level of comfort around commuting and the lifestyle impact taking the role may have on you.

To summarise, I think we need to redress the balance between recruiters and their market. If the four points above aren't covered in an advertised role then for me, it shows a lack of attention to candidates requirements, and a misunderstanding of how to create a quality engagement situation, that communicates what each party is actually looking for. If this was a first date, you wouldn't be getting a second.

As an example of this, take a look at the following role advertisements:

Architect roles in Nationwide


Conceptual, Logical & Physical views of solutions

There is a common sets of views that architects have to be able articulate, typically for different audiences, each of which describes the same solution but at a different level of detail. Anyone prescribing to be an architect should be able to clearly articulate these three common views, why they are necessary and how they link together, as there is a strong traceable model between them.

A while back I took a role in mentoring some less experienced architects with an aim to solidifying their architectural thinking and moving them out of a Business analysis and design way of thinking. As part of this in-house upskilling programme I started writing an example of the 'Conceptual-Logical-Physical' views and their relationship. Whilst researching it online I found the example below, from the Zachman site. This is a great example, and clearly shows why the three views exist, and how they convey the right level of information to the correct audience, allowing each role to perform in its own space with, aiming at the same solution, but not restricted by any of the other roles around them.

Conceptual, Logical, Physical architecture example

The "Owner":  CONCEPTUALLY .....   "I would like a pot of flowers in the center of my patio about 10 feet off the ground.  They would be purely for ascetic reasons, but I want the pot to be BIG and the flowers to be real."

The "Designer":  "Let me see now ... the physics of this situation would suggest that there are two LOGICAL alternatives ... either 1) you would have to have a pedestal about 10 feet high, the weight it would have to sustain is max of 100 pounds so if it was 10 square inches in area (cross-section) the material would have to hold 10 lbs per sq. inch.  You're second alternative 2) would be to hang it from something above the pot ... do you have a roof over the patio??  If not, that would mean we would have to construct a tripod to suspend the pot from the apex.  Do you care if you see the tripod? I recommend you go with the pedestal."

The "Builder:"  "The Architect is suggesting a pedestal that would be 10 feet high and sustain 10 pounds per square inch.  That Architect wouldn't recognize a lathe if he fell on one ... but here's what we could do ... we could PHYSICALLY build the thing in three pieces and then glue it together with superglue ... just in case, we could make flanges on the pieces so we could bolt the pieces together to make sure they don't come apart.  Your other alternative is to have it made in Japan and ship it in one piece and then we could install it by drilling a hole in the patio, sinking the base down 2 feet and filling in the hole with cement.

For full disclosure, I have republished this from the Zachman site, the original is here


Is there a fast track to becoming an Architect?

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.


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.


What do you need to know to become an Architect?

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.


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


  • 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


  • 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.


  • 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