|
|
The Software Architect's Profession: An Introduction (Software Architecture Series)
|
List Price:
$36.95
Buy Softwares Price: $36.95
Subject To Change Without Notice
Availability: Usually ships in 24 hours
Manufacturer: Prentice Hall PTR
|
Average Customer Rating:   
|
|
Binding: Paperback
Dewey Decimal Number: 005.3
EAN: 9780130607966
ISBN: 0130607967
Label: Prentice Hall PTR
Manufacturer: Prentice Hall PTR
Number Of Items: 1
Number Of Pages: 144
Publication Date: 2001-09-29
Publisher: Prentice Hall PTR
Studio: Prentice Hall PTR
|
|
|
|
|
|
Editorial Reviews:
|
A transformational guide to the profession of software architecture. Whether a structure is built of bricks, steel, or computer code, the process begins with an architect and client. Together they arrive at a shared vision-a plan-that the architect guides through the bidding, construction, and implementation phases. The Parthenon and the Empire State Building were built according to architectural designs, but the software industry has been building information skyscrapers without architects. It is time for the profession to become a reality. Successful software-based technology is designed, then built. It does not "develop." Who creates the design? An enormous grass-roots demand exists for software architects-but a true profession of software architecture is not yet established. Many software professionals adopt the gravitas of the title "software architect," but fail to fulfill the true, classical role. Drawing on deep metaphors from traditional architecture, Marc T. Sewell, President of the Worldwide Institute of Software Architects, and Laura M. Sewell examine the nature of architecture, what defines a software architect, and how the profession is coming of age.The Software Architect's Profession is lingo-free. It is a book of philosophy that will enable anyone to understand software construction, and it is the first "line in the sand" defining the parameters of this fledgling, yet ancient, e-profession. Key areas include: *Bridging the chasm that separates clients from technical professionals *Differentiating the professions within the software construction industry and defining the roles and accountabilities of software engineers and software "builders" *Discussing the vocational temperament and aptitudes that characterize architects *Reviewing the phases of architecture *Describing the critical role of the client in understanding and validating the design and construction of software Whether you are a CIO, CEO, IT manager, software professional, or student, you inhabit software structures, and your world is profoundly affected by their design. The Software Architect's Profession offers a simple cognitive map that will change your world view of software architecture, construction, and the information structures we live and work in everyday.
|
|
|
Spotlight customer reviews:
|
Customer Rating:
Summary: Speaks to the essence of a Software Architect's profession...
Comment: A quick yet enlightening read.
This is a must read for any wanna-be software architect. It clearly points out that software architecture is not software engineering, or project management, and that the software development industry could accelerate its maturity greatly by applying the abstract principals of other architectural disciplines to software. That shouldn't be too hard, right? After all, we who develop software believe we own the corner on abstraction!
This book will not teach you the Unified Modeling Language (UML), patterns of software abstraction, or how to write modular software, but it will help you think clearly and didactically about what software architecture needs to be.
Customer Rating:
Summary: Allow the book to inspire you
Comment: Sewell and Sewell take an opportunistic stand at the ongoing debate regarding the building metaphor in IT systems engineering. Many authors before have argued that the differences between building a house, a city or an airport versus building an application, information system or an enterprise architecture are way to big to adopt each others roles.
These authors do not try to convince anyone that there is a similarity between the two fields. On the contrary, they simply state that these builders have a long tradition in engineering complex constructions. They take you on a journey to find out how their profession has evolved and leave it to the reader whether software professionals should learn anything from this experience.
For the open mind, this is an exiting perspective.
Customer Rating:
Summary: Can I have my time back please?
Comment: This book was nearly painful to read... The point of the book can be summed up so easily, I can't imagine why it took 100 pages to do it. "The Software Architect role is not viewed correctly in the software development industry. A Software Architect is analogous to Building Architects - responsible for the aesthetics and overall vision and for the software. Their goal is to manage the software design (venustas) and make sure the software is useful." There, now you don't have to read the book.
I do agree with the author's premise, and I also find that the role of Software Architect is either misplaced or not placed at all into software development projects. But the comparisons to ancient architecture are only vaguely relevant, and I would have been happy if the tangents only stretched that far. Did you know that the word "normal" originally meant "right-angled" and that it's current meaning only took shape in 1828? This (any many, MANY other tidbits of scantly useful information) can be found in the book (pg 38). A great explanation of what a Software Architect does for a living cannot.
Customer Rating:
Summary: Good subject - poor execution
Comment: 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.
Customer Rating:
Summary: Must Read for Software Architects
Comment: 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
|
|
|
|
|
|
|
|
