23 April 2008

JAX 2008: Ted Neward on "Pragmatic Architecture"

On the JAX 2008 conference in Wiesbaden, Germany, I heard Ted Neward ("I'm a big geek") talk about "Pragmatic Architectures" - presenting his very code-centric ideal of solution architects.

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.

1 comment:

Matthias Bohlen said...

Yes, Gernot, you are right. In my current position as an architect and technical leader, it is a task in itself to keep everybody informed about the current way the project goes. We do not only write code, we also have one team who buys customizable components and integrates them into the solution (sometimes, we call them "The Ferengi" because they do not manufacture, they only trade).

The other team really writes code, and it is enough work to sync those two teams using a common language.

If I would try this using code, the customizers would not understand me. Code is not the only thing that communicates well, but you need stakeholder-specific artifact types.

I found two artifact types that work: User stories and test cases. Both teams understand them and contribute to them.