He started with a small joke architecture is latin, meaning "cannot code anymore". That's funny at first - but his notion of solution architect contains many issues I'm happy to share with him (e.g. care for non-functional requirements, consider goals and external influences, be pragmatic about the technology choices) - but I really missed some (imho crucial) points:
- Architecture is (only) a description of the solution - it's by no means the solution itself.
- Source code is sometimes (imho: very often) not suited to communicate structures-in-the-large. Its value is in my opionion ofter over-estimated - as there are so many other artifacts within software projects to be considered (like: existing data and data-models, existing business process descriptions etc.)
- Other important tasks (which architects need to support) are communication and documentation of technical issues, technical risk management, technical consulting to other stakeholders and so forth.
If the architects is coding like hell, (s)he's very likely to neglect one or several of these - with potentially dangerous consequences in the long run.
Ted continued to bash on "drawing, not coding", which got him serious bonus-points from the audience - but there were definitely no managers present to contradict him... In my opinion, coding only makes up a small fraction of the overall effort in projects.
He didn't get to the point of giving advice on how to achieve pragmatic architectures - which I found a little disappointing (all right - I did not expect miracles within that 60 minutes).
But I learned some really valuable things:
- First: Building commercial enterprise systems always boils down to the magical HST. Which stands for hooking shit together.
- Second: Even big geeks have no simple approaches for designing pragmatic architectures.
Summary: It's a real pleasure to hear Ted Neward talk - he's awesomely funny, makes great points and centers his attention on source code.
