The software architecture role from a non-technical point of view

I ran a couple of half-day training sessions yesterday, both of which were basically cut-down versions of the full 2-day Software Architecture for Developers training course. The major difference was that both of these sessions were for non-developers such as business analysts, project managers, testers and project management office staff. Given that many of these people do, or should, work closely with software architects, I asked them what their expectations of the software architecture role were. Here's what they said.

Software architecture role

Software architecture role

I think this is fascinating, especially because their definition of the role is better than I've seen from some developers! On the subject of whether software architects should be hands-on and write code, their response was "yes, it keeps their hand in". Brilliant. :-)

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 simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: The software architecture role from a non-technical point of view

This is interesting and informative. I think the most important expectation here is:

"Understand the impact of change"

It's very easy for a Software Architect to make changes to the technology that have a huge impact on the business/organisation without consideration. For example, if a large retail operation changes the software interface used by 1000 shop assistants then the training implications are VAST and expensive.

Add a comment Send a TrackBack