Taking some inspiration from the recently published SOA and FAIL manifestos, I thought I'd have a go at writing my own for software architecture.
- Some up-front architecture over doing the whole lot or none at all
- Designing for non-functional requirements over trying to tack them on at the end of the project
- Evaluating technology over just choosing it because it looks good on your CV/resume
- Experimentation over hoping your design will work
- Code over endless discussions, meetings and diagrams
- Collaboration over ivory tower dictation
- Involvement over running away and letting the team deal with the "implementation" problems
- Coaching team members over stroking your own ego
- Pragmatism over perfection
- Real problems over intellectual (self) stimulation
- Simplicity and common sense over complex and convoluted ideas
- Short and useful architecture documentation that reflects reality over encyclopaedias that nobody reads, understands or cares about
Humour aside, this does reflect my view of the role of a software architect. What else would you include?
About the author
Simon lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, helping teams to build better software. His client list spans over 20 countries and includes organisations ranging from small technology startups through to global household names. Simon is an award-winning speaker and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. He still codes too. You can tweet Simon at @simonbrown.