What Connect Four and Software Architecture Have in Common
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.
Job | Software Architect
Working in | Saarbruecken, Germany
Worked at imc since | 2021
Super power | Transfering knowledge to new situations
Favourite food | Pizza
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?
Hi Nadine, the pleasure’s all mine. I would describe my job to my grandparents simply by saying that my boss gives me a whole lot of brightly coloured Lego bricks which I then put together to make something resembling a house.
Well, that actually sounds pretty simple. Can you explain it a bit further?
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.
So, in other words, you have to plan something that doesn’t even exist yet?
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!”
Sounds like rather a lot of brainwork. What does your average working day look like?
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.
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?
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.
How does one actually become a software architect?
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.
And what is your specialism?
I tend to see myself as a solution architect who doubles as a domain architect from time to time. The distinction is somewhat fluid, which is due to our organisational structure. My specialism is in platform architecture. I distribute systems and ensure their interoperability, and I’m passionate about service orchestration and choreography within distributed and reactive service-oriented architectures.
What key skills does your job require?
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.
In what respects does imc differ from other employers?
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.
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?
Yes, in a heartbeat. I love the challenge – it gives me great joy. And I believe that if you do something that gives you joy, then that’s the key to happiness. If something fills you with joy, you cannot help but be happy.
Please complete the following phrase: For me, digitalisation means...
...that you can’t make a bad analogue process better simply by digitalising it.
What do your colleagues value most about you?
They value my willingness to help and my openness, and also my direct manner. At least, I hope they do!
Do you have any role models, professionally or personally?
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!
Living the dream as Hosting Engineer
Hosting is a male domain? Our interview partner Suwhathi proves this wrong! She reveals how she became a Hosting Engineer at imc and what she think about supposed male domains.
Conductors of the Software Orchestra
Conductors of the Software Orchestra: That is how Product Manager Lia from Sibiu explains her job. Find out more in the interview.
Would you like to know more about imc as an employer? Then take a look at our career section, maybe there is a suitable position for you.
We are also always happy to receive unsolicited applications!
I have been working in the Marketing & Communication Team at imc since March 2019.
Communication, creating unique content and social media are my passion.
"One can not not communicate" - Paul Watzlawik.
To explain complex content in an understandable way and thus make the topic of e-Learning accessible to everyone is an exciting challenge every day.
Privately I love to read, play poker and travel a lot.
I am always happy to receive feedback or suggestions.