Two key traits of an Effective Software Architect and how to maintain them

An effective software architect has many traits. In a 2006 article titled “Characteristics of a software architect”, Peter Eeles covers the following characteristics:

• The architect is a technical leader
• The architect understands the software development process
• The architect has knowledge of the business domain
• The architect has technology knowledge
• The architect has design skills
• The architect has programming skills
• The architect is a good communicator
• The architect makes decisions
• The architect is aware of organizational politics
• The architect is a negotiator

Mark Richards & Neal Ford have a section on the “Expectations of an Architect” in their recent book on the “Fundamentals of Software Architecture — An Engineering Approach” that I have just started to read. The authors cover a similar list to the one above that Peter Eeles covered.

Kyle Gene Brown, Darcy Lalor, and myself had shared our thoughts on “The Role of an Agile Architect” in an earlier article. We talked about the role of the architect being that of a boundary setter. The architect sets up fences within which the teams work. We discussed the following important traits of the agile architect regardless of architectural discipline:

• Architects need to be visionaries
• Architects need to act as mediators
• Architects need to have strong communication skills
• Architects must be hands-on

A couple of recent events have prompted me to write this article. Firstly, when I published my article on “Launching and Scaling a Transformation Organization”, one of the technical leads from my client where I had led a large transformation as Chief Architect reached out to me and reminded me that one of the key reasons things worked out well on that transformation project was because the architects were hands-on.

And more recently as I serve in a Chief Architect capacity on another large project, I find that architects that are focused in one technology and don’t have technical breadth come up with architectures that leverage that one technology they are an expert in even if there are several far better solutions using other available technologies.

As a result, I am writing this article to talk about the need for architects to have technical breadth and to be hands on. I also share what I personally do to keep up with technology as it continues to move at a rapid pace. I am in no way suggesting that these are the two most important traits. There are many other traits and it would be difficult to order these in terms of importance. But in my opinion, these are two key traits.

Architects must have technical breadth

“We need to avoid building solutions grounded in the expertise of the team you ask. For example, if you want to build an API and you ask the Pega team to build it, you will get a Pega implemented API. If you ask the Kafka team to build an API, you will get the best API built on Kafka you can imagine. If you ask the mainframe team to build an API, they will build you the best COBOL API you can imagine. This is why architects need Technical breadth to be able to best guide the technical team on implementation choices.” — Mike Nitsopoulos, SVP Strategy & Innovation, Retail Banking Technology, PNC Bank

When I joined IBM for the first time as an intern in 1992 while I was studying Computer Engineering at the University of Toronto, I joined a small IBM team as a developer. I learnt how to develop software that ran on the mainframe and I thoroughly enjoyed it. I loved writing code back then and I still do today. At that time I really did think that I was going to be a mainframe developer for my entire career. I enjoyed it that much. I learnt very quickly that technology moved at a really fast pace and I had to keep up. As IBM transformed itself as a company, I had to do the same. I went roughly from mainframe developer to client-server C/C++ developer to Java/JEE developer. Yes, I have omitted several to keep things simple for illustrative purposes. Along the way I got to experience a lot of varying Architectural Styles and a lot of different technologies. At some point I started to do architecture work. I started to play roles that you would characterize as a Lead Developer, Technical Lead, and Application Architect.

I find myself grateful for all those experiences. They gave me the technical breadth that enables me to think as an architect today and to consider technical options that I wouldn’t even be aware of. This is why technical breadth is absolutely necessary to be an effective software architect. You just have to know what’s out there. You don’t need to be an expert in it. You just have to know it exists and understand it at a high level to know when to use it.

Transforming myself from one technology to another taught me how to always keep learning and how to keep my finger on the pulse. This is important as I’ll need to continually move to the next big thing to remain relevant to my clients and have a fulfilling career.

We commonly refer to T-shaped skills. The vertical bar represents depth. This is the subject area that an individual has deep skills in. The horizontal bar is the many subject areas that the individual knows a little bit (just enough) about i.e. the breadth.

