Slashdot is powered by your submissions, so send in your scoop

 



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

Software Architecture 95

BShive writes "Software Architecture: Organizational Principles and Patterns covers the VRAPS model and the organizational aspects of Software Architecture. Patterns and Antipatterns are explored that resolve or complicate problems depending on the criteria involved. A Pattern that solves one situation might become an Antipattern in another, as not all situations need the same solutions. This fact is something forgotten too often in software projects. Architects, coders and even managers might benefit from the information contained in this book. Being able to identify and solve problems in a project and its organization is important for any large software project no matter where you are in the development chain." Read on for the rest of Ben's review.
Software Architecture: Organizational Principles and Patterns
author David M. Dikel, et al
pages 250
publisher Prentice Hall PTR
rating 7
reviewer Ben Shive
ISBN 0130290327
summary Useful approach to organizing software projects, from people to code.

The book opens by explaining what VRAPS (Vision, Rhythm, Anticipation, Partnering, and Simplification) is and what the book can do for the reader. Software Architecture is increasingly important, but the organizational aspect is often overlooked. Architecture and Organization do overlap, but to the executive the Architecture side is hidden, and to the practitioner the Organizational side is hidden. VRAPS attempts to shift the perspectives of the executive and practitioner to provide a more balanced view. An excellent summary of why each of the VRAPS principles are important is provided. A short example scenario follows, briefly illustrating how the model can be used and misused. These concepts are further expanded throughout the book.

The second chapter is essentially a more detailed look at VRAPS and how everything fits together. Criteria, Patterns and Antipatterns are explained, along with a short history of VRAPS. An amusing anecdote mentioned was a manager who divided his program into one hundred modules to show percent complete. Only five modules had more than 100 lines of code. One of the five had over a million lines. There are similar occurrences throughout the book that illustrate various follies in software development and management.

Chapter three deals with maintaining the vision and direction of the project while balancing all the influences. To a manager, the project may look perfectly ordered on paper while features are added and removed. On paper it still looks neat, but to the practitioner it can appear a jumbled mess. The reader also sees the first example of how the situation layouts are handled in the book. A short summary covering the Criteria, Antipatterns, and Patterns is presented. Then each criterion is further examined with its related Antipatterns and Patterns.

Further chapters proceed with introducing various development concepts that complete the VRAPS moniker. How to put the concepts into practice is explored through the same Criteria, Antipattern and Pattern layout. It does an excellent job of illustrating each part of VRAPS. Following at least some of the principles will result in a project that will be successful, instead of becoming one of the book's examples where the team ended up with nothing to show for its work.

The chapter on the Allaire (now part of Macromedia) case study was the most interesting chapter of the whole book. Company and product development is followed, including mistakes made along the way. The final chapter on 'Building and Implementing a Benchmark' was rather unimpressive. It seemed merely tacked onto the end and included no real conclusion to the entire book. However, the rest of the book is a solid piece of work with very useful information.

The anecdotes and examples throughout keep the reading from becoming too dull. Even with a flat finish to the book it contains plenty of valuable information and is worth the admission price, though it could have been better still.

Chapters

1. What You Can't See could Help You
2. The VRAPS Reference Model: How the Pieces Fit Together
3. Projecting and Unifying Vision
4. Rhythm: Assuring Beat, Process, and Movement
5. Anticipation: Predicting, Validating, and Adapting
6. Partnering: Building Cooperative Organizations
7. Simplification: Clarifying and Minimizing
8. Principles at Work: The Allaire Case Study
9. Case Study: Building and Implementing a Benchmark Using VRAPS

Appendixes

A. Quick Reference Table: Principles, Criteria, Antipatterns, and Patterns
B. Antipattern and Pattern Summaries


You can purchase Software Architecture: Organizational Principles and Patterns 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.

Software Architecture

