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 is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.
You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.