2011-11-02 | 04:45 PM - 05:35 PM Some architectural problems have been with us - in one form or another - since the dawn of software development: How should I modularise my application? How can I ensure my application is loosely coupled? How can I keep things abstracted and encapsulated, and how much abstraction and encapsulation is too much? What system should I use for loading my program (classes) into memory? How do I configure my application? How should I handle maintenance and versioning? As software developers, we've learned a lot about writing modular, maintainable, and cleanly architected programs since we first fed a string of 0s and 1s into a computer. However, there are still lots of open questions. This talk will explain what we now know and discuss the architectural challenges which are still worrying us, as an industry. It will go underneath the theory to provide real-world examples of when patterns go right, when they go wrong, and when they go so wrong they leave a trail of architectural destruction in their wake.

1. Life, the Universe, and Everything: Sixty
Years of Architectural Knowledge in Sixty
Minutes
Alasdair Nottingham

2. The Architecture

3. The Reality
?
dragons

4. Encapsulation

5. Modularise
• I want to modularise my application
• Bad Answer: I’ll use OSGi and put it in one
big bundle
• Good Answer: I’ll modularize my app and
use OSGi to enforce my boundaries

6. Loose Coupling
• How do I achieve Loose Coupling
• Bad Answer: Use static factories
• Good Answer: Use OSGi services

7. Extensibility
• I want to allow someone to plugin
• Bad Answer: Ooh, Eclipse has this thing
called the Extension Registry
• Good Answer: OSGi services

8. Configuration
• How do I configure my application
• Bad Answer 1: Use system properties
• Bad Answer 2: Each component does it
themselves
• Good Answer: Central configuration
management.

9. Maintenance

10. Versioning
• How do I version my shiny new component
• Bad Answer: Get marketing to do it for
you.
• Good Answer: Version semantically.

11. Complexity
• I might need to do X later on
• Bad Answer: Design the ability to plug X in
now
• Good Answer: Wait until you get the
requirement.

12. The Architect From Hell
• Leads by dictat
• Never explains why
• I’m right because of all my experience.
• X is the answer, what is the question?
• Doesn’t trust the developers
• We can’t use that because 15 years ago...
• We should use X because it is cool

13. The Nice Architect
• Trusts the developers
• Listens to the developers
• Can actually write code
• Explains reasoning
• Be honest
• Is the developer?

14. Plan for Failure
• The Earth’s 10 billion year program was
destroyed 5 minutes before the program to
calculate the ultimate question of life the
universe and everything completed.

15. Thanks