Why I Don’t Teach a Traditional Software Architecture Course (Any Longer)

tl;dr The software development contexts that I deal most with these days are open source projects and fast-moving startups; both don’t seem to have much use for what is traditionally taught in software architectures courses.

Let me start by saying that I love a good software architecture as well as software architecture in general. My dissertation was on better modeling object-oriented frameworks and I have played the architect role for most of my engineering days. I even started a traditional software architecture course at my university. However, I got bored quickly and couldn’t connect it to the practice I dealt with, so I passed the course on to a colleague who is now teaching it. I do teach, however, the associated software architecture project, in which student teams perform some analysis and provide recommendations on a real-world architecture provided by an industry partner.

Most software architecture concepts are simple: Components, interfaces, relationships. Cohesion and Coupling. Styles and patterns. Simple concepts become complex when you try to formalize them: Notations for everything. Unintuitive syntax and semantics. Metrics and analyses that may show something but usually don’t. And above all, tools that hard to use because in order to arrive at syntactically correct models users have to work with maddeningly cumbersome user interfaces. For the simple concepts, you don’t need a course, just abstraction skills and experience or intuition. For the not-so-simple concepts, you do need a course or you’ll get lost in UML’s M-levels.

That said, my colleague loves teaching the course. There is ample evidence of the importance of software architecture in large companies and for large systems. And it is not just for the purpose of creating a new salary band for software architects to reward senior developers. I suspect, but don’t know, that the separation of work afforded by unwieldy notations is helpful in large companies with widely varying capabilities of the involved people. It may get the job done, but you shouldn’t expect something elegant or beautiful.

In contrast to this, neither open source projects nor fast-moving startups tend to care. I have yet to see my first open source project that uses UML or my first startup that uses the arc42 template to documents its architecture. In these contexts, what counts are the capabilities of people and they’ll keep anyone out who doesn’t fit the bill. In most circumstances, the notations and concepts that you learn in a traditional software architecture course will only get in the way.

2 Replies to “Why I Don’t Teach a Traditional Software Architecture Course (Any Longer)”

Leave a Reply