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.
Developers shouldn't care about the market. If you have a quality process in place with requirements that are reviewed by many disciplines (services, product management, etc) then they will modify the product to fit the market.
;)
If you don't have that well.. how much quality will you have anyway whether you get this book or not?
--------
Free your mind.
..."marketecture" or "tarchitecture" in written or verbal form, please kill yourself now.
I'm off to the suicide booth to pay for my sins.
In Soviet Rush, today's Tom Sawyer gets high on you.
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
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.
This has the makings of a wonderful thread. One of my favorite consulting words is incent, as in "The client hasn't been properly incented to give us a bunch more money." Let's hear your favorites!
The last paperback book I bought was $7, new.
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.
1) Sales/marketing talk to some clients, find out what they want.
2) Sales/marketing sign up clients for the beta.
3) Sales/marketing finally gets around to communicating to the dev team what they have promised the clients.
4) Sales/marketing blames the developers when they can't deliver what the client was promised.
This is actually not a joke. On one of that last projects I worked on, I was handed the "specification", which was basically a collection of photoshop mockups, and told that clients were going to be beta testing in 30 days....wheee!
The top down hand requirements to developers process is conceptually the same as the top down hand work orders to factory people process that GM used to produce many of its illconceived cars in the 1970s and 1980s.
Developers MUST know the marketplace because capturing all of the market knowledge into a requirements slows down business mobility too much to make it a worthwhile process.
Besides, if developers know the market they are in, then, they have an automatic value add over requirements only shops that work overseas!
This is my sig.
Web Economy Bullshit Generator
(enough said)
Making things deliberatly incompatible with existing technologies, applications, and infrastructure in order to force the user to change..
I'd often made the remark that I was going to bring my department into the 21st century, kicking and screaming - little did I know that I would be kicking and screaming when Microsoft's !tarchitecture made my job more difficult and sometimes pure hell.
Maybe change is good, but I have seen very few good changes in the past 2 years - at least nothing worth ripping every computer out and upgrading....
Keep up the good work and stay the course. When the management realizes that many open source projects build and keep a solid foundation, they'll be more likely to choose against the wrecking ball.
-B
Hmmmmm...
Ok, architects design.
"architect" is a noun not a verb.
There is no such word as "architecting".
The title does, however, remind me of some of the stuff you see on this page. It also reminds me of a person I did work experience with during school. Incidentally, I never want to work with said person again, because he was full of crap.
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
How is architecting a word? Oh yeah people want fancy titles like "architect" nowadays .. what happened to designers?
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!
Making up words is the sure sign that the author is an idiot?
:-)
Like Shakespear did? I guess a fair number of Highschool students might agree with you.
I'm only being half cynical, really.
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); }
Architecting is not a word!!!
Nah, they're actually in the book. Sad, but true.
You get photoshop mockups??? You Lucky, lucky person.
Step 3 is wrong. It should read:
3.Sales/marketing can't be arsed to tell the dev team what they have promised the clients. Or when. Or even the name of the clients. Specifications are then drawn up that look like horoscopes, by the IT Manager (Ex-Army, ex-mechanical engineering, ex-three day programming course c. 1960) which are unimplementable.
"As a writer / novelist you might want to spellcheck your sig.
retardchitecture
-- Alan
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!
I don't have much use for this book. When I want to write a program, I know what I want it to do. If other people can use it, great! There are plenty of projects, like Gnome and KDE, that are doing a great job with user interfaces and all that other stuff. Their interfaces manage to incorporate M$ stuff without crippling it or pulling in too much of the intentionally confusing bits. Indeed, most of the free software I use comes with good documentation and installs via apt. If any project I work on lives up to those standards, it's sure to be picked up. If not, oh well, that's alright. I'm happy if my project meets my own needs.
Friends don't help friends install M$ junk.
You keep you using this term "Software Architecture". I do not think it means, what you think it means.
The so called marketecture of this book is outcome oriented too. Tirage is at the heart of marketecture. Throw away nifty geeky design ornaments in favor of maximizing your return. Really take into account your target.
I especially think the section on discarding portability is a wise choice for the bottom line. It leads to faster development and more powerful software which can take advantage of platform and processor specific features.
The whole concept works well with XP because we are interested more in pragmatics than aesthetics. The aesthetic may work well in academia, but it more often results in longer time to market in the real world.
What do you get when you combine a marketing executive with a marketing executive?
Masshole.
Is not a word!
Damn it!
I killed da wabbit -Elmer Fudd
Too often I've been telling my friends in the software industry that when hiring into a software company, the primary thing a prospective employer should ask for is domain knowledge. ie, if you're looking to join Cisco's IOS team, you better have a pretty fundamental understanding of networking and routing. If you're joining an CRM software company, knowledge of CRM (at least a specialty like sales force automation) is the primary thing they will want. Even better is direct knowledge of the product/architecture itself. Programming experience is, of course, neccessary, but runs secondary to the actual domain knowledge.
C++, Java, etc.. don't matter as much these days because everyone knows them ... including those offshore programmers who are probably better and/or cheaper than you. Understanding and becoming an expert in a domain gives you a value add that a non-knowledgeable person can't match.
Make sure everyone's vote counts: Verified Voting
> 3.5) Developers firmly tell sales/marketing no and why not, cc owner
Try it in a US corporate structure and your career will be stuck in mud forever. You will be penalised for lacking a "can do" attitude. Meanwhile some other twinkie will claim that everything is fine and promise delivery. Then they fail miserably. Now comes the weird part: The collosal failure of the twinkie will be immediately forgotten and he will be promoted, but your negative attitude will be remembered. Nobody is less popular than the guy who correctly anticipates failure. When it turns out you were right, somehow the PHBs will figure failure is your fault even if you are not involved at all.
In terms of what will help you climb the corporate ladder, these are your options in declining order:
1. Predict success and succeed
2. Predict success and fail
3. Predict failure and succeed
4. Predict failure and fail [or don't try]
Option 4 is a LONG way below option 2.
I am not recommending [2], just pointing out how things work. A better option is to get the hell out of that kind of environment.
http://rareformnewmedia.com/
To start with, all languages exist due to the evolution of languages. New words appear and old words disappear. Nouns turn into verbs and verbs turn into nouns. I believe the reason for turning "architect" into a verb in this case is because in software development you separate between the software's architecture, design and implementation. The programmer is implementing, the system designer is designing and the system architect is... well... not designing. That's what the system designer is doing. The system architect is architecting. Ok, not everybody must use that word. You're free to use whatever words you want (at least in my country). I wouldn't mind using "architecting" whenever I need to distinguish it from "designing". I will probably never use "marchitecture". And I will definitely never ever use "tarchitecture". However, I don't mind if other people use those words. It's up to them.
Smoke and mirrors. How stupid.
For example, Microsoft's "marketecture" is actually a lying-through-the-teeth-marketing department coupled with an unscrupulous aquire-and-crush department coupled with leadership that has a psychological deformity that makes them believe in world domination. Their "tarchitecture" are too-smart-for-their-own-good college graduates and a counter-intuitive culture of cut-n-paste and stock options.
In the "real world", which Microsoft is not a part of, there is no distinction between "marketecture" and "tarchitecure". Well designed software is genuinely useful, with a healthy set of features, a healthy user interface, and robustness. I believe I will call it, simply, "architecture." If this "architecture" does not truly fill the customers need, then capitalistic natural selection provides an honest solution.
You may claim that Microsoft has truly filled the needs of many people, but, upon closer inspection, this is not true. Many others have found ways to fill the same needs better, but, somehow, Microsoft skirted the laws of nature and invented their own microuniverse of delusion. I believe they will be short-lived in the grand scheme of things, where truly superior architectures will come in and make them obselete.
Healthcare article at Kuro5hin
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
I know this is slashdot, where grammar and spelling are somewhat, shall we say, arbitrary, but damnit dont use nouns as verbs!
Hooptie
"Heavens, it appears that my weewee has been stricken with rigor mortis!" -- Stewie Griffin
Why not? Nobody is suggesting developers do the marketing, just that it is beneficial if they understand about that aspect of the business. The wider their view of the whole process, the better decisions they will make, which will result in a product that is more marketable. No matter what your process or how high quality it is, no product specification from marketing will ever be so detailed that the developers never have to make any decisions during design and implementation that influence the marketability of the product.
Welcome to the net of 1000 lies. Upgrades are scheduled soon that should bring us to the 10,000 lies mark.
- Marketecture: architecture done by someone named Mark
- Tarchitecture: the design of a roadbed
- Farkitecture: what Drew Curtis does all day
- Sarkitecture: the organization behind the guards in Tron
- Darkitecture: the buildings in Tim Burton's Batman movies, or Blade Runner
- Quarkitecture: how you wind up with five-quarked subatomic particle
- Barkitecture: secondary phloem, periderm, lenticels
- Narcitecture: planning a drug-related sting operation
- Arkitecture: how Noah built his boat
- Parkitecture: the annoying way they lay out parking structures so that there's always some sort of deficiency
(By the way, none of these are to be confused with Barkitexture, Darkitexture, etc.)"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
Not to be like Spike Lee or anything, but I'm mildly annoyed by the use of the term "architecture" in regards to software design. For the most part, I can let it go, but damn, using it as a verb? With marketecture and tarchitecture?
I spent 5 years of my life to get an architecture degree, worked 3 years for firms, and yet I can't put my name anywhere near the word "architecture" until I get my license or I get popped for a section 5536 (Practice Without License or Holding Self Out as Architect).
I don't mind the geeks having it, just keep it away from the damn marketing droids.
Larchitecture: the part of the design concerned with locking users into your product so that the marketecture and tarchitecture become irrelevant.
There is no noun that can't be verbed.
Interestingly the writer does not mention law in the book? IP is pretty important, especially when dealing with open-source and marketing. The problem is that you get marketers and software developers together. You should really get lawyers and software people together. That way you might defend long-term problems. Marketing is by nature short-sighted. Lawyers are not.
Around the days when Context MBA and Lotus 1-2-3 were slugging it out, the trade press was filled with dozens of stories about a hot new software product named "Ovation." It was one of the first big products to be managed and launched by MBA's, and it almost literally fits the above description. The MBA's were simply brilliant at lining up venture capital, getting press attention, making sure the product had the right features, doing absolutely everything right. The press raved about the screen shots. Everyone was sure it was going to be the biggest success in PC history up to that time. Because, for the first time, you had real business people on board and in charge from day one.
Except they omitted one small detail.
Developing the product.
"How to Do Nothing," kids activities, back in print!