Process of Software Architecting, The [ペーパーバック]

About a year ago I finished up putting together a new Software Engineering Process for the state of PA. It included the best of the best, from those that gave us permission to use their content. You can check out the resources by googling "bscoe sep" (no links allowed on amazon).

A lot of the content was related to architecture. I would have loved to have had this book back then to refer people too as an educational resource. This book puts the process of Software Architecting into a very understandable format and does a great job of explaining process fundamentals.

It is hard to train people in Software Architecture, and then add a ton of Software Process Engineering concepts to it and you really begin to lose people. We had very little success in finding anyone who wanted to go through the learning exercise. Only our team used the process for the most part.

This book starts out with a great overview of Software Architecture, the Architect, and Architecting. Even if you are familiar with these concepts, they are a good read and they get the context laid for the rest of the book from the perspective the authors take on the concepts.

Next the authors give a great introduction to method fundamentals. They pull from the industry's best practices which include the RUP, OpenUP, XP, SCRUM, FDD, and use the SPEM to do their process diagrams. The do a great job of pulling out the important information that relates to software process engineering and putting it into a very organized and easy to understand format. The chapter is short and to the point.

The authors then cover documenting software architectures. In this chapter they outline an architectural description framework based on Rozanski and Woods viewpoints and perspectives, the Zachman Framework, and the 4 +1 view model.

The next chapter on reusable architecture assets provides an architecture asset metamodel for development -time assets and one for run-time assets.

The rest of the book is a detailed, real world, case study that puts the architecture method to use.

The book ends with appendixes, Software Architecture Metamodel, Viewpoint Catalog, Method Summary, and Architectural Requirement Checklist.

PROS:
Two guys from IBM authored a non IBM centric book. Although he authors both work for IBM they didn't include or use tools from IBM.

The book stays within the scope of process engineering as related to software architecture, which produced a more effective book than if they had not. For example, if they would have tried to provide a treatment of tactics instead of referring us to the best resources available on tactics. The book stay process focused.

The appendixes are very valuable references.

They use industry standard best practices for all their content. They are not inventing any new wheels here, or trying to sell a new silver bullet. They are simply picking out the best of what has worked in the industry and putting it into a very organized and usable format.

I like that they include the requirements gathering phase as part of the architecture process. You usually find the requirements discipline treated as though the architecture team has nothing to do with it. That is just not the case in a healthy process.

CONS:
I really do not have any. The only thing I would like to see is the process content in the book put into the Eclipse Process Framework Composer. That way it could be offered as a plug-in and we could include it in our process configurations.

Overall
If you are involved in software development in anyway, you should read this book. It is the story of how it is supposed to be.

"The Process of Software Architecting" looks like it could be read in one sitting. Don't be fooled. It is one of the most informative and thought provoking "job discussion" type books I have read in a long time. I made notes in the margins on page 1 and continued to the end.

Another surprise was the preface saying both architects and students are the target audience. True. Students won't get the deepness of it, but they will still learn a lot. Finally, the authors are both IBM'ers but it doesn't read like an IBM book or have an IBM slant. While the case study uses JEE, the authors summarize relevant knowledge beforehand.

Ok. Enough with the surprises. This approachable book is visual and list heavy which makes for easy understanding. Consistent bold keywords help readability. I found myself skimming some parts where the visual said it all. The appendices provide a tabular summary of much content.

For the 200 page case study, they have tasks defined in a summary box. Each task has steps along with checklists/pitfalls/best practices where applicable. I REALLY like this format. I particularly liked the emphasis on providing a mental map/thinking as an architect.

While the case study is simpler than real life, it is supplemented by examples later. My only complaint was the term "right-sizing" to mean scaling small vs large teams. Since this word was hijacked to mean layoffs, it is emotionally charged. But that being my only issue with the book is still pretty good.

I strongly recommend this book for anyone who is an architect or wants to be one day.

"The Process of Software Architecting" looks like it could be read in one sitting. Don't be fooled. It is one of the most informative and thought provoking "job discussion" type books I have read in a long time. I made notes in the margins on page 1 and continued to the end.

Another surprise was the preface saying both architects and students are the target audience. True. Students won't get the deepness of it, but they will still learn a lot. Finally, the authors are both IBM'ers but it doesn't read like an IBM book or have an IBM slant. While the case study uses JEE, the authors summarize relevant knowledge beforehand.

Ok. Enough with the surprises. This approachable book is visual and list heavy which makes for easy understanding. Consistent bold keywords help readability. I found myself skimming some parts where the visual said it all. The appendices provide a tabular summary of much content.

For the 200 page case study, they have tasks defined in a summary box. Each task has steps along with checklists/pitfalls/best practices where applicable. I REALLY like this format. I particularly liked the emphasis on providing a mental map/thinking as an architect.

While the case study is simpler than real life, it is supplemented by examples later. My only complaint was the term "right-sizing" to mean scaling small vs large teams. Since this word was hijacked to mean layoffs, it is emotionally charged. But that being my only issue with the book is still pretty good.

I strongly recommend this book for anyone who is an architect or wants to be one day.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A contrasting opinion from Jan de Boer via [...]
Ah sorry but I really do not like this book. Now first I must say, I can have very different opinions then the crowd. Sometimes I dislike movies for example that other love. I can remember a movie called oceans' number 12, I think. Lots of famous stars in it, but I just hated it. I can remember certain music records as a teenagers my friends loved, I hated them. I am kinda strange and independent.

But what I don't like about the book is, what I already stated in the previous post, it tries to over define all kinds of things. I don't like that because the process of architecture, software development, uses very inconsistent vocabulary. But if this is the case, why not just agree on the fact that these words are used in a different way in different environments? Why on every term quote all kinds of books? Just agree to disagree, and try to explain certain pitfalls and good practises by some examples instead? Also the definitions are useless I think when in all software developing environments they are used differently. You should know what it means in your environment, and this is not the same as tried in any book anyway.

Then it gives a certain empty cabinet, procedures you could follow. But if I work in a company, this is mostly already decided for me, in a method the company has chosen. And the exact organization of the shells is not that important. It is important you put something logical inside it. And then it kicks in some open doors like: this procedure could be simpler if your project is small, and more thorough if the project is complicated. Now really? And also it comes with remarks like: the order of the process in not exactly defined. Yes I know that too. It never is.

So it really did not tell me much new stuff. And what it did told me, was packed in what I think a over academic style that in the end really irritated me. In fact, I stopped reading the book at page 260 of about 300. I learned a few new terms from it. There is a check list as appendix I think is useful to check if you have thought of everything. But I would rather read a book that tells me what I can put 'on the shells of the cabinet'. The books states that this is not such a book and that there are other books who explain design and architecture paradigms. I think I will read those books then.

I will still give it a six, since it's not badly written or something. In the fact that there are a lot of errors in it. But I find the aim of the book useless, and the style over academic. Again and again some quote from some study like the writers want to prove they read all those