Developing IT architecture skills

In a recent post, I looked at the topic of IT architecture from the perspective of what it is and why it’s not all about technology. For brevity, I decided to hold off on the next logical step, which developing the associated skills. So now it’s time to revisit the topic.

What skills does an Architect need?

In my first post, I made the distinction between Technical, Solution and Enterprise Architects and it’s clear that the skills, experience and knowledge will vary as across roles. There are some common things we can look at though, including:

  • Industry skills frameworks.
  • Formal certifications.
  • Other skills and knowledge.

It’s quite common to talk about T-shaped individuals, as they grow out of their domain expertise and gain some breadth. An Architect really does need to be more than T-shaped. They need to know a little bit about a lot of things – to be comb-shaped. If it’s not immediately clear what I mean, imagine a comb, with each tooth representing some knowledge on a different topic.

Skills Framework for the Information Age (SFIA)

Skills Framework for the Information Age (SFIA) claims to be “the global skills and competency framework for a digital world”. I’m not a fan. In my opinion, it’s overly wordy and feels like it was designed by committee. It’s also true that part of the reason I chose to leave a previous employer was a decision about SFIA grading, so I may be bitter.

My current employer also uses SFIA, and I can see the advantages when selling into the UK public sector. And I do have to concede that the SFIA skills definitions are actually useful when defining Solution Architect and Enterprise Architect roles:

It’s interesting that Enterprise and Business Architecture is labelled STPL. Perhaps it was called something like Strategic Planning in the past? That would be very appropriate (although Strategic Planning is labelled ITSP… so who knows).

There are other skills that may be useful for an architect. Candidates include:

And, depending on the organisation (e.g. working for a service provider, rather than in-house), maybe Consultancy (CNSL) too.

But this is where SFIA falls down. It’s so broad and encompassing that we don’t know where to stop: IT Management (ITMG)? Innovation (INOV)? Information Security (SCTY)? We could spend forever assessing people against many skills, but does it really move us forwards?

What SFIA does though, is provide a reference for what these terms mean and some pointers of what to expect at different levels.

Digital, Data and Technology (DDaT) Professional Capability Framework

Because we can never have too many standards, the UK Government came up with another framework for defining roles and the skills that are needed to perform them. That framework is known as DDaT – the Digital, Data and Technology Professional Capability Framework. Unlike, SFIA, DDaT is quite light, but possibly more relevant to the “digital” world.

DDaT doesn’t define a Solution Architect or an Enterprise Architect. Instead, it further muddies the water by defining various levels of Technical Architect, as well as Data Architect, Network Architect, and Security Architect. It also has a role of Technical Specialist Architect which seems to be some kind of ill-defined catch-all. I would suggest that the DDaT Technical Specialist Architect is some sort of specialist and probably not an Architect!

The “value” of certifications

Certifications are not everything, but they can help demonstrate having achieved a certain level of knowledge/experience. It’s worth noting that certifications are important to managed service partners as they are a factor in the partner competencies that a company holds. For some roles, they may also be important at an individual level, but they become less so as we tread the Architect development path.

Any technical certifications required for an architecture role will depend on context. The team I lead works predominantly with clients who have significant investments in Microsoft technology. For this reason, I ask every Architect (at all levels) to study for and pass all of the Microsoft Fundamentals series of exams.

At the time of writing there are six exams:

A seventh exam is in beta:

Some team members may have other certifications, but this is the base level. If I led an architecture practice working with clients who had a different focus, the list might have been focused on Amazon Web Services (AWS) or another technology stack entirely.

It’s also helpful to have awareness of competing technologies. In my case, I want the Microsoft-focused Architects to also have a foundational knowledge of AWS. That’s why I became an AWS Certified Cloud Practitioner (CCP).

But this is where the technical list ends. There is a Microsoft certification named Microsoft Azure Solutions Architect Expert but I consider it to be an oxymoron. It is my experience that the exams that lead to the award of this certification focus too much on detailed knowledge of Azure (the expert part) and have very little to do with architecture. They have breadth and depth within a single domain and in order to maintain the knowledge, it would be necessary to spend a lot of time working with the technology. That is certainly valuable in a technical role but it is not solution architecture (as discussed in my previous post).

