Customer Reviews

The Software Architect's Profession: An Introduction

5 star:		(7)
4 star:		(4)
3 star:		(1)
2 star:		(4)
1 star:		(3)

 

 

The Sewell's try to address the crisis in our industry by attempting to formalise and define the role and profession of the software architecture. They do this by comparing the software industry to the building industry. They advocate specific educational programs for software architects. Personally I feel that this approach is valid - I have post-graduate qualifications from a school of (building) architecture and design, plus bachelors in computer science - but work as a software architect. Yet I find a lot of confusion in the marketplace (and sometimes in my own mind) about what a software architect is and is not.

This is not a practical book. Instead it attempts to provide a philosophical basis and justification for the profession of software architecture. If you read this book hoping to find an architectural process or methodology, look somewhere else. If you are looking for a set of templates to use as a basis for your practice, read Dikel eta al's "Software Architecture" instead. But perhaps the current book will contribute significantly the debate that is sorely needed in the software industry.

The book is well-written and a pleasure to read. I found the anecdotes relevant and enlightening.

While I recognize the need for a distinct role of software architect, different from that of software developer, this book takes the analogy to building architecture way too far. It fails to recognize that while physical architecture is literally set in stone, software structures are forever malleable, that physical architecture is concrete and there is a standard way to communicate it while software architecture can be abstract and efforts to standardize its representation have not been truly successful, that aesthetic factors play an important role in physical architecture while software architecture is driven almost exclusively by practical considerations, and that software construction often calls for professionals, not tradesmen comparable to plumbers and brick masons, etc. I think for most organizations it makes practical and economic sense for developers to be able to take on more than one role during the course of a project, and most team members would look forward to it as well. I also think that the superstar architect championed by this book who sticks to a bird's eye view of things while the lowly "builders" fill in the details would have a difficult time coming up with practical designs as well as getting the respect from developers he would need to be truly effective.

This books gets two stars from me because it does contain some useful insights. For instance, the case it makes for architects as client advocates is particularly compelling. It also stresses that an architect should understand the client's world view in a way that goes above and beyond laundry lists of requirements, which is hard to argue against. I guess if this book were a ten to fifteen page manifesto, with the key insights and ideals behind software architecture presented concisely (along with a proportional reduction in the [$$] price tag), it would be worth it. But unless you are interested in a tour through architecture history (filled with such illustrating words as "venustas" and "firmitas"), a cliched account on why software projects fail, and a concept of software architecture that raises more questions than it answers, it would be better to look elsewhere.

Finally, someone has pointed out that the emperor is, indeed, naked...that all of the hoopla about rapid application development, extreme programming, etc., etc. hasn't given the poor neglected customer (whether internal or external) software that a)actually does what the customer needs (not just wants) , b)is completed within schedule, and c)comes in within budget. All the emphasis on getting on with coding has given us software that, in most cases, only a masochist could love. As the Sewells point out, using software should be a pleasant, even enjoyable experience -- like living in a well-designed house. Instead, all too often, those upon whom poorly designed software is inflicted complain it makes them feel stupid. Yessir, that's certainly a noble goal for the software profession - and one it has obviously achieved in spades! Neither the ignorance of what users really need; nor the hubris of thinking that because one can write code, one can also make design decisions results in inspired software. Let's be blunt: most software today is not designed, it's engineered...the situation is quite equivalent to having Bob Villa design the Empire State Building. I'm sure Mr. Villa is a complete professional at what he does, but I also suspect he'd be the first to say that he'd be out of his league as an architect. Just because you're very good at construction doesn't mean you're an architect. No matter what your beliefs, there is a fine quote out of Proverbs (29:18): "Where there is no vision, the people perish..." And that's the problem: all current methods of software development have no place for "vision," artistic or otherwise. The Sewells bring a long overdue voice of sanity to a field upon which so much of modern life depends. The only problem is that if you're in any way at all involved with software development as it's currently practiced, once you read this book, you'll become increasingly dissatisfied with all the nonsense going on around you. Read it anyway! Get dissatisfied! Customers of software "designed" with the current engineering mentality will thank you- whether they shell out their hard-earned money for it or are forced to use it all day in their jobs. Eventually, we can make a difference - and the first step is to read the Sewell's call to sanity.

As other reviewers have pointed out, there is very little reference to software in this book. But as the Sewell's point out, most of the actual software technology is in the province of the builders, and/ or the experience base that the architect brings to their engagement. It doesn't belong in this book.

If you're a practicing software architect, as we are, I think you'll find this book puts into context a great deal of what occurs on your projects. While others, such as John Zachman also use this analogy, they use it to different ends. Zachman, for instance uses it as a framework to build successively more detailed models of the systems to be built.

This is a book is advocacy for Software Architecture as a Profession