“You can’t get to breadth if you don’t first have depth. Architects aren’t “born”, you “grow” into one. It’s the classic architecture “T”. Depth in one discipline and breadth across a variety of others.” — Mike Nitsopoulos, SVP Strategy & Innovation, Retail Banking Technology, PNC Bank

I once watched a video by Andrew Ng, co-founder of landing.ai and Coursera, a professor at Stanford, and formerly led Google Brain, where he discussed the T-shape individual in AI. To be successful Machine Learning engineers you needed to have a broad understanding of many different topics in ML/AI and a deep understanding of the 1 or 2 areas that you focused on. You can find Andrew’s discussion on this topic on YouTube.

Andrew suggests that to build breadth you can do it by taking courses and reading. For depth, he suggests hand-on project work. I totally agree with this.

Architects need to be hands-on

“Architects need to be hands-on. It’s the only way to prototype and remediate the “high risk” areas of your architecture. It also builds rapport and respect with the dev team because you can get them in a room and instill confidence in your architecture when you can show them the path forward for those high risk areas because you rolled up your sleeves and prototyped it out on your laptop.” — Mike Nitsopoulos, SVP Strategy & Innovation, Retail Banking Technology, PNC Bank

A few years ago, I had my first encounter with Event Driven Architecture. We were going to leverage Kafka as the event backbone. I already had a high-level understanding of Kafka. One of the first things I did was install Kafka, install Zookeeper, and get it all running on my laptop. I could have used a Cloud provider and provisioned a fully managed Kafka service but decided that I will likely run into issues installing it myself and will learn from them as I work to resolve them. I used the Command Line Interface (CLI) to create a topic. I used the console producer and consumer to produce and consume messages from the topic. I then started my IDE and wrote a Java producer, consumer, and steaming application. I experimented with Kafka security, Kerberos, ACLs, etc.

Being hands on with the technologies being used on my project enables me to have deep technical conversations with the developers. I still have to have conversations with the business stakeholders, the enterprise architects, the client’s chief architect, their CTO, their CIO, etc. Don’t tell them but I enjoy the deep technical conversations with the developers more. As a software architect, me and my team of architects work for the developers. If we are not helping the developers every day and making it easier for them to deliver great software products that solve real problems, we are not doing our job well.

By being hands on, I put myself in a position that enables me to have good design sessions with the developers, to spike areas of technical risk, to roll up my sleeves and work with developers to debug bugs/issues and earns me credibility with the developers.

Attaining and maintaining breadth

As the title of this section suggests, technical breadth needs to be maintained. Technology changes at such a fast pace and you need to keep up and maintain your technical of knowledge. Here are a few suggestions for you to try. These work for me but I can’t guarantee that they will work for you. Give them a try and let me know. If you have techniques that work for you, please share using comments.

1. Keep a list — start by creating a list of the technologies that you want/need to know a little bit about. I like lists and like crossing things off it even more. So what do you put on your list? Here are some suggestions:

• Start with technologies you need for projects you are on. These should be a priority to get through.
• As mentioned earlier, architects need to be visionaries. What technologies do you think will be important in the next few months, in the next year, in the next three years? Add a few of those.
• There are many resources available that I leverage to create my own list. If I was to recommend just one, it would be the ThoughtWorks Technology Radar. The teak at ThoughtWorks do an amazing job with this and it is one of my favorite resources to build my own list. The Radar is categorized into 4 sections; Techniques, Tools, Platforms, and Languages & Frameworks. Each technology or technique that make one of these categories is further put in one of four buckets; Adopt, Trial, Assess, and Hold. I suggest picking a couple from each category and from each bucket. You might feel that you don’t need to look at the Hold bucket. What I have found is that it is important to at least understand why the ThoughtWorks team suggested a Hold. This will give you a great list to start with. There are several other resources that I do use but the ThoughtWorks Technology Radar is a great one to start with.

Here is what the ThoughtWorks Radar looks like on one page:

Source: https://assets.thoughtworks.com/assets/technology-radar-vol-22-en.pdf

