Software Architects

https://www.spiraltrain.nl/architectural-design-patterns/

Is a good software architect like an octopus, forcing its tentacles into everyone’s code? How can the architect be an authority in all technologies used by a system? We discuss the age-old problem of broad vs. focused knowledge with three veteran software architects.

At some stage in every programmer’s career, there comes the time when they must decide which area they will specialise in, if any at all. But expertise is a tricky concept when it comes to making software architecture decisions.

We asked three expert software architects how they approach the problem of balancing general IT knowledge vs. technical expertise.

“Question yourself”

Gernot Starke, Software Architect: This situation is know in other disciplines too. Highly intelligent people have already investigated that issue that we need both general knowledge of a broad range of topics and we need specialised knowledge. They have invented something they call the “T Model of Education”. You have to have some broad, fundamental knowledge over a range of areas, (for example soft skills, moderation, presentation, communication, documentation, system analysis, testing, project management and so on). You need to understand all these areas just a bit. And then you need these ‘vertical columns’, you need special areas of knowledge, probably more than one. So it’s actually not a T, it’s more like an M or an E, or some other letter, [laughs] with many bars.

Nobody can be an expert in all these dimensions, then you’d have a perfect rectangle. And I don’t believe in those. But for a specific domain, let’s say medical systems, you would need some expertise in safety-critical systems, how to make systems really reliable. You probably don’t need to be an expert in high-speed data manipulation, ’cause that’s not required. Whereas when you build a webshop, if the webshop is down an hour for a day, it’s maybe not that bad. But the medical cannot be down when the doctor operates on a patient. So this is a very individual selection of topics that you have to specialise in.

And as an architect, I require a certain foundation, at least in communicative skills, and the ability to reflect on what’s missing. If you always think you know enough, you’ll never question yourself. But as an architect, if you build a new system from scratch, you don’t know all the technologies, you don’t know all the people and you have to self-reflect what area we need to build up some knowledge in.

“Move around”

Carola Lilienthal, Software Architect: What I do is, I never stay in one team. I move on from team to team. I can’t know everything, every little corner. This is impossible. So for me it’s about trust. I trust my people that work in those teams. They will tell me if there’s a problem and I have to know something. We all have to be aware that these systems are so huge, you cannot know everything. But it’s good if the architect can move around between teams, because you take knowledge with you and you can confront other teams with something they don’t know or they never thought about. This kind of disruption is a good idea.

It all depends of course on the size of the team that you have. But I think it’s very natural that people love a certain part of a system; it might be some technology or part of the domain that they become attached to. And so they tend to work alot on this area and they then become experts and the others start to give more work to them. I think this is a very natural thing that happens to all programmers.

We can help solve this problem with our teams of programmers. What we do is pair programming, we let people program together in a team of two. And this helps a lot to spread knowledge of the system among all programmers. So if we do this, I’m not afraid of having experts in areas, because they always have to take someone else along with them. This way the knowledge will spread in the team. But I think it’s impossible to avoid situations where the two people who know best about the database are on holidays. We’ll always have that problem.

“I try to ignore as much technology as possible”

Rainer Stropek, Software Architect: I don’t know if there’s a general solution to this, but I can tell you my solution.

What I try to do is whenever I see a new technology, I try to do some kind of triage. So I ask myself ‘Is this technology relevant?’ I play a bit with it. Maybe I read an article or two. And sometimes I come to the conclusion that I can completely ignore a certain piece of technology. And I try to ignore as much technology as possible, because there is so much of it. And then there are these things where I think this might be interesting in the mid to long term. And then I actively look for… let’s call them ‘playground projects’. Either I do some kind of user group meeting session where I force myself into a situation where I have to learn more about a topic. Or I write an introductory article because other people might also be interested in basic information to understand whether it’s interesting for them.

And if it really turns out that, after a bit of playing around, that this technology is really relevant for me, well then I spend more time with it. I start reading, I do some exploration projects, things like that. And with that I try to balance, as you said, the breadth (the different technologies that are out there) and the depth (of any technologies that I think are important for me or for my business life).

I can make it more concrete – for instance Java is something that I completely ignore, for years now. Not because it’s not interesting, but for me I have decided it’s not necessary. I know TypeScript, I know JavaScript, I know Node.js, I know .NET – and I can do everything I want with all of these technologies. I don’t need another one.