Blog • 03.09.2020

Becoming a Software Architect

Becoming a Software Architect

Software architect: a somewhat rare and coveted sub-species of programmer, known as notoriously hard to catch in the current job market. At Gofore, software architects are major players in our largest and most impactful projects. They design and implement principles and infrastructure used by thousands of people on a daily basis. And we would love to have more of them.

But as much as we like clear division of responsibilities and predictable call stack hierarchies in our codebases, we don’t see a place for them in running a modern software consulting company. Gofore has a minimal number of middle management (one, and he’s actually a bot), and our career ladder resembles rock climbing instead of a leisurely sloping path. Titles are not awarded automatically on basis of years in employment or obtaining some certificate. 

We realised that we have a puzzle to crack: how to grow new software architects at Gofore.  

“Gofore can and will offer help, tools and support for people who want to take on new responsibilities.” – Meeri 

Meeri’s story: “My first step towards my goal was to join Gofore’s mentoring program”

After working as a software developer for 10 years, half of which I’d spent at Gofore, I was ready for new challenges. I could see a clear pattern in my previous projects: my engagement was significantly higher when I had taken part in the design phase, met with the shareholders, pitched in my ideas and evaluated technologies, as opposed to projects where I had been just another pair of hands to speed up implementation. I was eager to take on more responsibilities and join larger projects with non-trivial architecture. My first step towards my goal was to join Gofore’s mentoring program in the spring of 2020, where I was paired up with Juhana. 

In the first sessions, we set our targets for the program. As the program was only a few months long, I didn’t expect to emerge as a full-fledged architect. Instead, I wanted to know where I stood and what direction I should take off to. I knew the textbook definition of software architecture, but I also wanted to hear the experiences of people who were actively practicing it. I wanted to learn what was beyond the web service patterns I had been using for the past 15 years. Most importantly, I wanted to learn what I didn’t know, so one of the first thing I asked of Juhana was to help me identify the strengths and weaknesses I had but didn’t see in myself. 

It’s often even more important to remind ourselves and others of our strengths

As important as it is to work on our weaknesses, it’s often even more important to remind ourselves and others of our strengths. I asked Juhana to remind me to share my knowledge. I expected him to maybe send me a message at some point, telling me to give a technical talk or to write a blog post. Instead, sharing my knowledge became a much more regular–and impactful–discussion point in our mentoring sessions. 

With coronavirus shutting down offices, we began our program with bi-weekly remote meetings. 

As for the content of these sessions, my initial thought was that we would draw a roadmappossibly using some formal notion I had not used since my university days–and start crossing off items. Juhana, however, had other ideas, so we set out for exploratory research, starting with the simple question of if software architecture was something I would enjoy 

Software architecture is a mix of technology and people skills

Software architecture is a mix of technology and people skills: In addition to drawing diagrams and setting up services, at Gofore we expect software architects also to be experts at defining requirements and maximizing value to clients and users. While we benefited greatly from discussing blog posts (What Kind of Animal is a Software Architect, The Path to Becoming a Software Architect), software architecture is not something you can learn just from a book. 

To explore this other side of software architecture, we studied an entirely different document: my resume. We identified the roles and responsibilities I had had in my past and current projects. We picked out past architectural work–after all, the line between developer and software architect is blurry, especially in smaller projects – and started looking for ways to verbalize this experience, forging my past experiences to pave a way into the future. 

As a result, we found plenty of opportunities to use my current skills and start building on them in my current projects. To my surprise, what benefitted me most turned out not to be an academic study of existing architectural patterns. Instead, I started bringing new value to my client by utilizing tools of software architecture in the work I was already doing. And because my work had an impact on my team, it made for a shorter feedback cycle as well as some good old-fashioned peer pressure. In the end, I was very happy that I didn’t have to take a huge leap to a new role in a new project at this time. 

“… what benefitted me most turned out not to be academic study of existing architectural patterns. Instead, I started bringing new value to my client by utilising tools of software architecture in the work I was already doing” – Meeri

My tip: “to reach your goals put them into words”

My key takeaway from the mentoring program was something very simple: The most important thing you can do to reach your goals is to put them into words and discuss them regularly. Having the mentoring sessions set in my calendar forced me to find time to do the thing we had discussed. Of course, sometimes there were urgent project tasks that took priority. 

