Interview with a Software Architect

I’ve interviewed quite a number of imc colleagues about what exactly their job involves. I’ve put myself in the shoes of software developers, taken a peek behind the scenes in product management, and quizzed colleagues from marketing.

But I’ve never encountered anything as complex as what my colleague Eric Andre does for a living. Eric is a software architect, responsible for the imc Learning Management System (LMS). In our interview, he told me what Connect Four and his job have in common, how he trained as a software architect, and what the distinction between happiness and joy has to do with his work.

To understand what a software architect does, you first need to understand the function of architecture in software. Architecture refers to the fundamental way in which an entire system is organized – the basic framework. It specifies both the individual components that make up the system and the relationships, or dependencies, that exist between them.

Hence building a house is an apt metaphor. When you’re planning a house, there are certain things you must specify clearly at the outset. You can leave room for future additions, obviously, but if, for example, you want to be able to add another level at some point, you’ll need to allow for that when planning the foundations.

Software is similar in that sense. On the one hand, it must be flexible and open to change rather than static and ossified. But on the other, certain limits and properties must be maintained in the system at all times.

Connect Four is also a good metaphor. Here, architecture is like the blue grid of the game: it provides a structure within which the individual tokens are flexibly arranged and re-arranged. But it only works if the grid is designed to support this.

Yes, that’s part of it. But I also have to make decisions very early on as to what might be important later on. That’s always a bit like gazing into a crystal ball. But with software architecture, it’s also like a house: if everything is working properly, you don’t give it a second thought. If it’s well planned, there won’t be any problems up front.

But planning doesn’t end with the initial build. It’s an ongoing process. It costs time and money, with no immediately obvious benefits. But if you don’t plan, and you just keep on building, then sooner or later things can get really expensive. There’s a great quote from Brian Foote that sums it up beautifully: “If you think good architecture is expensive, try bad architecture!”

I usually get up fairly early, sometime between six and seven, and go running for an hour. Then I have a coffee, preferably outside in the garden. That’s when I start thinking about my day. I have a not to-do list, and every day I jot down what I want to achieve and how I intend to go about it. In doing so, I always have our roadmap in the back of my mind.

Most mornings, work starts with our team meeting, with me generally pacing back and forth. I prefer to work standing up anyway, and I’m always moving around because I always have a lot to think through, and movement helps me order my thoughts.

In the late afternoon, I often go for an hour’s walk or do some gardening, after which I go back to my (standing) desk. My working day ends once I’ve done everything I set out to do that day. This flexibility and the freedom to switch between periods of high intensity and relaxation is very important to me.

Good software architecture demands an incredible amount of time and effort. And even then, sometimes you just have to accept that what you’ve come up with won’t work, and that you have to tear it up and start again. Only when I’ve thought everything through in the minutest detail and looked at it again and again from every angle do I know that I have given it enough thought.

That’s when the real work begins and I start defining processes and process flows, document requirements, and talk to my team, the developers and other teams. That might sound simple, but believe me, there are a lot of people and departments involved. The Executive Board, too, needs to sign off because the architecture affects the entire system.

Not through any classic apprenticeship or any one course of study. There are usually various certificates and modules involved. In most cases, including mine, you end up in this role at some point after starting out in software development. Software developers progress through various stages from junior to senior, at which point career paths branch off in various directions and you’re referred to as an individual contributor.

If you want to continue along the hands-on technical career path, you can work your way up to fellow engineer. Alternatively, if you prefer a management role, your career and further development options range from engineering manager all the way up to CTO. Or you can go into software architecture. The journey probably varies from company to company and industry to industry. But ultimately you progress from being a software developer to being an architect who must learn to delegate some of their previous responsibilities as a developer.

These days, there are various kinds of software architect, and each has a different focus. For example, there are enterprise architects, who are responsible for verifying that the organisation’s IT strategy is aligned with its mission. It’s their job to analyse both business properties and the external environment and to define all business needs.

Then there are solution architects, whose task is to evaluate all business needs and develop solutions in the form of products or services. They are the interface between business analysts and IT experts.

And finally, there are domain – or technical – architects, who mostly work as part of a team and tend to specialize in one particular technology. They can also work as technical project managers. These software architects work collaboratively to ensure the overall system has the flexibility, scalability and security required in order to meet business needs.

Adaptability, the ability to transfer and apply knowledge to new areas, and analytical skills. I need to be able to familiarise myself with new subject areas and problems very quickly and transfer my existing knowledge to new situations.

For instance, I’m not the best developer by any stretch of the imagination, but I know enough to be able to understand problems and quickly get a handle on the issues involved. Good communication skills are also very important, as I deal with a wide range of stakeholders.

I used to work at a large US corporation, and things were done very differently there in several respects. For example, decision-making processes are much shorter there, and people are more inclined just to give something a try. Here in Germany, there’s generally a lot more discussion and planning before something gets implemented.

I’m very happy with the overall situation here at imc. The people here are very open and honest. That came across right from the outset, during my job interview and the onboarding process. But I also like the way people deal with one another. And then there are all those in-house events and knowledge-transfer opportunities.

I also really like our approach to design here – it’s all so cohesive. Plus, I like the painstaking attention to detail here, and the fact that people notice when you go the extra mile. It’s not all strait-laced and serious either – people know how to have a bit of a laugh without being puerile. I suppose it’s a little like working for a start-up, albeit one with more structure.

Also, in my role, I’m able to work with a very wide range of information and levers, and imc always gives me really good support in that regard.

Professionally, several. At a personal, human level, the actor Keanu Reeves springs to mind. Despite his immense success, he remains grounded, uses public transport and stands up for others. I find that truly remarkable. Amid all the rapid changes of our modern world, it shows that there are still immutable principles and values that we all share, or at least should share.

Indeed! And that wraps things up nicely. Thank you for your time, Eric. Here’s wishing you continued joy in your work!

What Connect Four and Software Architecture Have in Common

Eric Andre

Hi Eric, thanks for making time for us today! I suspect your job description will be pretty meaningless to most laypeople. How would you describe your job to your grandparents?

Well, that actually sounds pretty simple. Can you explain it a bit further?

So, in other words, you have to plan something that doesn’t even exist yet?

Sounds like rather a lot of brainwork. What does your average working day look like?

So a large part of your work consists of planning. How do you know when a plan is finished and the architecture is ready for implementation? And what happens next?

How does one actually become a software architect?

And what is your specialism?

What key skills does your job require?

In what respects does imc differ from other employers?

Now let's go on with some random, personal questions. If you could have your time again, would you still choose to work as a software architect?

Please complete the following phrase: For me, digitalisation means...

What do your colleagues value most about you?

Do you have any role models, professionally or personally?

Living the dream as Hosting Engineer

Conductors of the Software Orchestra