How to Stop Screwing Up Architect Titles

Your organization needs to switch to a competency-based and fully externally assessed architect role immediately.

February 25, 2022 Holt Hackney Applications & Technology, Elevating Architecture, leadership, Strategy & Planning 0

By Paul Preiss

“Hiding behind a title to create security is insecurity” – Richie Norton

The world is full of architect titles. Aspiring architect, functional architect, solution architect, cloud enterprise architect, Salesforce architect, service-oriented architecture architect (I like spelling that one out because when you do, you realize how stupid it actually sounds out loud). Some people gave themselves the title (think developer gone architect on Upwork), some people were given the title randomly (think of a boss walking in and saying hey Margaret we are making you the architect), some have gotten degrees in architecture, some test-based certifications like TOGAF, some board certifications like the CITA-Professional. But in all of this, titles are still up to the employer. It’s why I wrote the fluffy bunny architect article. Because in all of this crazy, no one can say objectively whether someone is an architect or not… except in one of those cases and that is the board-certified architect… but we will come back to that.

What’s In A Title?

First, let’s get a better idea of where all of these titles come from and why this is important. There are three elements that are impacting the way we title architects today negatively.

The number one component of the title is the word architect. I will not rant again here about using the BTABoK competency model based on the five pillars of Business Technology Strategy, Information and Technology Environment, Human Dynamics, Quality Attributes, and Design. But the base of any title is the title architect. That needs to be fixed first. Your organization needs to switch to a competency-based and fully externally assessed architect role immediately. It will fix almost everything else.Bad title add-ons, as I call them, just muddy already murky waters further. They are evil and must be destroyed. Title ‘add-ons’ are anything you put before or after the title architect. Iasa uses the generic term business technology architect to differentiate from building and landscape architects.

The negative consequences come in multiple forms:

  1. They make bad decisions or worse. This has far-reaching consequences which we will explore in a future article on Decisions as First-Class Objects
  2. It ends up leaving huge numbers of stakeholders with a poor opinion of architecture. This erosion of trust is the death of any profession (again imagine if anyone could call themselves a medical doctor).
  3. If anyone can be an architect then no one is an architect. The lack of credibility of the title means we spend more time questioning each other than delivering value.
  4. It makes progress nigh on impossible in the profession.
  5. It undermines the nature of the profession creating ‘sharding’ or splinter groups who define it completely differently.

The three areas of title management that are so detrimental are easy to define and difficult to change. They are the fundamental reason why architecture remains a mess. Clean these up and the field will be able to mature rapidly.

Scope-Based Title Add-Ons

I truly believe scope-based titles are the root of all evil in architecture. Ok that isn’t true… the only thing worse is product based title add-ons

A scope-based title is one that is based on the amount of decision coverage a particular architect controls. To understand scope and coverage go read the BTABoK articles. But it boils down to this… an enterprise architect, is one that was invented to have an enterprise scope. A domain architect then has a domain scope (though domain scope is often confused with depth area as in the data domain). A portfolio architect is also scope-based. In fact, this is one of SAFe and TOGAFs greatest failures in my opinion. They do not effectively battle scope-based titles. While many people still think I have a problem with ‘Enterprise Architects’, I honestly only have a problem with the negative impacts of scope-based titles.

So why is scope so bad? For a few of reasons; a) scope makes us think we are better or higher level than other architects. An EA is ‘bigger’ than a DA is bigger than a SolA, etc… this creates serious problems in who is leading and who to learn from, b) scope is based on traditional management concepts not competencies, c) scope is not expertise, and in fact the higher the scope these less opportunity to practice many of the competencies. I just met with an enterprise architect at a 2 billion dollar organization. He was made the enterprise architect, primarily because he is the only architect. That is a scope-based title.

Think about this… it is the scope of the enterprise, but no one can design an enterprise. It is too complex. Ok call yourself an enterprise designer or a management consultant but an enterprise scope is not an expertise level… Imagine again someone saying ‘I’m the Enterprise Doctor… I medicine the enterprise’. Doctors consult with each other, but they see one patient at a time, just like building architects actually build one building at a time. If you want to be a city planner… call yourself a city planner 🙂

  • Decision Quality: Poor decisions are made as the higher the ‘scope’ the less competence in the details. Lower levels of scope do not mean less expertise leading to the crisis between groups (solution architects don’t listen to enterprise architects etc).
  • Stakeholders: become confused about what architects do, why they do it and why they are in the room. Of then architects without expertise will interact with stakeholders who lose respect for them.
  • Career Path: There is none. Scope can be about complexity, but it does not constitute a career. I am still a software architect at heart though I achieved the Chief Architect expertise level. Career path is about having obvious next steps with clear competency goals in both competencies and knowledge.

Social Construct Titles

Project, product, team, business group titles come up all the time. I am a Consumer Banking Architect is one I heard recently. Ok so why is that bad? Because we change our social constructs all the time. Think how many re-orgs you have been through. Enough said. In some cases, these are depth areas (what we call topic areas) that will stand the test of time, like online commerce or supply chain, but seriously we are trying to make life easier for employers. In most cases, these are times when a manager wants to give someone a boost so they make them the _______ architect.

