Author: Paul C. Brown
Publisher: Addison Wesley Professional (www.informit.com/aw)
Published: April 2008
ISBN-10: 0-321-50472-0
ISBN-13: 978-0-321-50472-2
Format: Soft cover, 736 pages
Price: $59.99
The Business Value of SOA
The emphasis in the book, "Implementing SOA: Total Architecture in Practice" is on the business value that can be derived from SOA (Service-Oriented Architecture) implementation. As implied by its name, the book explains that SOA is "an architectural style that modularizes information systems into services." The ongoing challenge for IT professionals then involves orchestrating the "collections of these services to bring business processes to life."
The ultimate goal of a successful SOA, as put forward by Paul C. Brown, the author of "Implementing SOA: Total Architecture in Practice", is to possess the capability to "readily recombine these services in various ways to implement new or improved business processes." The content of the "Implementing SOA: Total Architecture in Practice" book has been divided into nine major parts, and is comprised of 43 chapters in total.
If you have the time available, I suggest that you read the book in its entirety, rather than just randomly picking out bits and pieces to read. Reading sequentially through the chapters of the book will provide you with a comprehensive understanding of how to put SOA into practice within your company or organization.
The first five chapters of the opening section of the book are dedicated to the fundamentals of SOA. This is where you can read about the role SOA can play in your enterprise, and covers both architecture and service fundamentals, along with using services and insights into the SOA development process (and how this particular development process differs from conventional development projects). Interestingly, Brown points out that "SOA development commonly involves multiple development teams – both present and future. Typically one team is developing the business service while another team implements the business process that uses the service. In the early stages of your SOA initiative, there may be a third team working on SOA infrastructure and infrastructure services."
A feature of "Implementing SOA: Total Architecture in Practice" that I found particularly useful as I read through the book is that every chapter concludes with a short series of key questions. By attempting to find answers to these questions, readers of the book are greatly assisted in honing the skills required to create robust SOA solutions. For instance, one of the questions from the chapter about service fundamentals is "Do your services employ common data representation technologies that facilitate the movement of data between disparate platforms?" See below for more information about how you can use these key questions to your advantage.
In addition, a number of chapters in the book also include a "Suggested Reading" list that contains extra information about some of the topics that have been discussed in that particular chapter. Indeed, at least one other book about SOA that is worth looking out for has been written by Brown himself, namely, his first book called "Succeeding with SOA: Realizing Business Value Through Total Architecture."
The titles of the eight remaining major sections of "Implementing SOA: Total Architecture in Practice" are listed below. And to give you some sort of immediate feel for the type of content that you can expect to find in those sections, I have also included just a small selection of key areas that are investigated in each of them:
1. "The Business Process Perspective": processes; initial project scoping; modeling scenarios; process constraints; and defining business process patterns.
2. "The Systems Perspective": an overview of systems architecture followed by an indepth discussion of top-level systems architecture.
3. "Communications": transport technology; a range of adapters, for instance, database based adapters, file based adapters, etc.; defining a communications strategy.
4. "Data and Operations": data consistency; common data models (CDM); results validation.
5. "Coordination": coordinating two or more activities; process monitors and managers; detecting and responding to breakdowns.
6. "High Availability, Fault Tolerance, and Local Distribution": stateless and stateful failover; workload distribution.
7. "Completing the Architecture": process security; process monitoring; testing.
8. "Advanced Topics": this section of the book is made up of three chapters: "Representing a complex process"; "Process management and workflow"; and "The enterprise architecture group."
There is one final, small section of the book, just a few pages in length, that has been titled "Afterword." The book's author, Paul C. Brown, uses it to remind readers that "there are many things to consider when evolving the enterprise architecture – so many that it is not practical to consider every issue for every business process scenario." If you attempt such an approach, Brown warns that you run the risk of "spending the majority of your time considering issues that, in the end, don’t really matter."
In order to maintain your focus, he recommends that, instead, "you need to continually ask yourself three key questions about each design issue:
1. Is the design issue relevant?
2. Is satisfying the requirement important to the enterprise?
3. Is the proposed solution sufficient?"
In fact, Brown summarizes the above by stating that, "in the end, architecture is about judgment – your judgment about what is relevant, important, and sufficient. Keep focused on what is important to your enterprise."
If after reading this review, you would like more information about Brown's book, you can peruse its "Table of Contents" plus its index, as well as read the book's preface and the complete fourth chapter, titled "Using Services." All of these are available online at http://www.informit.com/store/product.aspx?isbn=0321504720 which is the address of a Web page that's part of the site of the book's publisher, Addison Wesley Professional.
In conclusion, Brown makes the point that any IT professional, given the responsibility for SOA in their enterprise, indeed faces many challenges. He states that "whether intended or not, the architecture you create defines the structure of your enterprise at many different levels, from business processes down to data storage. It defines the boundaries between organizational units as well as between business systems." Obviously the architecture that's required is non-trivial. Brown stresses that it "must go beyond defining services and provide practical solutions for a host of complex distributed system design problems, from orchestrating business processes to ensuring business continuity."
So if you find yourself in the situation of being responsible for SOA in your company, I recommend that you read "Implementing SOA: Total Architecture in Practice" as soon as possible. Doing so will significantly increase the odds in your favour of successfully meeting the challenges you are likely to encounter.
Once you decide to read this book, Brown himself offers a couple of suggestions as to how you can get maximize value from it. He describes the first way as being "prescriptive", which, he explains, means that his book "presents a structured approach to tackling individual projects and managing the overall enterprise architecture." His second suggestion is to use his book as a "review guideline." That's possible, he says, because "each chapter discusses a topic and concludes with a list of key questions related to that topic. Use the questions as a self-evaluation guide for your current projects and enterprise architecture efforts. Then use the content of the individual chapters to review the specific issues and the various ways in which they can be addressed." And I am in total agreement with him when he says that either of these ways will result in strengthening your enterprise architecture.