Admittedly, we did not come up with a universal curriculum to turn developers into architects in four months or less. However, I believe that we have proved that Gofore can and will offer help, tools, and support for people who want to take on new responsibilities. 

 

Juhana’s story: “Software architecture is not something you can learn just from a book”

I’ve been working at Gofore since Dec 2019, and my professional experience in building digital services dates back to early 2006. Here at Gofore I’m working as the Capability Owner of Web Development multitasking as a Technology Consultant in key projects with several hats from Software Architect to Scrum Master and Lead Developer to name a few. I’m renewing and nurturing Gofore’s capabilities in Web Development to match the current and future needs of our clients, and to grow new scalable businesses. 

For the past decade, I’ve been involved in SMEs, growth companies, and startups as Head of Digital, VP of Software & Services, CTO, Chief Architect, Lead Developer while simultaneously undertaking all imaginable software professional roles from DevOps to Design, and from Architecture to Development, Integration, and Database administration. I often find myself working towards sharing a common understanding of the digital services at hand, either when ideating, planning, or both in their current status and what future holds. Furthermore, making proactively sure that client is heard and understood, and those important things get done and finished, effectively tying up loose ends. 

I was asked to scout out potential mentors for different tracks and decided to join in as well as a mentor as I’ve previously experienced mentoring to be an excellent way to learn and widen one’s own perspective and as a software architect, I was a suitable mentor for Meeri. 

What it is to work with software architecture and what it means to work as a software architect are very different things. As the mentoring was more from a coaching approach, I wanted to set the expectations towards having a low barrier dialog between two equals, open sharing of experiences, and therefore learn through widening our lenses by learning how to wear different hats one might say. Commitment to achieving goals set to oneself and having good open communication were some of my additional expectations for the mentoring agreement.

Fundamental structures of a software system, different development activities, paradigms and models, methodologies and frameworks, practices, tools, and standards are something that can be learned from books, but that doesn’t mean that one using them becomes necessarily a software architect and it is the same toolset for developers 

A good software architect: the backbone of an entire development organisation

Software architecture is also about being able to make fundamental choices that can be costly to change once implemented, and also about being able to communicate all of the above to all of the different stakeholders at hand. It is very much about people’s skills. How all of the above should be taken into consideration when applying these into the customer business landscape in order to find a problem-solution fit for the particular digital service or a problem domain.  

Expectations for mentoring the software architecture track weren’t set out of the blue. I strongly believe that being able to identify oneself as a software architect, it comes from understanding the rationale and decisions behind past experiences (both one’s own and others) and having the applied knowledge and knowhow suitable for the task at hand to tackle the future successfully. A compelling track record one could say. Furthermore, accompanied by an ability to be able to have a good and open dialog between different stakeholders on a level that everyone understands the matter at hand, the decisions needed to be made, and being able to reflect, iterate. A good software architect can be the backbone of an entire development organisation even without having sugarcoated title prefixes, such as principal, lead, or chief.  

“… software architect can be the backbone of an entire development organisation even without having sugarcoated title prefixes, such as principal, lead, or chief” – Juhana 

We usually have pre-determined goals for positions or roles we apply to and have thoughts about the possible road ahead of us to grow into. However, even though often these goals are thought of beforehand they tend to change while things unravel. 

Mentoring: Give value to the shared knowledge and discussion 

As a takeaway, remember to have an open mindset in your professional development journey whether it is participating in a mentoring program or through something completely different. Give value to the shared knowledge and discussion, and adjust it to your situation together, and remember that setting strict goals might not be for everyone and that pre-determined goals might not be the ones you are truly after. 

Sharing knowledge is a two-way street. Support one another in your professional growth through openly sharing your knowledge as well as learn how to turn these discussion items into action points that get followed through thus paving your path into your future role.

And one more thing. Remember to ask for feedback. 

Meeri Panula
Juhana Harmanen  

 

Goforeans participated for the first time ever to our own official mentoring program last spring. ’Official’ meaning that mentoring at Gofore has been rather unofficial and it has usually taken its form in project teams or with two colleagues talking casually, yet repeatedly, about their challenges at work.
Even though unofficial mentoring continues to be the most important form of mentoring in our company, we know that we also need structures and support. Participants gathered their thoughts and lessons learned on our blog. Get inspired! 

 

Gofore Oyj

Gofore Oyj

Do you know a perfect match? Sharing is caring