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

Saw presentation earlier this year

[mwillson]

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

Software is ART.

[Boss, Pointy Haired]

I wish people would stop trying to manage it.

Anti-pattern Rant

[Shamanin]

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

[Bazzargh]

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, where you get swamped with alternative designs; I only mention this because of the nice story behind that link.

Re:Anti-pattern Rant

[rossifer]

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

Re:From the department of the Glaringly Obvious

[Tablizer]

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

Software development is easy:

[master_p]

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.

Re:From the department of the Glaringly Obvious

[pyrrho]

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.

Re:This brain rot gives me a headache.

[AuMatar]

The problem is that all too often, the process becomes a goal in and of itself. Its no longetr "lets use the process to achieve this goal that will get us better code". Its "we have to do this, that, and the other in order to fulfill the process".