Applied Software Architecture

Rating:
Summary: A novel and thorough approach to software architecture
Review: Computer scientists at Siemens have developed an intriguing and very useful approach for describing the architecture of software systems. This book, written at a high level of quality, details a wide variety of factors that project managers and architects must consider during the course of planning, designing, and implementing small-, medium-, and large-scale projects. Backed by data from real-world examples, the authors present their ideas in a very understandable form and give software engineers many good ideas for improving the quality of their products.

Rating:
Summary: This book is excellent!
Review: I am Software Architect at Siemens Medical Systems, Angiography Division in Chicago.I am involved with the architecture for a Angio Acquisition/Post processing system. I have read the book "Applied Software Architecture". It is excellent! I find it very helpful and use it as a reference for my architecture work.

Rating:
Summary: Architects of the Architecture process
Review: OK. So you are a seasoned software engineer, 4th and 5th generation languages hold no secrets for you, design patterns are your credo, and you even have tackled this good old OMT technique. However, you still feel uneasy when it comes to translating use cases to risk management, and especially to take into account those interns who will develop part of the software.

This book answers your questions by proposing both a technique and a language (UML extended), that will help you list the different factors affecting your project, infer the right design decisions, and document them throughout the project. For those with an analytical mind, the architecture process itself is decomposed and re-engineered. No consultant talk here : everything is explained, both in words and figures, using real world examples.
Some will regret that the application field used for the demonstration is too narrow, since only real time applications are used, and there is no reference to database architecture or e-business ! But for those of the embedded world, such a book was awaited, and browsing (too) quickly through various application fields would have contented no one, anyhow.
It is still a long reading, if you want to study all examples in depth - fortunately, you can start your own design after the first case study.

Lastly, using UML throughout the project eases the communication with the development engineers, and it really helps when your team tackles detailed design.

Rating:
Summary: Solid practical advice for practising architects
Review: The authors show how to practically apply software architecture principles by providing a process distilled from the collective wisdom of successful projects at Siemens.

The organisational, product and technical factors affecting the development of a product are called out and the authors provide a means to systematically identify and classify each of these factors. The attempt to satisfy each factor inevitably leads to issues which must be addressed. By providing an issue card format that records the general solution and associated strategies, each issue can be comprehensively addressed. In fact new issues may be raised as a result of the adoption of a strategy and these new issues can be addressed in the same way.

To me this clear linkage between the factors that affect the product development, the issues that arise, and the strategies that address them, is the most outstanding attribute of this book. My only quibble is that the examples given do not encompass business sofware development.

Overall I heartily recommend this book as an excellent way of making sure that you are addressing the issues in your projects.

Rating:
Summary: Good for the case studies
Review: This book is clear, solid, and workmanlike. It could work well as a textbook, or one of several texts for a term course.

It gives a systematic introduction to several high-level notations, describing the conceptual, executable, structural (or module), and code views. Most of the notation is well-formed UML, and the authors take care to add semantic notes to every part of the graphical notation. They supplement the standard notations with a few text-based extensions. These capture requirements, archtiectural decisions, risks and risk mitigation, and other operating features of a living software project.

One real asset is the related set of brief case studies at the end of the book, three separate products with a common conceptual base. This book is aging, it dates back to 1999 - five years, as I write this. That's old in the "architecture" literature, and the authors fail to apply the "product line" notion. I take this book for its good, though, and lack of one buzzword is a small enough fault.

The book uses a process-and-pipe model pervasively for architectural description. It's a good tool, but other tools are good for other purposes, and their omission is a problem here.

Still, the book is competent on the whole. Its sustained product-line example ties the whole together, and it focusses on practice intead of mainfestos and brand-name methodologies. There's a lot of good here, and you can pick out out easily.

//wiredweird

Rating:
Summary: Much Form, Little Substance
Review: This book spends a great deal of time discussing what it suggests one does to architect a system. However, there is very little on how to actually do it. The steps to do things are detailed, but what doing the steps means is not well articulated. Further, some parts of the process are very poorly explained, but still used as a foundation of many other parts of the process.

The best practices are simply case studies that really impart no wisdom to the reader (or, at least, to this reader).

I tried to "get something" out of this book several times, and read it fully twice. However, I'm convinced that there really isn't much there.

Rating:
Summary: Good in essence, lower in form
Review: This book try to tackle a very hard, even if not old problem : How to model the architecture and what approach can be adopted ? The high value here is : they do it ! I think the approach adopted here is at least a very good starting point and the multiple view approach looks like Kruchten's idea. Another good thing is the improvements proposed to UML for architechture. My highest regret is about examples proposed here : They are too complex and the ideas behind the approach is hidden behind the exemple themselves which are hard to understand. Moreover, we have four example, all seems to be real time example. I would like to have several domain here, like B2B architechture and classic IS architecture. Finally, it's a pitty to gives only 3 stars for a book where I feel 5 stars possible...