Total Unity in Total Architecture: Book Review

I started to read "Succeeding with SOA: Realizing Business Value Through Total Architecture"
by Paul C. Brown today. I was actually looking for another book on my subscription service but the title and cover of this one appealed to me.

A number of books, articles and talks make a big point of bringing IT and the users together as if IT goes off and does its own thing just for the sake of it without consulting anyone. I have yet hear anyone say "Ignore the user, IT knows best" or "Make sure the business does what IT says". I too will sometimes gratuitously implore my technical staff to get inside the head of business but presenting the fact that IT and business should be closer is not particular new of insightful.

This book suffers a bit from this. Creating governance structures that make sure a business need is satisfied and even architectures (like SOA) that bring the business process in better view are well worth writing about and Brown spends some time on this. I found the information content thin and sometimes descending to motherhood. Perhaps this book was pitched more at the business management. There is not much technology in it. It is to be the first of two books. The second will be written for Architects rather than management. I regard myself as management and the first couple of chapters have not done much for me.

I think this book has some good points. It raises the questions

• Who from the business is responsible for the services?
• Who can provide this cross-project perspective of re-usable components?

I might persist to see what the Brown's answers to these are. I also like the steps presented:

• Justify each project on its own business merits.
• Have an explicit architecture step in every SOA project
• Have an active SOA architecture group
• Have a living SOA project road-map

This seems good advice.

In general I was looking for a more tightly written technical book. I am from a mathematical background and I like definitions precisely stated and concepts built from these definitions. Thus "Total Architecture" is not clearly defined but it is suggest that the one god-like architect is responsible for both the business processes and IT systems and we get this definition of a service "A service is a bundling of information and the functionality required to manage it".

I think I might keep looking for the book I was looking for before I found this one. I am sure I would get some benefit out of completing this one, but it was not quite what I was looking for.