Slashdot Mirror
Beyond Software Architecture
Overview Beyond Software Architecture explains how to bridge the gap between the marketecture and tarchitecture- how to create a product that not only performs well, but which also appeals to the market. It is part of the Addison-Wesley Professional Series line of books (also containing notable titles like Design Patterns, Refactoring, and Patterns of Enterprise Architecture) but this latest installment in the series is (thankfully) paperback, so it comes at a paperback price ($39.99 USD).
I am a software developer with no marketing background who works in small development teams, usually in an open-source development atmosphere. I was excited to find this book because it told me what I need to consider for my projects to help them reach the intended user. There is a lot of helpful information in this book, and at times it almost seems to suggest more work than I can handle, but I think it will ultimately pay off to be able to use the knowledge gained.
Table of Contents Forwards by Martin Fowler and Guy Kawasaki
1. Software Architecture
2. Product Development Primer
3. The Difference between Marketecture and Tarchitecture
4. Business and License Model Symbiosis
5. Technology In-Licensing
6. Portability
7. Deployment Architecture
8. Integration and Extension
9. Brand and Brand Elements
10. Usability
11. Installation
12. Upgrade
13. Configuration
14. Logs
15. Release Management
16. Security
Appendix A. Release Checklist
Appendix B. A Pattern Language for Strategic Product Management
Organization by chapter: Chapters 1-3 set up the rest of the book, defining the scope of the book as well as concepts and key terms used throughout the book. They describe a product development cycle, the players involved, etc.
The remaining chapters each focus on a particular aspect of a software product and how it relates to both the customer and the product's architecture. Catalogs of alternatives are available for each topic along with caveats for each alternative.
For example, in Chapter 6, "Portability," the advantages and disadvantages of creating a portable application are discussed. If most of your customers are using Windows and your code is written in C++, then the cost of supporting Solaris as well may be the difference between a product's financial success and failure. The chapter reminds us that guaranteeing support for 6 operating systems and 4 database backends and 3 browsers means that we have to support and provide quality assurance for 6x4x3=72 combinations of products. Then it describes a process of eliminating or prioritizing combinations of platform support. The chapter goes on to describe ways in which a product's architecture can affect its portability and how best to write software to be portable.
Related to this is a discussion of how supporting particular platforms ties your release cycles into the release cycles of products you support-- another problem that can financially doom a project. Another point from Chapter 6 that I found interesting was what it means to support a platform-- the customer expects you to take advantage of the platform's features. Many cross-platform products are written to be identical on each platform they support, which means they probably ignore platform dependent libraries or features that can enhance performance or usability. This creates a potential place where competitors can gain an edge.
So you see each chapter goes into great length and detail to cover the nuances of its topic, and it is extensive enough that it can be overwhelming and even discouraging.
Who should read this book Anyone involved in software architecture or design, particularly project managers, whether in a very small group or a large corporate atmosphere. Open source developers are notoriously technically proficient, and often are not marketing-savvy. Oftentimes you have to be technically proficient to even install and use an open-source product. Ordinary developers who do not participate in architecture might benefit from reading this book in order to understand the decisions being made by the architects.
Why someone should read this book Many software industry professionals are not marketing experts and may even view the marketing department as their enemy. This book helps bridge that gap between marketing and project management, helping the two parties work together to create more effective, usable, or profitable software. Similarly, open-source developers usually architect and market their own software. Tactics described in this book could help OS developers create software that lasts longer, is more extensible, and more usable.
What this book is and is not. This is a general, and not technology-specific, guide to designing software and while doing so, keeping a marketing perspective in mind. It describes what things a software architect should remember when designing a product.
It is not a guide to marketing software. It does not recommend particular solutions for particular problems. It does not tell you what you should do, only what the consequences of your choices may be.
What I would like to see A similar book that concentrates on the open-source aspects of the topics included in this book and how and how not to use open source tools (like Freshmeat, Sourceforge, Bugzilla, CVS) for marketing and maintaining successful open-source projects.
Recommendation Buy this book if you have benefited from Design Patterns, Refactoring or Patterns of Enterprise Architecture. This book is a welcome addition to a line of books that has consistently contributed to the standard knowledge base of the software architecture discipline.
You can purchase Beyond Software Architecture from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
..."marketecture" or "tarchitecture" in written or verbal form, please kill yourself now.
I'm off to the suicide booth to pay for my sins.
Don't forget to consider the implementation of the buggytechture of your applications. It is important to give your users a reason to buy the next version.
Gee, verbed nouns sure are popularing! Sometimes I think it's almost as bad a habit as l33t sp33k...
"It's a wonderful idea. But it doesn't work." -- Tad Danielewski
Since buzzword-speak became the lingua franca of the tech world (so we're talking at least 5 years now).
Now if you'll excuse me, my toilet is leaking so I have to do some plumbering and a light bulb burned out and it needs electricianing.
From hell's heart I fstab at /dev/hdc
marketecture...tarchitecture
They forgot bamboozlecture (or the bamboozle architecture). It's how authors bamboozle you into buying books about made up words.
Then there's karmarchitecture (or the karma architecture). It's the method by which karma whores read as little of the article as possible and come up with a comment that seems to have something to do with the post but really is just a cheap shot at gathering as much karma as possible.
A programmer is a machine for converting coffee into code.
Just checked http://www.m-w.com and confirmed that Architecting is not, in fact, a real word. For that matter neither is "chunking". Unfortunately, neither is "hork" or "hoark" (as in "That rat-bastard just horked my last twinkie!"). Fortunately, "hosed" is acceptable.
fartchitecture : (noun) an architecture that stinks. Example: [insert most hated OS here...]
there's no place like ~
What I'd like to see is a translation of this book without all the marketspeak. Maybe sales and marketing people need lots of buzzwords to make themselves feel smart, but us technical folk find all that extra verbage a waste of time.
:-)
IMHO
Ruby on Rails Screencast
Brussels, Belgium (DP) - Bill Gates took 1st prize at the International Software Association's first annual contest for "Reliability and Security" in software architecture. However, contest officials caught him before he left the building and made him put it back.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
You keep you using this term "Software Architecture". I do not think it means, what you think it means.
You've got it way too complicated. Here's how it works.
1) Microsoft saleman visits the medical company.
2) CEO tells engineers to use Windows XP for our hard realtime embedded system controlling an intracardiac catheter.
This is actually not a joke. I'm as serious as a cardiac infarction.
A Government Is a Body of People, Usually Notably Ungoverned