Beyond Software Architecture: Creating and Sustaining Winning Solutions
I must say I’m disappointed after reading this book. I made one mistake thinking this book is about software architecture. It’s not. It’s title refers to word “architecture” so I thought I will learn something about software integration or modular design. Instead of this book describes in general software product management: licensing details, brand management, etc. – subjects at very high level only slightly related to software construction.
The book is intended rather for managers (product managers or other MBAs) than for IT people. Author writes from the position of strategic director or person who manages product architects (marketing: m-architect and technical: t-architect). There are a lot of topics mentioned inside. But rather in a form “what else you should read somewhere else” – so you will not learn many practical things from this book. One practical thing I found is explanation how number of supported platforms influences cost of product development. It was interesting to learn that portable software construction has also it’s downsides.
I can say diagrams presented in this book are not very useful and rather rare. Paragraphs are a little too long, so you have to be very focused during reading. Inside Polish translation I’ve read I found few translation errors (terms I knew how should be expressed were not correctly translated).
Table of contents
- Software Architecture
- Product Development Primer
- The Difference between Marketecture and Tarchitecture
- Business and License Model Symbiosis
- Technology In-Licensing
- Deployment Architecture
- Integration and Extension
- Brand and Brand Elements
- Release Management
- Appendix A: Release Checklist
- Appendix B: A Pattern Language for Strategic Product Management
Introduction to software product management. Read it only if you have zero knowledge about this subject or no IT background. Can be useful for MBA people or just-starting ISV owners.
* interesting point about workload related to number of supported platforms
* broad range of topics
* no software design details (rather requirements for requirements)
* few useful diagrams
* boring structure (too long paragraphs)