Comments Filter:
  • At work... (Score:3, Funny)

    by Anonymous Coward on Monday December 16, 2002 @11:52AM (#4899222)
    we use the American Standard Spiral (ASS) model.
  • by L. VeGas ( 580015 ) on Monday December 16, 2002 @11:55AM (#4899239) Homepage Journal
    Being able to identify and solve problems in a project and its organization is important for any large software project no matter where you are in the development chain.

    This is the kind of astute observation that makes reading /. so fun (and informative!). If I may be so bold to add on to your analysis, I think it's also important for a software developer to be able to read and write. No matter where you are in the development chain.
    • [Being able to identify and solve problems in a project and its organization is important for any large software project no matter where you are in the development chain. ] This is the kind of astute observation that makes reading /. so fun (and informative!).

      I once took some Management courses, and roughly 80 percent of the textbook was stuff like that. There was very little real substance. I suppose to people just born (physically or mentally) it might be new, but it bored the sh8t out of me.

      At least I learned why PHB's talk the way the do, and perhaps learned some good fluff-talkin' techniques for speeches, interviews, etc. I suppose that counts as "education", but I doubt it is what the author(s) intended.
      • There scary thing is, there are people out there that will read a statement like that and consider it a glorious insight. Those are the people that would end up paying $500 to go to an all-day event at a hotel to hear a motivational speaker. I think the average slashdot reader is a little smarter than that, but these people do exist.

        I'm not making any comment on the rest of the book. As a software cfaftsman, I might be interested in actually reading it.
        • Those are the people that would end up paying $500 to go to an all-day event at a hotel to hear a motivational speaker. I think the average slashdot reader is a little smarter than that, but these people do exist.

          I somewhat disagree. The purpose of a "motivational speaker" is to motivate, not necessarily supply new knowledge. I have been to one (paid by my employer), and the speaker was actually pretty good.

    • the syllogism is also obvious, but had to be stated at one time.

      software is logic. It's abstract.

      "Obvious" is a synonym of "true".

      It's so obvious we are a half century behind on integrating this obviousness in our software engnineering "standards".

      Go to a disorganized software team. Try to formalize these "obvious" ideas to actually benefit the process, and you will experience people resisting the obvious -- which they will try to say is "because it's obvious".

      The thing about going through the "obvious" is that subtle truths arrise, and some obvious things turn out to be false (obviously heavy things fall faster than lighter things... we waited hundreds of years to find Aristotle was wrong in this because the attidutes was, it's obvious, why check?)

      Please, write down everything that is obvious... I want to read it.
      • Please, write down everything that is obvious... I want to read it.

        Obvious Things

        1. You take yourself way too seriously.

        2. I'm being a kind of a jerk.

        3. There's no way I'm goin to finish th
        • I don't know why you say I take myself too seriously just because I have an opinion. Another knee-jerk rhetorical tactic, maybe? I don't see how it applies to me.

          btw, obviously, you did finish.

          And I'm still right about what it means if something is "obvious" and that we need more obvious statements about software engineering because our field is very substandard as an engineering practice, with a total inability to make reliable predictions on cost, schedule and functionality.

          I just presented the CMM to the director... "isn't this obvious management technique?" he asked, "Yes," I admitted. Still, we struggle, in software, to do and justify the "obvious".

          You have oversimplified the situation. It's actually so complicated even the obvious is a source of confusion. As is the fact that there are "obvious" facts in contradiction with on another.

          I have analysed this a lot, not because I take myself so seriously, but because it has a direct impact on my work... which I guess I do take fairly seriously.
  • It's a go! (Score:5, Funny)

    by Hayzeus ( 596826 ) on Monday December 16, 2002 @11:57AM (#4899260) Homepage
    This methodology has what is probably the most important feature any methodology can have: a nifty acronym. Sounds highly technical, yet it could also be a tasty lunch item. I shall write a memo to the CTO forthwith!
    • by Mr. Sketch ( 111112 ) <<mister.sketch> <at> <gmail.com>> on Monday December 16, 2002 @12:00PM (#4899284)
      Actually the acronym is missing an MT in front of it for Multiple Threads, making the real acronym MTVRAPS.
      • by xphase ( 56482 )
        It's also missing:

        Yield Organizational!

        Which leads to YO!MTVRAPS

        Yield Organizational! Multiple Thread Vision, Rhythm, Anticipation, Partnering, and Simplification

        • ROFL. that is one of the funniest comment threads I have read on slashdot in a LONG while.

          (Of coruse maybe it has something to do with I am actually old enough -- aka >25 -- to remember when that show was on MTV)
    • As a CTO I would be inclined to deny your request, as it is obviously frivolous and without merit.

      Had you included rude, crude, or otherwise obscene representations of VRAPS which were themselves clever and amusing -- so we could refer to it in a more meaningful and appropriate way when it broke -- then it would get rubber-stamped on through the 'process'.
    • by ergo98 ( 9391 ) on Monday December 16, 2002 @12:19PM (#4899432) Homepage Journal
      Acronyms and titles on processes are often a great source of hilarity as well meaning and inferior feeling developers will go along with whatever you say just to seem like they're "in" with whatever is hip and cool (despite the fact that the overwhelming majority of these things are fringe technologies and processes that overwhelmingly people have no clue, rightly, about).

      "Are you familiar with the CORAN 2 process?"
      "Oh yeah...we use that a lot."
      "Really? I use it in concert with UMX and ICBM VSLAM for maximum effect. We use Agile Extremities processes with core-duplex programming methodologies"
      "Ooooh...sounds awesome!"
      "Yeah, it's good stuff. You really need quad-programming to and read once write never methodologies to have quality code. As long as you use over the shoulder management with sycophant posterior gestulations it all turns out good."
  • manager? (Score:5, Funny)

    by tanveer1979 ( 530624 ) on Monday December 16, 2002 @12:02PM (#4899289) Homepage Journal
    An amusing anecdote mentioned was a manager who divided his program into one hundred modules to show percent complete.

    You don't call such people managers....
    you call them damagers.

    • Re:manager? (Score:2, Funny)

      by winse ( 39597 )
      interestingly ... I bet the taskbar for the entire project moved along with some jumps and stalls and then stayed on 99% for a couple of months.
  • I think reviews should address those questions.
  • by mwillson ( 165675 ) on Monday December 16, 2002 @12:08PM (#4899350)
    I saw David Kane present these concepts at a Software Architecture Conference. In essence, he was reinforcing the importance of architecture, and the need to deal adequately with all the non-technical aspects of implementing an architecture within an organisation. The book is worth a read, mostly for solutions to people-type problems (e.g. how to persuade a development team to adhere to an architecture, using informal relationships to aid communication and shared goals).
  • VRAPS (Score:5, Insightful)

    by sql*kitten ( 1359 ) on Monday December 16, 2002 @12:16PM (#4899409)
    Software Architecture: Organizational Principles and Patterns covers the VRAPS model and the organizational aspects of Software Architecture

    You know, there's one thing worse than developing software without a methodology, and that's changing the methodology every time someone comes out with a new acronym. No-one can evaluate a method until they've done a few non-trivial projects with it, and that takes years. If all the people who jumped on the RUP bandwagon then the XP bandwagon jump on this, the industry's track record for delivering on time and within budget will only get worse.
    • Re:VRAPS (Score:1, Insightful)

      by Anonymous Coward
      I'll second that. Whatever happened to assessing a problem, identifying the hard parts and the parts you could do without up front, then assigning the work and doing what needs doing? It's always worked for me.
    • Re:VRAPS (Score:4, Insightful)

      by spakka ( 606417 ) on Monday December 16, 2002 @12:43PM (#4899554)
      The book under review seems even more vacuous than usual for the genre. The chapter titles are laughable, but appealing to a certain 'inspirational leadership' type of manager. Only one successful case study? Design Patterns cites several per pattern. And I simply don't believe the anecdote about the manager with the million+ lines of code in his source file.
      • Only one successful case study? Design Patterns cites several per pattern.
        The book has a much stronger evidence base than that. There are 18 different organization at which we conducted structured studies. We interviewed over 125 people from architects to software engineers to managers. We also drew from our own experiences as practitioners and from other published work. All of the patterns and antipatterns in the book include real examples as well.
    • Re:VRAPS (Score:5, Insightful)

      by pmz ( 462998 ) on Monday December 16, 2002 @01:00PM (#4899638) Homepage
      No-one can evaluate a method until they've done a few non-trivial projects with it, and that takes years. If all the people who jumped on the RUP bandwagon then the XP bandwagon jump on this, the industry's track record for delivering on time and within budget will only get worse.

      Thus the importance of not adopting RUP, XP, etc. for real projects. These methodologies can be informative, but it is better to create a simplified custom process for each project. It isn't very hard, and the development team can establish the tool chain, conventions, and documentation methods that suits them and the project's requirements best. Note that simplifying the process is critical, because no one can seriously keep track of developing real software while trying to learn some baroque process. Also, it is always critical to avoid proprietary documentation formats (e.g., basically anything by Microsoft), trendy IDEs, acronyms of the month, and other neat but immature development toys.

      Personally, I think taking the time to actually implement the dogma of RUP, XP, etc. is a waste of time, when 1) no one really understands them, anyway and 2) they are like fashion: here today, gone tomorrow, possibly reborn in 20 years, but who knows.
  • by Idarubicin ( 579475 ) on Monday December 16, 2002 @12:19PM (#4899435) Journal
    Although VRAPS does emphasize Vision, Rhythm, Anticipation, Partnering, and Simplification, the whole book is about Criteria, Antipatterns, and Patterns.

    Consequently, I propose the following acronym.

    Criteria
    Rhythm
    Antipatterns
    Patterns

  • Software is ART. (Score:4, Interesting)

    by Boss, Pointy Haired ( 537010 ) on Monday December 16, 2002 @12:24PM (#4899484)
    I wish people would stop trying to manage it.
    • by Daleks ( 226923 ) on Monday December 16, 2002 @12:40PM (#4899540)
      If software is art, what's the software equivalent of modern art? My guess it's something like Befunge or Brainf*ck. Also, I say the software world's Bob Ross would be Donald Knuth.

      Yes, it's Monday.
    • Agreed: Software is Art.

      Unfortunately, people who fund the Arts usually expect to manage the Arts ... even if they know nothing about Art.

    • See, I'm not anti-Moft biggot or anything... but this book was designed for the countless shops out there that have 'MCSE senior VB programmers'. (Not that in itself is bad - but most just leave it at that... whereas a true programmer should continue learning all their lives)

      Software is Art, and one of the reasons why the industry is in such shit right now is because there's a bunch of Con Artists pretending to be programmers out there.

      • I just left a software company that mostly used C++, and there were several guys there that had the "I don't need to learn anything new because I can already do it in obfuscated C/C++" mentality. Getting some of them to look at newer languages, tools, methodologies, etc., was like pulling teeth.

        It's not that they only wanted to code in C/C++, it's that they habitually coded *badly* in C/C++. IMHO, that's where a lot of the crap code comes from - people that have no interest in ongoing learning.

  • Anti-pattern Rant (Score:5, Interesting)

    by Shamanin ( 561998 ) on Monday December 16, 2002 @01:07PM (#4899719)
    I had a former collegue that just couldn't grasp the use of design patterns, and thus despised the concept. He also couldn't solve large scale programming problems and wasn't much of a software architect in general. Then, the book anti-patterns comes out which he latched onto as some sort of weapon against the evil design patterns. He became very dogmatic about using what he had learned from the book to shoot down others designs (obviously, not what the book was intended for), trying to find fault in others work to somehow cover for his own inadequacies.

    My former collegue taught me one thing if nothing else. It is easier to find a problem in a design than it is to find a solution for a design. Design patterns are a powerful way to classify and grasp large abstract recurring design issues. Anti-patterns are nothing but the same. Don't let anyone tell you otherwise.
    • Re:Anti-pattern Rant (Score:3, Interesting)

      by Bazzargh ( 39195 )
      This isn't just a pattern/antipattern thing. Many discussions er... have this pattern. Its the reason why we have the phrase "constructive criticism".

      Another extreme of criticism is Bikeshed Painting [freebsd.org], where you get swamped with alternative designs; I only mention this because of the nice story behind that link.

    • Re:Anti-pattern Rant (Score:4, Interesting)

      by rossifer ( 581396 ) on Monday December 16, 2002 @01:37PM (#4900062) Journal
      I had a former collegue that just couldn't grasp the use of design patterns, and thus despised the concept. He also couldn't solve large scale programming problems and wasn't much of a software architect in general. Then, the book anti-patterns comes out which he latched onto as some sort of weapon against the evil design patterns.

      Ya know, I'll bet he loved the "Golden Hammer" antipattern. For those in the cheap seats: the golden hammer antipattern observes that people who get a shiny new tool tend to look at all new problems as if the tool can solve them. I.e. if the only tool you've got is a hammer, all of your problems start to look like nails.

      This particular application of this anti-pattern (as a universal pattern debunking argument) is particularly ironic.

      Regards,
      Ross
      • Is there an "Old Rusty Hammer" antipattern? People who have been using the same tired tools for years tend to look at all new problems as if the old tool can solve them.

        Seriously, the key is using an appropriate tool. It doesn't matter if the tool is old or new.
    • Since I have repeated my pattern skepticism on /. before numerous times, I will just link to my rant this time:
      [geocities.com]
      http://www.geocities.com/tablizer/prpats.htm#for mu las
      • My co-authors and I became interested in patterns after earlier work in "best practices." We had been working for a client to capture them, but we realized that just because a practice works in one organization, does not necessarily mean it will work in another. The approach we took focused on both the effective practices that we found, but also the context in which they were practiced, i.e. we wanted "best fit" practices not just "best" practices. We found that the pattern format was a good way to capture and communicate these kinds of organizational insights because of the explicit concern for both the problem to be solved and the context in which it occurs. Of course, as the earlier post in this thread suggests, the problem and context are lost on some readers :+)

        Your critique on the OO/Design Patterns is interesting, I am not sure that it addresses how patterns were used in the book to communicate ideas on how organizations behave. I mentioned in one of the other posts that the chapter on rhythm is availble online [bredemeyer.com]. That chapter includes several patterns that are typical of the style and substance of the others in the book.
    • The Cheat is to the Limit
  • According to the review, the book seem to be how to manage a project to an ugly completion. Very similar to how eXtreme Programming is supposed to result in more efficient development, but results in disorganized (yet working) code.

    Or is this actually a worthwhile guide to software engineering? Does anyone know?
    • Just how does XP result in disorganized, yet working, code? There is nothing in the tenets of XP that proposes this. Have you tried XP? Please attribute your source.
  • You might also want to check out the latest development process paradigm: Market Programming [slashdot.org]
  • by nadador ( 3747 ) on Monday December 16, 2002 @02:24PM (#4900526)
    This is exactly what's wrong with the universe, or at least the small part of the universe occupied by software engineers.

    What has all of our Functional, Object Oriented, Extreme Programmed, UML-based, XML compliant, Pattern-ed or Anti-Pattern-ed flow charts in animated PowerPoint got us? Its got us a load of crap, thats what. A load of crap. We re-org endlessly. We have more meetings. We write more Standard Operating Procedures. We rewrite the coding standard. We switch languages, run times, operating systems, and libraries. We refactor, re-code, re-work, re-design and re-plan. And we get a load of crap. We manage, and plan and re-manage and re-plan, depending on what the winds of your upper management's whims dictate is the "in" style for the day.

    What should all of this tell us?

    Software engineering is a practical craft. No amount of process will ever make up for proper training, proper documentation, proper version control, and proper testing. Ever. And that's the way it is. If you have good people, set them free. If you don't, spend a little money to train them to their highest potential instead of trying to make them good cogs in a crappy buzzword wheel.

    In the end, 99% of the work done by software engineers is just rearranging magnetic pixy dust on some drive platter, or scattering the electrons in a flash or DRAM or SRAM cell. Most of our value to the universe is just damned pixy dust. And it shouldn't be this difficult.

    We don't need any more of this - we all just need to learn how to be practical craftsmen that get *work* done.
    • We don't need any more of this - we all just need to learn how to be practical craftsmen that get *work* done.

      Sure.

      No amount of process will ever make up for proper training, proper documentation, proper version control, and proper testing. Ever.

      A process is supposed to precicely about a framework for accomplishing those things. Sadly, it doesn't tell you how to do the work. That requires experience.

      If you have good people, set them free.

      Depends what you mean by this. Do you mean -- everyone is autonomous, let's hope for emergent organization? Or do you mean -- let's come to a consensus of the MINIMAL required ceremony to get our jobs done in the most effective way possible? The former is possible with a very small team of experts. The latter is possible with a (more likely) team of mixed-expertise(high/medium/low).

      What I'm trying to say is that process & methodology doesn't have to be about getting poorly [trained, motivated, disciplined] people to develop great software. It just happens that many poor managers (which are in much larger supply than poor software developers) tend to apply it that way.

      Agile processes are precicely supposed to be about letting good people get their job done, without stepping on each other! That's the whole idea behind XP and its ilk.

      Object oriented technology, patterns, etc. are all techniques for experienced programmers to create more maintainable and expressive programs by elevating the level of discourse. They can be misused. They don't substitute for experience. But there is value there.

      By suggesting that "we don't need none of this extra stuff", you are right -- yet there still is a place for that "extra stuff".

      It's kind of like Maslow's hierarchy of needs. At the base levels, you need good [disciplined, competent, motivated, intelligent, trained] people, good team dynamics, good technical management, support from general management.

      This is the kind of stuff that the Agile Alliance [agilemanifesto.org] believes in. People over processes, collaboration over negotation.

      At the upper levels of the hierarchy of needs are things like tools, processes, and higher-level programming constructs. They do add a lot of value to software development, but are not first order success-factors.
    • Software engineering is a practical craft. No amount of process will ever make up for proper training, proper documentation, proper version control, and proper testing. Ever. And that's the way it is. If you have good people, set them free. If you don't, spend a little money to train them to their highest potential instead of trying to make them good cogs in a crappy buzzword wheel.

      This is quite a simplistic view of the development world. I think it "may" have some relevance for smaller projects, but a recipe for disaster in anything approaching a large project size (i.e. hundreds of people involved).

      Just look at some ongoing sizeable Open Source projects (where you might expect no process) as examples. Lets take Mozilla: There are guidelines for coding, guidelines for checking source in, guidelines for reporting/fixing bugs, guidelines for deciding what gets into a particular release, etc... This is a process. It may not be the the process-du-jour, but it exists. It has to at this scope, otherwise anarchy results.

    • True, you can over process and there is a lot to this. However, I am a believer that we will get better at the process of designing good software. Software is not magic pixy dust that weirdos produce using a dark art. At least it shouldn't be. It should be a well ENGINEERED product which is adaptable and relatively easy for a newcomer to understand. Patterns and OO, if used properly, promote this understanding. Good process encourages good design and IDEALLY gets us closer and closer to being able to adaquately predict when a software project will become complete. For those writing to checks to have software become complete, knowing when it will be done is the holy grail. For those of us writing code, not having to work obscene hours to meet unrealistic expectations that are the result of not knowing early would be awefully nice as well.


      Where I will agree with is that training, documentation, version control and testing are absolutely critical. I see establishing good ways of doing these things as key process. Buzz words are just that, but they are largely just names for good ways of going about writing software. You need good people, but you need to have them working together and in a manageable way.

  • The cornerstone of software development is the specifications. Once this is laid out, the rest is easy.

    I work at the defense application sector and every software project comes complete with a book of specifications. Every little detail is described analytically. We never had a problem with any project. We don't work long hours (standard 9 to 5) because we don't need to. We also have to deliver a preliminary design document prior to first meeting which proves that we understand the design issues.

    On the other hand, the next door department works on business applications: web banking, mobile phone accounting, distributed DBs etc. They work under terrible stress, they throw big amounts of code every week, they work overtime almost every night, and they almost all smoke one cigarette after the other. And this is all because there are no fixed requirements for each contract they get: requirements change by the minute, from person to person, from manager to developer to network administrator!!!

    The real software is not the code: its the specification, and specification means requirements and design. Everything else, incluging VRAPS, is buzzwords to keep the manager happy.
    • Sure, specs are great if you can get them, and the requirements are stable. Otherwise, software development becomes unending specifications development, which has been the spiral of death for many a project.
    • Yes, business requirements change constantly. That is because the marketplace (that you are so conveniently insulated from in the defense sector) changes constantly. I'm sure that if you can devise a way to freeze the economy in time, your harried neighbours will be delighted to write specifications at their leisure.
  • Just ask for the chief architect, Art Vandelay [sonypictures.com].
  • If you want to review the book for yourself, portions of the book are available online.

    The preface and the rhythm chapter can be found on Dana Bredemeyer's software architecture site: http://www.bredemeyer.com/papers.htm [bredemeyer.com]

    Amazon also has about 44 pages from the book on their site including all of chapter 1 (Introduction), some of chapter 2 (Reference Model), the index, and table of contents.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...