Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Beyond Software Architecture 146

Posted by timothy from the horses-for-courses dept.
jkauzlar writes "When thinking about a software product's architecture there are two viewpoints to consider: the marketecture (or the marketing architecture) and the tarchitecture (the technical architecture). Oftentimes an architecture is designed without consideration of the market toward which the product is directed and even a technically superior product can fail against competitors with an inferior product, but who understand the market a lot better." This book tries to remind programmers (and managers) about maintaining the right balance of these things; read on for the rest of jkauzlar's review.
Beyond Software Architecture
author Luke Hohmann
pages 314
publisher Addison-Welsey
rating 5 out of 5
reviewer Joe Kauzlarich
ISBN 0201775948
summary A software architect's guide to designing software with the market and end-user in mind

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.
This discussion has been archived. No new comments can be posted.

Beyond Software Architecture More

Beyond Software Architecture

Comments Filter:

  • Marketing for Developers (Score:3, Insightful)

    by Gortbusters.org ( 637314 ) on Thursday July 03, 2003 @11:02AM (#6359142) Homepage Journal
    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? ;)

    • Re:Marketing for Developers (Score:5, Insightful)

      by C0deJunkie ( 309293 ) on Thursday July 03, 2003 @11:07AM (#6359181) Homepage Journal
      I disagree. If developers (and analysts, project mgr's etc..) do nothing to care about the market (read: at least make the product easy to change/adapt) then the best thing that could happen is a lot of money spent to match user/market requirements.
      • (and analysts, project mgr's etc..)

        Those are the people that should provide input into the project as the key source for market direction.
        • 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).
          • Depending on the organization size, the requirements for a product usually take a few levels:

            - Market requirements
            - General Technical Product Requirements
            - Feature Requirements

            I wouldn't expect a developer to get involve at all in the first, a little in the second, and key on the third to say if it is doable or not in the time frame for the project. And of course the product manager (who understands the market) is a required reviewer of all three.
    • You still have to find a balance. If you're modifying your product to fit every slight change in the market, then you're too far behind.

      Successful developers have the market modified to fit its products. Think Cisco.

      • Re:Marketing for Developers (Score:4, Interesting)

        by Gortbusters.org ( 637314 ) on Thursday July 03, 2003 @11:12AM (#6359229) Homepage Journal
        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.
      • >>Successful developers have the market modified to fit its products. Think Cisco.

        Strangely enough this also applies to Microsoft.
    • 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.

    • Re:Marketing for Developers (Score:5, Insightful)

      by Jack William Bell ( 84469 ) on Thursday July 03, 2003 @11:10AM (#6359209) Homepage Journal
      Bullcrap!

      Developers should care very much about the market, for a variety of reasons. Not the least of which is the fact that the people who's job it is to do that may not have enough knowledge breadth to also understand the technical aspects, and how they are affected by market-based descisions. If you want your voice to be heard in these discussions you have to make certain you are talking in a language they understand.

      Of course if you are content to let marketeers and product managers design your product and build your feature list, and then set your schedule without reference to the technical realities, you might think differently. You might also be working for Microsoft...
      • The product manager should state the high level features that the market is demanding. It is then up to the development community, and more specifically a systems engineer or lead developer, to translate those marketing requirements into technical requirements. Customers want to do task A, so that means we need GUI X, and server component Y to let them do A.

        The person who actually sits down and writes the code for X and Y doesn't really need to know a lot about A, or be an expert in the market for A, as
        • No, generally that would be the job of the business analyst or requirements engineer. It's not good practice to 'state' requirements, generally they are obtained by following a well-defined requirements discovery process, such as RUP.

          The product manager's role to is manage the overall strategy and provide the overall interface between all stakeholders of the product.

          In my company only people who know about X and Y, but not A are usually individual test engineers, who genuinely don't have to. And even then
        • The problem is, the requirements are rarely fully specified. It today's time-to-market and features-are-better-than-quality driven world, development - both for products and corporate IT - is very often expected to take off and work with incomplete requirements.

          That is why developers that understand the target use-case and market are so valuable. They can fill in the gaps to make sure of product quality and fitness for purpose. No, its not the ideal situation, but it is reality.

          I've never seen product man

      • Re:Marketing for Developers (Score:5, Interesting)

        by Shoeman ( 686545 ) on Thursday July 03, 2003 @11:19AM (#6359302)
        I completely agree, not that it matters, but so would Mr.Humprey, DeMarco, Weinberg, and other legends in the software industry.

        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.

        • Hear hear ...

          It's not make things happen - it's make the right things happen.

          If the product of you work is useless or of little use to the end-users it all ends up being some sort self-masturbatory task.

          Half the fun in doing software is when the result of your work is actually used by someone and solves their problems (or improves their business processes, or entertain them or whatever).

          For those that don't quite share my type of "fun in doing software" concept just remember one thing - a company that p
      • 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 wis
      • You might also be working for Microsoft...

        That was a low blow. I've never been more insulted in my entire life.

    • 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 tha
      • I think it comes down to the R&D organization size. I know many large enterprise companies do something like this:

        - Market Requirements document authored by the business team, outlines what exactly the market demands to satisfy the customers

        - Technical Product Requirements authored by a systems engineer or lead developer who knows all aspects of the entire product, and specifies the feature areas and general product information to satisfy the market requirements

        - Software or Feature requirements/arc
      • "Know the marketplace" is a vauge concept. It can mean anything from "know how dominant (Micro$oft) software works to leverage user knowledge" to "know what people want to do". This book looks like it also considers stuff that most of us consider fluff, actual marketing, "branding", sales and all that.

        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 gre

    • Developers shouldn't care about the market.


      That depends on whether you;'re talking about a big corporation or a small one-man business. Obviously, if you have to do more than the programming part, you have to worry about more than the programming part too.

      That said, the best programmers shouldn't care about the market anyhow, because they create a market where none existed.

      Regards,
      --
      *Art

    • Re:Marketing for Developers (Score:5, Insightful)

      by russellh ( 547685 ) on Thursday July 03, 2003 @12:14PM (#6359909) Homepage
      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.

      That's a big if ! But you know, we're not talking about developers, we're talking about software architects. They're not usually interchangeable. Architects need to know a little bit of everything. In particular, seemingly minor points like supporting platform-specific features are often overlooked at the strategic level.

    • Developers shouldn't care about the market.

      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 a

  • If you've ever used the words... (Score:5, Funny)

    by Anonymous Coward on Thursday July 03, 2003 @11:03AM (#6359144)
    ..."marketecture" or "tarchitecture" in written or verbal form, please kill yourself now.

    I'm off to the suicide booth to pay for my sins.
  • Since when is "architecting" a word?

    • Re:Nice verbing (Score:5, Funny)

      by Rudeboy777 ( 214749 ) on Thursday July 03, 2003 @11:07AM (#6359180)
      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.
    • Seems to be an artifact of a culture that views a concrete language rather dimly, I'm afraid. After all, some deep understanding it might *gasp* result in intellectual thought, and endanger the 30-second attention-span most contemporary marketing is struggling hard to reduce to 15 seconds.

      Every noun isn't a verb. If you're an architect, you design things. A plumber is one who plumbs, since the word 'plumber' indicates profession. Architecture, however, is the study and practice of structural design.

      No

    • "Since when is "architecting" a word?"

      Ever since we were tasked with leveraging mission-critical neologisms and jargoning, in order to grow units and upsize language weirding across all territories.

    • Maybe since this bozo [stanford.edu] started using it to title presentations?

      It gets over 74000 hits on google.

      Don't ya' just love the flexibility of English?
    • To paraphrase Alexei Sayle:

      "Anyone who uses the word 'architecting' who isn't even remotely connected with designing buildings is a twat".

      (Original was 'workshop'...'light engineering').

      graspee

  • since we're making up words... (Score:5, Funny)

    by yorkrj ( 658277 ) on Thursday July 03, 2003 @11:03AM (#6359149) Journal
    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.

  • Architecting? (Score:3, Funny)

    by nekoniku ( 183821 ) <justicek AT infosource DOT info> on Thursday July 03, 2003 @11:06AM (#6359173) Homepage
    Gee, verbed nouns sure are popularing! Sometimes I think it's almost as bad a habit as l33t sp33k...

  • Really, now. (Score:5, Funny)

    by inertia187 ( 156602 ) * on Thursday July 03, 2003 @11:08AM (#6359191) Homepage Journal
    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.
  • The last paperback book I bought was $7, new.

  • "architecting" != English (Score:1, Funny)

    by Anonymous Coward
    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.
    • 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.

      Unfortunately according to http://www.m-w.com [m-w.com] "twinkie" is also not a word. I'm gonna go out on a limb and guess that rat-bastard isn't either.

      • Re:"architecting" != English (Score:1, Funny)

        by Anonymous Coward
        Ahh... but "Twinkie" is, in fact, a proper noun, so one wouldn't expect a definition for Twinkie any more than one would for, say, Timex. Rat-bastard, however, is a word formed by joining two indivdual words with a hyphen, much the same way that email used to be e-mail. Much like the semicolon, it is yet another redheaded step child of the English language; it's always around but no one quite understands its origin. Given enough time, I'm sure that NPR will issue a linguistics editorial on the use of the
      • Twinkie is a word, because it is a proper name. A dictionary does not contail all of the names, but names most certainly are words.
    • Just checked http://www.m-w.com and confirmed that Architecting is not, in fact, a real word.

      Ok, so where do new words come from? m-w putting the word in their dictionary and then people start using it?

      People see the need for a new word (in this case a verb describing the process of building software architecture) and they start using it. There's nothing wrong with that. Then other people start using it too and eventually it ends up in m-w. Or people stop using it and it doesn't end up in m-w.
    • If you had access to the full oxford english dictionary, you would find that architecting is, in fact, in there. I thought it wasn't and lost 5 bucks on it. ;)

  • How this concept REALLY works (Score:5, Insightful)

    by beavis88 ( 25983 ) on Thursday July 03, 2003 @11:17AM (#6359276)
    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!
    • But this is software development, you're not supposed to deliver what client wants otherwise they have no reason to upgrade.

    • Re:How this concept REALLY works (Score:5, Insightful)

      by ShieldW0lf ( 601553 ) on Thursday July 03, 2003 @11:26AM (#6359362) Journal
      1) Sales/marketing talk to some clients, convince them we can give them what they want

      2) Developer talks to clients, determines what they need

      3) Developer talks to Sales/marketing, tells them what the client needs

      4) Sales/marketing talks to clients, sells them on what they need

      5) Developer builds what client needs

      6) Everybody Profits!

      If you are caught in the parent posts situation, insert:

      3.5) Developers firmly tell sales/marketing no and why not, cc owner

      • 3.5) Developers firmly tell sales/marketing no and why not, cc owner

        Alas, when the COO wants it, and the beta clients are his buddies, no amount of firm disagreement from the developers makes a difference...
        • Well, technically, no amount of agreement makes a difference either.

          In my experience, once they've been made too look the fool by your being proven right once or twice, they'll be more receptive to listening to your expert advice.

          • I wish this were reality because it is the way it should be.

            From what I've seen, the economic climate is one where programmers have much less a voice in these matters and if they aren't willing to kill themselves to make these deadlines then they might need to be looking for a new job.

            It's also often the case that it's "your word against theirs" and no COO/CEO/big kahuna likes to throw away business. That's the business world. Just get what you can get done..even hack it, as long as we can give somet
          • my experience has been tell them it's immpossible and its your fault when your right.
      • 3.5) Developers firmly tell sales/marketing no and why not, cc owner

        Why not make it 4)? I am serious. Sometimes, the client does not even know what (s)he wants and/or (s)he wants something which is either impractical or utter nonsense. It is the job of the consultant to correct these problems.

        Okay I know, consultant != coding, but I (coder) know something about user-interface design, which is a definite advantage.

        der Joachim.

      • Welcome to the real world (Score:5, Insightful)

        by joss ( 1346 ) on Thursday July 03, 2003 @12:52PM (#6360387) Homepage
        > 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.
    • I couldn't agree more.

      In fact, the IT department I work in spent
      considerable time implementing new features into
      our LAUNCHED product that sales "sold" to new
      customers!!

      grrrr....
    • 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.
    • 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.
    • Your problem is that to many idiots actualy believe that marketing and sales actualy have something to do with each other.

    • 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. Every

  • Follow-up to book (Score:4, Insightful)

    by truth_revealed ( 593493 ) on Thursday July 03, 2003 @11:25AM (#6359345)
    Web Economy Bullshit Generator [dack.com]
  • 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 com

  • Hmmmmm...

    Architecting Software for the Marketplace

    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 [dack.com]. 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.

    • 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 sys
  • 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 :-)

  • Marketecture... (Score:4, Interesting)

    by BitwizeGHC ( 145393 ) on Thursday July 03, 2003 @11:44AM (#6359525) Homepage
    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.

  • Software Contest (Score:3, Funny)

    by ch-chuck ( 9622 ) on Thursday July 03, 2003 @11:45AM (#6359539) Homepage
    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.

  • Marketecture? What market? (Score:5, Interesting)

    by crazyphilman ( 609923 ) on Thursday July 03, 2003 @12:05PM (#6359736) Journal
    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.

      • But I was talking about applications software, which I got the impression the article was about.

        It's true, games are a huge market, and there's a lot of money to be made in producing them. Granted. However, games are developed in a completely different way from applications software, and the marketing and distribution work differently too.

        My understanding of game development is:

        1) A game development team selects a graphics engine and probably a sound engine. Then they learn the API.

        2) While they're lear
        • that's roughly how FPS games are developed. There are so many other genres of game that to take that as a global opinion is ridiculous. Lots of games are still built from scratch, since off-the-shelf stuff never does everything you want it to.
          • I disagree partially. What I said could be held true for FPS, third-person fantasy, space games, basically anything which involves the simulation of some 3-D space. First, before anything else gets done, a group must have graphics and sound engines. Maybe they design their own or maybe they buy someone else's. It makes no difference. If they design their own, they're still producing an API, which a subset of their developers must learn to use. If they design their own, you just add one additional pre-step t
            • Disclaimer: IANAGameDeveloper.

              In the best games, design comes first. You write the technology to support the design, you don't design the GAME mechanics within the constraints of technology. Sounds like some kind of karma-whoring aphorism, but it's true in all the literature that I've read about game design in the real world. The visionary type (Sid Meier, Warren Spector) comes up with a Big Idea and takes it to his tech director to see if it's feasible. The tech director figures out how much of it can
              • Which is why I said that most companies will probably be acquiring a graphics engine first, so that they have the capability to create a game (without that, it doesn't matter HOW good your storyline is). What you're describing is an already-existing gaming company, in which someone cool has come up with a cool idea. But, you're leaving out the part where, independently, their developers have mastered the use of whatever tools they have licensed. I think it's probably set up like separate groups, you know? Y
    • While this may apply to the home (and possibly the business) pure software market, it's not the case across the board. I work for a company which makes specialized testing equipment controlled across a network from a PC. Believe me, there's MANY of my coworkers who would benefit from a book like this. I've lost count of the number of times that a great new feature has been made available, but the implementation has been such that it's rendered almost completely useless. This is primarily due to the fact tha
      • BUT, is what you're describing a marketing issue? Or is it a usability issue? I see it as a usability issue -- there are many more directed books about that topic. It may be true that your engineers need a book, but I don't think it's THIS book. :)

    • > 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.

      Yeah, everything has been invented already. Oh, wait.... haven't I heard that before somewhere.

      The reason software market seems dead at the moment, is we stopped making new applications. The small proportion of developers with an ounce of genuine inventiveness have spent last few years on server side. This doesnt mean that there are no new killer apps out the
      • Wait -- didn't the Second Renaissance end with the defeat of humanity? ;)

        You're barking up the wrong tree. I'm not saying there won't be any new apps, or that everything has been invented already. I'm saying that all new truly innovative things tend to be created by interested individuals, who tend to release them open-source or freeware.

        Corporate development is ponderous, slow, and expensive. Individual programmers are fast on their feet, completely free (they're only spending their time), and able to tu
        • > all new truly innovative things tend to be created by interested individuals, who tend to release them open-source or freeware

          > truly innovative things tend to be created by interested individuals
          - agreed

          > tend to release them open-source or freeware

          I am not convinced of that. Only about thirty major applications have been invented so far.
          [Word processor, Spreadsheet, webbrowser, RDBMS, music editor, pixel manipulators[photoshop], vector manipulator[corel]...] The last major new application I
          • Hidden from view? Or beneath your radar?

            Also, why do you say that there are only thirty major application types that have been developed? There are thousands of projects on Sourceforge. Go take a look. And, tons of new stuff comes out all the time.

            Just because you're not aware of it doesn't mean it isn't there. :)

    • 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

      If marketing isn't central to your business, prepare to hav

      • Yeah, but, see, here you're painting yourself into a corner. You admit that my point about open source has validity. And, you admit that just about anything anyone might want to do is probably available open-source. But then, you assert that there's still a need to market these open source projects to small businesses, even though you've already admitted they could just go download the stuff -- so where's the market? IN reality, it's like, "Here's the website, here's an FTP client". Where's the sale? Where'

  • As Indigo Montoya might say (Score:1, Funny)

    by Anonymous Coward
    You keep you using this term "Software Architecture". I do not think it means, what you think it means.

  • Translation for Hireabiltiy (Score:4, Insightful)

    by rsborg ( 111459 ) on Thursday July 03, 2003 @12:45PM (#6360293) Homepage
    ... know your domain.

    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.

    • Being a domain-oriented organization is a double-edged sword. While it's true that it is useful for everyone to be knowledgeable of your business area, it's also true that there is a tendency to think "inside the box" because there is a lack of diversity of experience.

      In addition, there is value in having a few people around with many years of programming experience regardless of the domain. They can help avoid some of the software pitfalls that are domain-independent.

      Having said that, your point was abou
  • 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 b

  • Baloney (Score:3, Interesting)

    by pmz ( 462998 ) on Thursday July 03, 2003 @01:43PM (#6361070) Homepage
    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.
  • Damnit! You have blundered onto one of my pet peeves. The word "architect" [reference.com] is a noun not a verb. It is not possible to "architect" anything.

    I know this is slashdot, where grammar and spelling are somewhat, shall we say, arbitrary, but damnit dont use nouns as verbs!

    Hooptie

  • Not to be like Spike Lee [eonline.com] 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 [ca.gov] (Practice Without License or Holding Self Out as Architect).

    I don't m

Slashdot Top Deals

There is nothing so easy but that it becomes difficult when you do it reluctantly. -- Publius Terentius Afer (Terence)

Close