• The team at ThoughtWorks has been kind enough to Open Source their tooling to build your own radar. It is as simple as filling out a spreadsheet. You use Google Sheet to enter the data for your radar, go to a web page and submit the URL to the Google Sheet. What you get back is your Radar visualization that is fully interactive. Now keep in mind that this data of yours is public. If you have a problem with that, you can download the source codeand host the tool yourself.
• The list is not fixed. Be sure to continuously revise it. Add new items you have discovered, heard about from a colleague, or run into on a project. You can also remove items that you feel no longer need to be on your list.

2. Do research, read, listen, and watch — now that you have your list, you need to start to spend time on each item on the list. You need to do this as open as you can. I suggest you work on one item a week. That gives you enough time to do some research, read a few blog articles, watch a few YouTube videos, and maybe do the first few sections of an online course. I find Medium to be a good source for blog articles. There are many conferences that make their recordings available on YouTube. If your company has a subscription to O’Reilly I find that is a really good resource.

Remaining hands on

I want to say that all software architects were at some point developers. I really hope that is true. So, we were all hands on at some point. I find that far too many architects are no longer hands on. One of the challenges in our industry is that many of our clients do not want an architect to write code on their project because in almost all cases their billable rate is higher in many situations much higher than that of the developers. Architects end up losing touch with reality if I can phrase it that way.

I have always managed to remain hands on, but it has been because I put conscious effort towards it. On client projects there is code I write that does go to production and that is a thrill for me these days. There is lot of code I write that is a technical spike to prove something out that does not go to production. In addition to that I am always trying new technologies to learn and code on my own time to try new things out. One of the areas that I am interested in recently in Machine Learning/Deep Learning. As such, I am spending my free time learning and coding in this area. I taught myself Python and learning TensorFlow and PyTorch.

1. Write code every week — I try to write some code every week even if it is following a simple tutorial. Most of the times I spend my time trying different patterns to solve problems I am having on a project. Other times I am experimenting with technologies that have nothing to do with my day job. I am just passionate about them and enjoy experimenting with them. For example, Machine Learning and Deep Learning.
2. Pair Program with a developer — on most of my projects we Pair Program. I look for a day on which I have a 4 to 5 hour block with no meetings and I ask one of the developers if I can pair with them. I’ve done this a few times and find it very fulfilling and I learn a lot. I do hope they find me helpful in some way as well.

I hope you found this a worthwhile read. If you have techniques that work for you on attaining/maintaining technical breadth or how to always keep coding, please share them via comments.

Always keep learning and coding!

Thanks to Mike Nitsopoulos for an extremely helpful review and insightful comments on this article.

References

1. P. Eeles, “Characteristics of a software architect”, Ibm.com, 2020. [Online]. Available: https://www.ibm.com/developerworks/rational/library/mar06/eeles/index.html. [Accessed: 31- May- 2020]
2. “Fundamentals of Software Architecture Book”, Thoughtworks.com, 2020. [Online]. Available: https://www.thoughtworks.com/books/fundamentals-of-software-architecture. [Accessed: 01- Jun- 2020]
3. K. Brown, D. Lalor and S. Daya, “The Role of an Agile Architect”, Medium, 2020. [Online]. Available: https://medium.com/@kylegenebrown/the-role-of-an-agile-architect-ead1e114c8f2. [Accessed: 01- Jun- 2020]
4. A. Ng, “Stanford CS230: Deep Learning | Autumn 2018 | Lecture 8 — Career Advice / Reading Research Papers”, YouTube, 2020. [Online]. Available: https://www.youtube.com/watch?v=733m6qBH-jI. [Accessed: 02- Jun- 2020]
5. “Technology Radar | An opinionated guide to technology frontiers | ThoughtWorks”, Thoughtworks.com, 2020. [Online]. Available: https://www.thoughtworks.com/radar. [Accessed: 02- Jun- 2020]
6. “How to build your Interactive Radar | ThoughtWorks”, Thoughtworks.com, 2020. [Online]. Available: https://www.thoughtworks.com/radar/how-to-byor. [Accessed: 02- Jun- 2020]
7. “GitHub repo for thoughtworks/build-your-own-radar”, GitHub, 2020. [Online]. Available: https://github.com/thoughtworks/build-your-own-radar. [Accessed: 02- Jun- 2020]