This book starts out well, but leads nowhere. By the end of the book, I felt that the authors had no business writing about software architecture because they seemed to have little insight into software development. When they make statements like "great design is rarely mentioned in the software field" (I've paraphrased) I can't help but wonder where they have been for the past 30 years. I'm in the industry and I hear and participate in those discussions frequently. There are of course projects, where the design (and architecture) are not properly done, but it is common knowledge that this a bad idea.
My determination of a good software book is whether or not, I would want the authors working on a project with me. By the end of this book, I felt like I would not want these two on any project I was leading. They seem too naive, and too eager to embrace over-simplifications of complex topics.
I'll give them one star for at least trying to define the role of software architect and for taking on a complex subject.

We are in an industry whereby progress can be effectively described by Moore's Law, stating that every 18 months, processing power doubles while cost holds constant. Telecommunications bandwidth and computer memory and storage capacity are experiencing a similar fate.

Although we cannot say the same may apply to methodology, process and framework supporting software construction. These have also evolved in quick and overlapping pace. I joined the IT workforce 13 years ago happy with designing application software using straightforward FlowCharts and Structured language writings of collaborating modules. This has wondered off for a while to the "false" promise of 4th GL and subsequently to the existing Object Oriented world.

The author propose the Software Architect be educated and will earn his due recognition as a true Professional, as we see in a Doctor, Lawyer or Building Architect. One important aspect the author rightly argues for is the definitively role of a software architect in a complex software construction exercise. But without the institutionalization of the Software Architect profession, it is going to be a challenge holding any individual accountable for the "soundness" of software design.

It is hard to agree that a proficient Software Architect may not be a first class software builder. The analogy of the Building and Construction industry gives hope to people who enjoys software but may not fancy sitting in front of machine churning out beautiful language constructs only a machine can effectively execute. I do look forward to that day for that will be when everyone gladly assimilates software as part of his/her daily essential existence, and without suspecting fear. Anyone with the audacity to leave a backdoor for the next "Y3K bug" will be revoked of his rights to design any future system. I cannot imagine a Building Architect designing a state-of-the-art Hospital structure that may just collapse when we are celebrating the arrival of the next "millennium".

But if there's any realization through this process of discovery, it would be that software construction is often more important an art than about technical prowess. The next great software architect will not only inspire more "breath taking" structure to be planned and built, but also should leave a lasting legacy behind (just as Imhotep would with the pyramids), even if it's only in a virtual world.

This is an easy read for those (i.e., Software Architects) who want to draw parallels between the traditional meaning of the term "Architect" and that of the "foggy" Software Architect in order to help teach others that this profession is badly needed.

More emphasis on the role of a Software Architect and case studies of the project successes with a Architect are needed. Also, the essence of the material could have been covered in 50 pages; however it is a step-forward in defining the profession.

We are in an industry whereby progress can be effectively described by Moore's Law, stating that every 18 months, processing power doubles while cost holds constant. Telecommunications bandwidth and computer memory and storage capacity are experiencing a similar fate.

Although we cannot say the same may apply to methodology, process and framework supporting software construction. These have also evolved in quick and overlapping pace. I joined the IT workforce 13 years ago happy with designing application software using straightforward FlowCharts and Structured language writings of collaborating modules. This has wondered off for a while to the "false" promise of 4th GL and subsequently to the existing Object Oriented world.

The author propose the Software Architect be rightly educated and will earn his due recognition as a true Professional, as we see in a Doctor, Lawyer or Building Architect. One important aspect the author rightly argues for is the definitively role of a software architect in a complex software construction exercise. But without the institutionalization of the Software Architect profession, it is going to be a challenge holding any individual accountable for the "soundness" of software design. It is hard to agree that a proficient Software Architect may not be a first class software builder. The analogy of the Building and Construction industry gives hope to people who enjoys software but may not fancy sitting in front of machine churning out beautiful language constructs only a machine can effectively execute. I do look forward to that day for that will be when everyone gladly assimilates software as part of his/her daily essential existence, and without suspecting fear. Anyone with the audacity to leave a backdoor for the next "Y3K bug" will be revoked of his rights to design any future system. I cannot imagine a Building Architect designing a state-of-the-art Hospital structure that may just collapse when we are celebrating the arrival of the next "millennium".

But if there's any realization through this process of discovery, it would be that software construction is often more important an art than about technical prowess. The next great software architect will not only inspire more "breath taking" structure to be planned and built, but also should leave a lasting legacy behind (just as Imhotep would with the pyramids), even if it's only in a virtual world.

I liked this book, it was a quick and enjoyable read about the history of building architecture. Relatively little was said about software architecture, as I read it the book says the role of a software architect needs to be defined but does not attempt any sort of definition itself. This is not a criticism, the book has in its title that it is an introduction, and it makes for a good introduction. The writing style was amusing, I took a quick poll around the office to see who knew what a hair shirt is, including me only 2 out of 10 knew. I say ultimately disappointing because as I reached the end of the book and realized that the authors really weren't going to give any direct information about what software architects do, not even drawing clear distinctions between the designs they turn out vs. what an engineer turns out, I lost interest and thought it wasn't really worth the $.

As a programmer for 32 years and a manager of programmers, I found this book to be a helpful and necessary introduction to one of the most neglected areas of our profession. The limits of the construction metaphor for software development are examined in this book and put into a new perspective, that of an organic approach. The authors skillfully weave the history of the profession of architecture, its practices and motives, into a narrative that informs software design. They consider software systems as 'extensions of our minds', to use their words, and discuss how to achieve these extensions in ways that can be realized with software construction techniques.

This book offers a fresh look at the process of development of software designs and challenges us to embrace architecture-driven software construction. In a day when most software products emerge from the lava flow of code cut-and-pasted from previous projects, the insights provided by this book are worthy of deep consideration.

I highly recommend this appropriately brief book to all members of a software development team, especially the leaders and managers of such teams.