Better positioning architecture resources in the employment market.

Print Friendly

Surveying current architecture roles in Australia reveals an explosion of numerous, confusing and frequently ambiguous job titles. Over a 30 day period a staggering 71 different job titles emerged with some probably being missed.

Many of the roles advertised were seeking similar skill-sets but used different wording in their titles. Others, when looking at the associated job description, were ambiguously titled.

This would suggest that there were not in fact 71 different skill-sets being sought and indicates a major issue in both identifying and advertising for architecture resources.

Role Role Role
.Net Architect Enterprise Architect (Amazon Web Services) Salesforce Technical Architect
Application Architect Enterprise Information Architect SAP Business Architect
Application Solutions Architect – Mobility Enterprise Solution Architect SAP Solution Architect
Architect – Contact Centre Avaya Enterprise Technology Architect Security Architect
Architecture Manager Head of Architecture Senior Architect
BI Architect ICT Facilities Technical Architect Server and Storage Technical Architect
BI Architect – Microstrategy Information Architect Sharepoint Architect
Biomedical Solution Architect Infrastructure Architect Solution Architect
Business Architect Integration Architect Solution Architect – EDW
Business Capabilities Architect IT Architect Solution Architect – GIS
Business Process Architect ITIL Architect Solution Architect – Geospatial
Chief Architect Java/J2EE Architect Solution Architect – Healthcare
Citrix Solution Architect Junior Architect Solution Architect – Oracle eBusiness
Cloud Architect Lead Architect Solution Architect – Unified Communication – CISCO
Customer Solution Architect Microsoft Business Intelligence Architect Storage Architect
Data Architect Microsoft Cloud Technical Architect Systems Architect
Data Solution Architect MS Dynamics Architect Technical Architect
Data Warehouse Architect Networking Solutions Architect Terradata Solution Architect
Database Architect OSS Solution Architect TIBCO Solution Architect
Enterprise Architect Payments Architect UCS Architect
Enterprise Architect – Applications Portfolio Architect UI/UX Architect
Enterprise Architect – Infrastructure Pre-sales Network Architect Virtualisation Architect
Enterprise Architect – Infrastructure Portfolio Principal Architect Web Application Architect
Enterprise Architect – Marketing Business Domain Program Architect

The plethora of advertised titles leads to both confusion, with the potential for:

  • Employers to miss the candidates they wish to target and
  • Candidates to miss seeing real opportunities.

Anecdotally there is a perceived hierarchy of architectural skills with roles including the word ‘Enterprise’ expected to attract better skilled applicants. Applicants can also at times use word combinations in their own titles, sometimes erroneously, to put themselves in a better light when presenting themselves to potential employers.

This hierarchy, whilst perceived, does not really reflect the value that different architectural skill-sets provides to the business community.

An Enterprise Architect is demonstrably different to a Solution Architect but is not necessarily better. Which skill-set the employer needs is dependent on their requirement. The business with the wrong skill-sets will not prosper as well as the one with the right skill-sets.

The architectural community tends to be broken up into 2 key dimensions.

  • Those with breadth of knowledge and experience,
  • Those with depth of knowledge and experience.

Breadth and depth are not mutually exclusive.

The degree of breadth and depth provide an indication of scope and focus that the architect can bring to the business.

Analysing the roles advertised, many of the role Descriptions were clearly similar, even though they had different titles. Some roles were mis-aligned with their descriptions leading to further confusion.

Roles, such as the ‘Virtualisation Architect’ and the ‘Citrix Solution Architect’ with specific product knowledge, obviously being closely aligned but differing in their required breadth and depth of knowledge.

Role titles including the terms:

  • Junior
  • Senior
  • Principal
  • Lead
  • Head
  • Chief
  • Manager

all evoked expectations of the degree of knowledge or responsibilities required by the applicants.

The architecture community would be well served by devising a standard ontology and associated nomenclature that supports the architecture skill-sets on offer.

Defining roles and providing supporting position descriptions would be simplified if there were a common base from which to work. Doing so would provide prospective employers a more useful tool to support resource identification and acquisition whilst providing architects with a more focused approach to describing their skills and positioning themselves in the market.

Architecture_Roles

Suggested Ontology for discussion

An ontology with an associated nomenclature allows the skilled resource to be simply described. Describing roles consistently by focus, breadth, depth and responsibility would provide requisite clarity.

Incorporating families of architecture skill-sets within the ontology such a Business Domain Architect and Technology Domain Architect would provide a an indication of skill-set segmentation, focus and scope.

A suitable and agreed ontology and nomenclature would provide a mechanism for:

  • Architects to better manage their careers,
  • Architects to provide improved clarity to the market of their architectural focus, knowledge and skill-sets.
  • Businesses to better describe and source the skilled resources they require,
  • Recruiters to better target and assess suitable candidates for the roles advertised.

 

This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

2 Responses to Better positioning architecture resources in the employment market.

  1. Oliver Baier says:

    Hi.

    This is valuable. And interesting. Could you please elaborate a little on the Business Domain & Technology Domain Architects? How do these differ from the Business & Enterprise IT Architects (why then not “Technology Architects” for the latter?)?

    I assume you use “domain” for a defined part of the enterprise. If so, I think there is value in considering holistic/enterprise architects for specific domains as well (i.e. what I think TOGAF calls a segment…although I’m not getting into a TOGAF discussion here…).

    Cheers,
    Oliver

  2. Sidar Ok says:

    This is indeed a good starting point.

    I would question the need for Product architect and would like to know what you mean by that.

    It would also be good if you could provide some description for these roles, as titles can be highly misleading.

Comments are closed.