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.
Marketing is acctually a big part of ensuring quality processes. All the disciplines ensuring quality need feedback from customers, whether it is the end customer or the company you are supplying. I'm in a position right now setting up a Quality System (granted not for software, but manufactured parts) and it relies heavily on customer feed back on all our processes, not just the quality of our product. I started assuming I wouldn't interact with marketing at all, and now it's become a large focus.
Yes, the planning phase of a project should identify the business case that the product will play in and the potential for revenue that the product will generate.
If you dominate the market or have a monopoly, you can pretty much cram whatever you want down the throat of your customers.
Back in the 80s, AT&T decided what phone features you got, they were the market so they could do whatever they want. Today Cisco has some leeway in that area, but there are still other vendors who have some nice innovations that Cisco will then adopt as well. Or Cisco will drive the market and other vendors will reproduce their features, or improve upon them. Such is the glory of competition.
--------
Free your mind.
Ok, in that way I can see your point, and I completely agree with it.
My point is that the "key source" is just a part of a project goal. Depending on the market you are dealing with you will try to adapt something of your coding habits (eventually based on analysts directions).
Apple iProduct. Non importa cosa sia, lo comprerete!
If your developers are detacthed from the end result of the "want" or "need" their work is trying to satisfy then they are incapable of making good business decisions. They become "code monkeys".
I prefer my staff of developers to think of themselves as entrepreneurial craftsmen. The combination of shrewed businessmen and artfull solutions providers.
I've heard this neologism before, in much the same sense as "benchmarketing", i.e., a sardonic sense wherein it's implied that marketers without any technical knowledge are the ones designing the product.
But if my boss ever uses the words "marketecture" or "tarchitecture" straight-facedly, I'm quitting.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Yes and no.
If you have too many leaders in one room trying to design a software product you're bound to never get anythign done.
I'd like to take an Ayn Rand position on it. I'd say that most developers do NOT need to know much about marketing except for the lead developers and architects who should be interacting WITH the marketing fellows to create a product that's both sound in architecture and marketing.
All the other developers that work underneath this technical leads don't need to be any wiser. That's what leaders are for.
"Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr.
For starters, the home-user market is dead (or, more accurately, about to give its death rattle). Anyone who wants to engage in some activity A has only to go online and download any of a number of open-source or freeware systems for doing A. Oh, there are still a few holdouts; you still see some off-the-shelf software for sale in Comp USA, and I suppose there are some naiive users who are willing to buy them. But, it's definitely going away, and fast.
Organizations still buy software, but they generally contact the vendor directly, and secure site licenses. An example would be software development tools used by a government agency. In this case, there's very little marketing involved; a vendor submits a bid, competes with other vendors, and if successful, gets a contract. Any marketing that is done is done in a trade show, and the vendor generally understands the target market fairly well. Often, the vendor has a long relationship with their clients.
Then, there's highly specialized niche tools, like maybe high-end animation software, or music software. But those markets are tiny, sometimes maybe only a few hundred clients in total.
It seems to me that software is one of the few things with no mass market left. There are only specialized niches that still want to pay for software, and business categories where software has always been paid for in the same way. This is a book whose point I cannot fathom.
THIS IS NOT A TROLL. I'm serious. What's the point of programmers and techies getting all worked up over some marketing blather? It's just not central to the business anymore.
Farewell! It's been a fine buncha years!
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.
I believe very strongly that portable coding is possible and practical. The fact that Visual Basic is so alluring to the lazy should be no excuse. There are such things as Java, POSIX, ANSI SQL, ANSI C, etc.. Most frequently, deviations from these standards are small and add functionality, such as BLOBS in SQL, that aren't consistently implemented, yet. These deviations can be supported by isolating them in the software and providing abstractions that make them invisible to the rest of the application. This is called good architecture. I'm sorry that there are so many people out there who are too stubborn, lazy, and/or stupid to recognize the benefits of good architecture and portability.
The cost analyses that "prove" that non-portable software are better most likely include false assumptions about the cost of supporting additional platforms. They usually leave out the costs saved by organizing the software well, which makes support cheaper through fast problem resolution, fast support for new requirements, etc. Addionally, what are the costs of rewriting from scratch when the chosen platform becomes obselete or the vendor tanks? I'd say those costs are so great that creating portable software should be the rule rather than the exception.
For example, how many companies would simply go bankrupt if Microsoft went they way of Enron? I'd say that our economy is much more fragile than most people will admit.
Healthcare article at Kuro5hin
>>Successful developers have the market modified to fit its products. Think Cisco.
Strangely enough this also applies to Microsoft.
Huh?