Simon is a hands-on software architect who works within 
[Twitter] simonbrown: @kpseal that might explain why my full 99GB backup took just a few hours!
[Coding the Architecture] I did some technical consulting/due diligence on a large software development project recently where I'd been called in to look at how the project team was dealing with some of the non-functional requirements. I'm not sure exactly how large ...
The Pragmatic Architect
A link to an article entitled To Software Architects: Serve End Users, Not Your Egos [via here] dropped into my RSS reader this morning and I thought that it summed up some of the potential pitfalls with software architecture very well - complex and excessively documented architectures.
I've covered some of this before (see agile modelling), but in an architecture role I try to be as pragmatic as possible. It's very easy to fall into the trap of documenting everything "just because it's part of the process". Use case and architecture driven methods such as RUP provide a framework from which you can pick and choose the bits that are useful and relevant to your project but it's easy to to get carried away.
Our development method is loosely based upon RUP (as well as some others) but I've taken a high-level approach to modelling on my current project, particularly since we're a small team. To summarise, our UML model contains the following elements.
- Use case view : a top level use case diagram and some activity diagrams showing detail on the more complex use cases and/or business processes.
- Logical view : a handful of class diagrams showing the architecturally significant components.
- Design view : a collection of class and sequence diagrams showing lower level design for each component in the logical view.
- Deployment view : a couple of component/deployment diagrams showing where components are deployed.
When modelling, it's easiest to go overboard on the design view by describing each and every method on each and every class. Of course, it's good to have some detail on the behaviour of each class and how they interact but, unless you're doing MDA, you have to stop modelling eventually and start coding. As I said in my agile modelling entry, there is always a danger that your model becomes out of date. Choosing the right amount of detail for your project is the key here. If you've got five minutes, do take a look at the article as it's a great read.
On a related note, I did a lot of work with Rational Rose on previous projects, but just recently I've been trying out another tool. More on this later.