And NO managers do NOT have the ability to make you an architect, I do not care if they are the CEO or a line manager, only architects can define what makes you an architect… we will talk about architect groups run by non-architects like the Open Group separately. Really dig deep on this one in terms of your mindset. Would you go to an unlicensed physician? Let us not kid ourselves. Either our field is important and therefore a profession and follows professional rules, or it is not important and I can go back to the private sector and make lots more money saying whatever I want (hmmm, that sounds quite nice and pretty familiar 😉 … whew ok rant over.

  • Decisions: Decisions tend to be political consensus-based. A facilitator alone is not able to make critical decisions. Facilitation is not a profession (yes I intend to be controversial)
  • Stakeholders: Stakeholders think of architects as the person with some models, but no ownership. Business people make decisions. We end up with no ownership stake and no recognition of value.
  • Career: This seems almost laughable. How would you have a career path as a team architect… bigger teams? What about a consumer banking architect? More consumer bankingness?

Depth Area Titles

Things like Salesforce, SAP, etc are just products and have nothing to do with being an architect or not. Those should never ever be put in an architect title or certification. Do NOT get me started on the harm both Microsoft and Amazon are doing to the profession with their certified AWS and Azure architecture certifications… we will be feeling that pain for years to come…

Depth Area Titles can become a positive influence as I discuss below, but we have to get really careful here. There is no such thing as a Microservices Architect… that is a Software Design Pattern (it is technically in the BTABoK a Software Architecture Style). That person would be a Software Architect (as you will see) and ALL architects should be aware of the impacts of the microservices style, while software architects would have a very high degree of mastery of multiple software architectural styles.

  • Decisions: Well common this is obvious. If all you have is a hammer then everything is a nail.
  • Stakeholders: I like to call this the ‘brain on a stick’ after what one of my friends said one night. Basically, stakeholders trot you out whenever they need someone who can spell IoT and sound smart, then send you back to your room.
  • Career: We call these people engineers, operations or developers. If you follow a depth area far enough you will be really really good at it. That level of expertise is deeply valuable, but you are not sadly an architect.

Influencers on Titles that are Beneficial

There are a number of title influencers that are actually beneficial, though we will return to how and when they are earned.

Expertise-Based Title Add-Ons

The number one goal of titles should be to standardize on language for expertise. In the BTABoK we call this assurance. So if you achieve a CITA-Professional board certification, the Iasa and the board reviewers are ‘assuring’ any potential hiring bodies that this person is capable up to a certain level of architecture expertise. In fact, I fully expect that this will one day be challenged in court and will become a standard for certain levels of Socio-Technical (Tier 1 Critical) Decisions. Legal enforcement and Liability are beyond this article but we will come back there soon.

Expertise/Assurance Title Add-ons: Aspiring, Foundation, Associate, Resident, Senior, Professional, Principle, Distinguished, Chief. Notice there is no scope to be found only seniority, ability, proficiency and experience is implied.

At Iasa we use 6 expertise title add-ons. Aspiring, Foundation, Associate, Professional, Distinguished and Chief. Only four of these are certified. That is important because certification means that we are legally backing this persons work.

We also recognize ‘Fellows’ who have contributed to the profession so greatly they get to be famous.

So a Professional Architect at Iasa is one who has achieved significant experience and demonstrated success and proven that to a board of similarly board certified peers.

Specialization-Based Title Add-Ons

Specialization-based titles are effectively competency areas of deep expertise. They are built on top of the base competencies (the five pillars). Specialization add-ons are NOT topic or knowledge area based. So there is not an AI specialization, unless we can demonstrate competencies not knowledge areas.

Currently the BTABoK recognizes 4 specialization area and 1 generalization area. The generalization is solution architect as they need to know enough in all 4 specializations to be effective in the design and delivery of business technology strategy. The specializations are Business, Information, Infrastructure, and Software. Our acronym for this is BIISS – which worked out nicely :-). The goal of specialization is that we identify with a set of primary competencies which are beneficial to the profession and in which we gain experience.

So where does that leave us? Things like:

  • Professional Business Architect
  • Distinguished Software Architect
  • Associate Infrastructure Architect

All of those can be certified and we are looking into the possibility of making chief architect the final certification level. By certification it means that we as a profession can assure employers that this person is capable; a) as an architect, b) at a certain level of expertise, c) within a particular specialization area.

But wait there is more…

Knowledge-Area Add-Ons (This One is Dangerous)

There is an open question about what we call topic areas. For example, AI, IoT, Cloud, Security, Integration are all topic areas. I honestly don’t know how we should answer this one. In medicine, deep knowledge areas are most commonly handled as what are called fellowships. Basically, they come ‘after’ your specialization. For example, a huuuuuuge number of titled ‘cloud’ architects are actually infrastructure architects by our competency model.

Some of these should be treated as separate from expertise levels with their own levels of certification but it is possible that some will become their own specializations. For example, we have a Security Architecture working group diving into this right now. Integration is another likely candidate for specialization though it could also simply be an information architect topic area. AI will likely stay separate as it is clearly a topic area.