Home Design Softwares

I initially wrote a far more acerbic review that got some feedback from the author, after ruminating on it for a while I figured I should edit it to express the direction my opinion veered after our discussion. I can’t change the number of stars in the editing interface, but I’m not sure I should — this book is not for me

One point of confusion emerged in our conversation — the book appears to have been originally titled “Essential Software Engineering”, and the author refers to it as such. Though I feel that in it’s present form it would be quite inadequate as an engineering book, as an architecture book it is actually pretty damn good.

Much of the book is spent explaining different terminology well enough for the reader to be able to hold their own in conversation, but if everyone read the book (and did not do further research) there wouldn’t be much discussion to be had. It’s definitely an introductory text, not a primary source.

One thing that grated on me is that the book is mostly in nested outline form! The concepts are *well described*, but not too well contrasted. The format does not do a very good job of relating the concepts to one another — they are presented serially as if in PowerPoint. You’d get a better understanding in a lot of ways by browsing the related Wikipedia articles, simply because hypertext is better suited for explaining multidimensional things (though hypertext obviously does not work on paper). A lot of the subheadings throughout the book are short & shallow — but the alternative of longer & shallower would be clearly worse

The case study is discussed far too abstractly: he enumerates the functional and non-functional requirements, and gives an overview of the chosen architecture at too high of a level — but does fairly little to justify the choices made. He does not really discuss the various downsides to the chosen architecture, nor does he discuss why other architectures were not chosen. Absolutely no discussion is made of feedback from the ‘architect’ to the ‘client’ about weighing the potential usefulness of the dictated features — especially those which hinder the use of architectures better suited to the problem domain.

A major disappointment that stood out for me was that he didn’t really address the *culture* of Big Design Up Front — where all your mistakes are designed, diagrammed in UML, and ossified well before you start coding. I find that architecture should be something that is put off right up until the point when a qualitative decision about how things should work is no longer avoidable. My favorite definition of Software Architecture is from the original c2 wiki:

> “the set of decisions that we have to live with for the life

> of the project or system because it will be too expensive to

> change our implementation later if we change our minds”

Most of the technologies are related to the use of middleware to interface a companies’ homegrown software and customized versions of commercial software together with commercial backend software. Because of this the primary readership I see for this book is in department-level managers in charge of dealing with the nightmare of deploying ‘Enterprise Software’ for a large business. I can see this book actually being quite helpful to them, particularly if they do not have a background in Computer Science.

If you’re a code monkey and not a decision maker, this book doesn’t really contain anything that could help you deal with your task directly — it might even demoralize you by helping you realize how poorly/over-architected the system you toil on is. If you have any agency it might help you manipulate the managers below and above you into seeing things your way!

If you’re an academic, it’s probably only really useful for ‘gawking at the natives’ over in industry. Much of the chafing that I experienced with this book is related to the fact that my course spent 3 credit-hours a week on it for ten weeks — it did not hold up well at all under our drawn-out usage of it. We were not at all the right audience for it.

Reading through it again now it holds up a lot better, with a lot more mindfulness evident in the text than on the first drudgery-filled pass as a group. Thinking about it now I realize how exceptionally mindful it is for a book in it’s field! I would not recommend it’s use in an academic Computer Science course, but it would probably work pretty well as a text in courses on Business, Information Systems, or Software Engineering; especially in a coursework-based masters program.

The second edition promises to dismiss most of my criticisms, especially in regards to the case study.
Rating: 1 / 5

This book was the textbook for a introduction course to software architecture. I found the textbook quite helpful in learning architectural principles.

The core chapters of the book are the first 6 chapters, which provided a strong foundation of knowledge. Chapter 1 introduces the topic by discussing architecture definition, abstraction, views and non-functional requirements plus others. Chapter 2 introduces the study study utilized throughout the book. I got alot out of chapters 3 & 4. Chapter 3 discusses software quality attributes that an architecture should take into consideration. Quality attribute are characteristics of an architecture design rather than capability. Quality attributes are such items as scalability, modifiability, security, performance, portability, etc. Chapter 4 discusses architecture design patterns and technologies applicable to architecture design. Chapter 5 discusses development cycle for defining your software architecture. Chapter 6 discusses how to document the architecture design.

I thought chapter 6 was a bit light in discussing architecture documentation. In the course where this book was the textbook, there was much time spent discussing views and viewpoints. I think chapter 6 should have delved deeper into the view discussion.

I thought the author did an excellent job with this book. There are many different types of software architectures that can be built. Therefore, readers would becoming various technological perspectives in reading this book. I felt he discussed the topics in the chapters in a way that was applicable to this wide audience.
Rating: 4 / 5

Get this book if you’re interested in seeing UML 2 applied to software architecture specification. In any case, it gives a good overview of architecting with emerging technologies as well as state-of-the-industry middleware.
Rating: 5 / 5