Software Architecture

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.

Comments

But, is this a useful book? Is it good?

[Monkius]

I think reviews should address those questions.

VRAPS

[sql*kitten]

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

[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

[spakka]

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.

Re:VRAPS

[pmz]

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.

Re:Software is ART.

[Daleks]

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.

Re:Software is ART.

[NewbieProgrammerMan]

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.

Re:From the department of the Glaringly Obvious

[Tablizer]

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.