Whilst the BCS has some examples of solution architecture certifications, they require attendance of formal training, which drives up the cost considerably. In fairness, there is a self-study option but it has no published learning path – just a reading list. Aside from these, I’ve struggled to identify good solution architecture certifications (I’m open to suggestions) but there is lots of reading that can be done.

One such area is around enterprise integration patterns but it’s worth absorbing the contents of the major cloud providers’ Architecture Centers too:

It’s also worth gaining some experience in other domains – for example, IT Service Management. This is why I have included ITIL Foundation certification on the development path for my team. I’m also considering whether a Business Analysis certification might be worthwhile, as well as knowledge of something like Lean Six Sigma.

And then there’s knowledge of Enterprise Architecture frameworks. It’s now 9 years since I took my TOGAF exam and I’ve not really had much opportunity to deploy that knowledge. Far more useful has been building out a set of artefacts around Svyatoslav Kotusev (@Kotusev)’s Enterprise Architecture on a Page.

I was also a Chartered IT Professional (CITP) for a while. Unfortunately, I found that it was not recognised or required by clients and it offered few, if any, benefits. It cost me quite a lot (both to become certified and for the ongoing fees). I couldn’t justify it to myself, so why expect my employer to pay? For that reason, I let it lapse.

It’s probably clear by now that I have mixed feelings about the value of certification for Architects. It can certainly help in some areas and it can demonstrate some knowledge (literally, getting the badge). But, for a Solution or Enterprise Architect, I’d be more interested to hear about their methods and approaches than the certifications they hold.

Other skills and knowledge

Soft skills are critical to success as an Architect and these are wide-ranging. First on the list is excellent written and verbal communication skills. The Architect needs to be able to present confidently, to a wide audience – both technical and non-technical. They need to forge relationships, manage stakeholders and exercise powers of persuasion and influence. They also need to be commercially aware. There’s a really good list of soft skills for architects in this post by Arnon Rotem-gal-oz (@arnonrgo). Arnon’s post is thirteen years old now but seems to have stood the test of time. In it, he outlines six key areas:

  • Leadership: acting as a technical manager for a project, influencing, guiding and directing others (who are often not direct reports) towards the same shared vision.
  • Systems thinking: understanding the “big picture” as well as the interdependence and interactions between components – how they operate independently and as a whole.
  • Strategic thinking: understanding the context that the solution sits within – how it supports the organisation’s goals and meets different stakeholders’ needs – balancing these needs to create a robust solution.
  • Organisational politics: Architects are logical thinkers – their decision making is based on analysing a set of options and picking the best one – except that in any organisation there will be other factors that apply non-rational influences to the decision making processes.
  • Communications: I’ve mentioned this already, but I cannot understate its importance. It’s not just about writing and presenting too – storytelling and negotiation are also key.
  • Human relations: covering team dynamics (how the team behaves at different stages of development), personal dynamics (motivations and personality types) and pragmatism (recognising when to let others have their way).

When I was writing this, I asked Matt Ballantine @Ballantine70 for his input. Matt reminded me of a post he wrote about CIO traits you won’t see on a job spec: curiosity; humility; and empathy. These are just as relevant to an Architect.

We need the curiosity to explore new things – not just new technologies but also new ways of doing business. Question why things are done as they are. What if we changed this? Could a new process help there? Could technology replace this manual process? What about our business partners and the way we integrate with them? Do the services we provide meet the needs of our end customers?

Humility is important too. The point is that the Architect is not an expert. They know a lot and they know how to put the pieces together – or if not, they can work out an approach. But it’s fine to say “I don’t know” sometimes. Actually, say “I don’t know but I have an idea how to find out” – and don’t do it too often. A little humility is good, but not so much that it calls your ability into doubt.

Empathy is essential. Understand the impact that what you’re doing has on others. Maybe the reason they are resistant to the change you want to implement is that they are concerned about the impact. Try to see things from other perspectives: is there another way to do it? Can we change something to make it more acceptable?

