Software architects: Two traits that are key to success

An effective software architect has many traits. For example, in Characteristics of a software architect, Peter Eeles says:

• 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 and Neal Ford have a section on the expectations of an architect in their book the Fundamentals of Software Architecture. Their criteria is similar to Peter Eeles' list.

In The role of an agile architect, Kyle Gene Brown, Darcy Lalor, and I talked about the architect's role 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 their 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. First, after I published Launching and scaling a transformation organization, one of the technical leads from a client where I led a large transformation as chief architect reached out 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, I've found that architects who don't have technical breadth (that is, they are focused on one technology) create architectures that leverage the technology where they are an expert, even if there are far better solutions using other technologies.

[ For more insights on building your career, read 10 guides to advance your enterprise architect career. ]

Architects need to have technical breadth and be hands-on. They also need to keep up with technology as it continues to move rapidly. I not suggesting that these are the two most important traits for enterprise architects. There are many other traits, and it would be difficult to order them 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 as an intern in 1992 while studying computer engineering at the University of Toronto, I joined a small IBM team as a developer. I learned how to develop software that ran on the mainframe, and I thoroughly enjoyed it. I loved writing code back then, and I still do.

At that time, I really thought that I would be a mainframe developer for my entire career; I enjoyed it that much. I quickly learned that technology moves at a really fast pace, and I had to keep up. As IBM transformed, I had to do the same. I went roughly from mainframe developer to client-server C/C++ developer to Java/JEE developer. Along the way, I got to experience various architectural styles and a lot of different technologies. At some point, I started to do architecture work. I played roles that you would characterize as a lead developer, technical lead, and application architect.

I am 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 be aware of. This is why technical breadth is absolutely necessary to be an effective software architect. You 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.

Migrating from one technology to another taught me how to keep learning and keep my finger on the pulse. This is important, as I 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 (demonstrated in the image below). 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, 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

In 2018, Andrew Ng, who co-founded landing.ai and Coursera, is an adjunct professor at Stanford, and formerly led Google Brain, delivered a lecture about the T-shape individual in artificial intelligence (AI). To be a successful machine learning (ML) engineer, he says, you need to have a broad understanding of many different topics in ML and AI and a deep understanding of the one or two areas that you focused on.

Image

Andrew suggests (and I agree) that you can do this by taking courses and reading to build breadth. For depth, he suggests hands-on project work.

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

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 and Zookeeper and get it all running on my laptop. I could have used a cloud provider and provisioned a fully managed Kafka service, but I decided that I would learn more by installing it myself and working to resolve the issues I was likely to encounter.

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 integrated development environment (IDE) and wrote a Java producer, consumer, and steaming application. I experimented with Kafka security, Kerberos, access-control lists (ACLs), and so on.

[ Read Culture matters: The IT executive's guide to building open teams. ]

Being hands-on with the technologies in my projects enables me to have deep technical conversations with the developers. I still have to have conversations with the business stakeholders, enterprise architects, client chief architect, CTO, CIO, and more. Don't tell them, but I enjoy the deep technical conversations with the developers more. As a software architect, my team of architects and I 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, spike areas of technical risk, and roll up my sleeves working with developers to debug bugs and issues, which earns credibility with the developers.

How to achieve and maintain breadth

Technical breadth can't only be achieved; it has to be maintained. Technology changes quickly, and you need to keep your knowledge up to date. Here are a few suggestions that work for me and might help you.

1. Keep a list

Start by creating a list of the technologies you want or need to know a little bit about. I like making lists and crossing things off them even more. So what do you put on your list? Here are some suggestions:

• Start with the technologies you need for projects you are on. These should be a priority to get through.
• 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.
• I use many resources to create my lists. If I were to recommend just one, it would be the ThoughtWorks Technology Radar. The team at ThoughtWorks does an amazing job with this, and it is one of my favorite resources for building a list. They categorize the Technology Radar into four sections: Techniques, Tools, Platforms, and Languages & Frameworks. Each technology or technique in a category gets put in one of four buckets: Adopt, Trial, Assess, and Hold. I suggest picking a couple from each category and each bucket. You might feel you don't need to look at the Hold bucket, but I have found it important to understand why the ThoughtWorks team suggested a Hold. This will give you a great list to start with. I use several other resources, but the ThoughtWorks Technology Radar is a great one to start with.
  
  Here is what the ThoughtWorks Radar looks like:

Image

• 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 a Google Sheet to enter the data for your radar, go to a web page and submit the URL to the Google Sheet. You get back your fully interactive radar visualization. Keep in mind that the data you put in the web tool is public. Alternatively, you can download the source code and host the tool yourself.
• The list is not fixed. Be sure to revise it continuously. Add new items you discover, hear 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, spend time on each item. Do this as openly as you can. Working on one item a week gives you enough time to do some research, read a few blog articles, watch a few YouTube videos (many conferences post recordings there), and maybe do the first few sections of an online course.

How to be hands-on

I believe all software architects were, at some point, developers. I really hope that is true. So, we were all hands-on at some point, but I find that 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 projects. In almost all cases, an architect's billable rate is higher (in many situations, much higher) than a developer's. As a result, architects end up losing touch with reality, if I can phrase it that way.

I have always remained hands-on, but it has been because I put conscious effort into it. On client projects, I write code that goes to production, which is a thrill for me these days. I write a lot of code that is a technical spike to prove something out that does not go to production. In addition, I am always trying new technologies to learn, and I code on my own time to try new things out.

Here are some other tips you can try.

1. Write code every week

I try to write some code every week, even if I'm just following a simple tutorial. Most of the time, 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.

One of the areas I have recently been interested in is machine learning and deep learning. I am spending my free time learning and coding in this area. I taught myself Python and learned TensorFlow and PyTorch.

2. Pair program with a developer

On most of my projects, I pair program. I look for a day when I have a four- to five-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, learning a lot. I hope they find me helpful in some way, as well.

No matter what, if you want to grow in your career as an enterprise architect, always keep learning and coding!

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

This article originally appeared on Medium and is republished with permission.