The tension between software architects and their employers

Be prepared to stand your ground

Sergey Mikhanov has written a blog entry called Why I don't believe in software architects that, along with the follow-up comments, makes for a good read. It discusses some of the ways that software architecture is typically viewed (e.g. models rather than code) along with some thoughts about how coding should be included as a part of the role. Since this site is called "Coding the Architecture" and role of a software architect talks about how coding should play a part, I'm not going to dwell on that particular aspect. What I do like about Sergey's blog entry is that it highlights the often familiar (yet rarely discussed) tension between software architects and their employer.

What about career path then? Well, I can't give any personal advice here except for the "avoid advertised 'software architect' positions". The best company will allow you to keep writing code while expanding your area of influence wider and wider into the company products at the same time. This is what really software architecture is about.

I've been fortunate in that I've retained a large hands-on element as a part of my role and I've written code on most of the development projects that I've been involved in. I'm a firm believer that you're in control of creating your own opportunities and that the reason I've remained hands-on comes down to expressing that it's a crucial part of the role. For me it's simple ... coding is essential when designing software because I need to keep my skills up to date and understand that what I'm designing will work. Plus, it's fun and I'm not worried about admitting it.

Unfortunately many organisations seem to think that coding is the easy part of the software development process, which is why they see an opportunity to save some money and let somebody else do it. They view cutting code as low-value. Tension therefore arises because there's a disconnect between the seniority of the software architect in the organisation and the low-value associated with the coding activities.

In my experience, this doesn't happen in small organisations because everybody usually has to get involved in whatever is needed. No, it's those larger organisations where the tension is greatest. I spent some time working for a medium size consulting firm where my job grade put me squarely inline with the management and heads of business units, yet I still used to write code. In some ways it was quite an achievement to be graded as a manager and write code on a daily basis, yet it often felt very uncomfortable as other managers would try to push my name into boxes on the organisational chart.

Being in this situation is tricky and only you can get yourself out of it. A number of developers/architects have been in touch to say that they've found my Why software projects fail presentation really useful as a basis for expressing to their organisations what they would like their role to be. The role of a hands-on software architect discusses the same thing in a shorter format and both have been used as the basis for "terms of reference" for software architecture roles in organisations. Whether you're in an organisation where this is happening or you're looking to move on, be clear about how you view the role of a software architect and be prepared to stand your ground.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Add a comment Send a TrackBack