Back in 2017, I wrote about people change management and the ADKAR model. We need to understand people’s motivations in order to drive successful changes. Take them on a journey and help them to adapt. As Matt says in his post:

“If you are going to be successful in delivering new things, you have to be able to manage the balance of changing technologies and changing people’s behaviours.”

Ideal CIO Personality Traits, Matt Ballantine

Creating a development path

So I’ve come up with a huge shopping list of skills for our “comb-shaped” Architect and, clearly, they won’t all appear overnight. It may be useful to think about architecture skills in the form of a development path.

The first thing to understand is where we’re coming from. What skills does the person who wants to be an Architect already possess? Have they got experience in another role that could be relevant – perhaps they’ve already worked in IT Service, or Project Management, or as a Business Analyst?

Once you know the starting point, look at the target. Define the skills and experience that are needed, identify the gaps, and plan to fill them.

There’s a common misconception that Architects need to be über-technical but I would say not. At this point I should say this is not my first rodeo. (I have been burned by this point on Twitter in the past). Some people will argue that domain knowledge is needed – and that is true, but not at a deep level. And technology can be learned.

In my experience, some Architects can find it difficult to extract themselves from technology. Whereas taking someone from a different discipline (such as Business Analysis or Technical Project Management) and training them to understand how the parts fit together can work well.

What should the development path include? I’d suggest that there should be a mixture of things, but it could be something like this:

Technical Architect

A Technical Architect has broad domain knowledge. For example a Software Architect should look to develop an understanding of software development tools, methods and approaches.

Their experience may expand across multiple industries/market sectors.

They may have expertise in one technology stack (e.g. Microsoft .NET or Java) but they should be actively looking to increase their breadth and this will necessarily impact their depth of knowledge.

They should be able to communicate concepts and ideas to technical and non-technical stakeholders in a manner that’s easily understood, and they should understand the impact of their part of the solution on others.

Solution Architect

Able to guide the design and development of solutions that meet current and future business needs, eliciting requirements and determining the necessary logical components to create a solution.

A Solution Architect will take account of relevant architectures, strategies, policies, standards and practices. They will also ensure that existing and planned solution components remain compatible.

They will have experience across multiple domains and, normally, experience across multiple industries/sectors.

They will have excellent written and verbal communications skills. They will be able to present complex information, clearly, to both technical and non-technical audiences. They should demonstrate many of the soft skills discussed above.

They may also have experience of IT Service Management, Business Analysis or another discipline.

Enterprise Architect

Able to create and maintain business and enterprise architectures including the key principles, methods and models that describe the organisation’s future state, and that enable its evolution. These architectures support the formation of the constraints, standards and guiding principles necessary to define, assure and govern the evolution, and so facilitate change in the organisation’s structure, business processes, systems and infrastructure in order to achieve a predictable transition to the intended state.

An Enterprise Architect will interpret business goals and drivers; and translate business strategy and objectives into an “operating model”. This may include: the strategic assessment of current capabilities; the identification of required changes in capabilities; and the description of relationships between people, organisation, service, process, data, information, technology and the external environment.

An EA will have experience with one or more EA frameworks and will regularly make use of associated artefacts.

They should have excellent leadership skills, and should be able to inspire people in transforming the organisation to move to the target operating model. They must be comfortable in discussions with the C-Suite. To do this, they will need a complete toolkit of soft skills and the ability to deploy them appropriately.

In conclusion…

I hope this (rather long) post has given some insight into some of the skills that may be useful for a career in (IT) architecture and how to develop them.

Please let me know your thoughts – especially if you know of resources that can be useful to others who are developing skills as an architect.

Thanks to Matt Ballantine for his help in collecting my thoughts and ideas into something that almost flows (even if it is a bit long for a blog post).

Featured image by Crisco 1492 from Wikimedia Commons, licenced under a Creative Commons Attribution-Share Alike 4.0 International licence (CC BY-SA 4.0).

4 thoughts on “Developing IT architecture skills

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.