It’s been over a week since the last one, but here is #2.
Top 10 tips for presenting architecture information:
- Know Your Audience
- Carefully Choose Your Approach
- Set the Context
- Increase the Information Resolution
- Show Data on a Universal Grid
- Use Small Multiples
- Recognize that Content is King
- Leverage Industry Standard Notation Techniques
- Incorporate Relevant Facts and Figures
- Follow the Particular, General, Particular Pattern
Read more here.
I was just going through some old notes from last year’s Australian Architecture Forum. One of the presenters spoke about how service registries are very useful, but often will end up out of date with the real running systems due to the maintenance overhead. The suggestion was to harvest information from various sources, such as:
- version control
- continuous integration servers
- interface documentation
- task / issue tracking systems
- application servers and message broker
I’ll be looking for ways to add these to the governance toolkit, as regardless how many rules we put in place, people will always find ways around them, often for what sounds like good reason (so they don’t tell you!)
Zapthink remind us of the value of reference architectures.
The Ujuzi take (with apologies):
- build on a pre-existing reference architecture where possible (this is the standing on the shoulders of giants bit)
- if you are committed to a vendor’s product, decide how deeply you are prepared to entrench it in your architecture and then build on their best practices for the chosen bits
- maintain a register of lessons learned (and solutions) as you go through projects
- document antipatterns and how to avoid them
- document new patterns and how to apply them
- document what doesn’t work as advertised – whether it is a vendor product capability or just an architectural approach
- PoC, PoC, PoC
This is going to change the game in a big way – Oracle et al, look out!
Faith without works (james 2:20) is plain trouble and so is architecture that’s not backed by a PoC.